Einführung der Gesundheitskarte

Größe: px
Ab Seite anzeigen:

Download "Einführung der Gesundheitskarte"

Transkript

1 Einführung der Gesundheitskarte Spezifikation der Broker Services BROKER SERVICE AUDIT SERVICE SECURITY SERVICES Version: Stand: Status: freigegeben gematik_inf_brokerservices_v1_1_0.doc Seite 1 von 175

2 Dokumentinformationen Änderungen zur Vorversion Die Änderungen im aktuellen Dokument betreffen neben dem Broker Service i. e. S. insbesondere den Auditdienst (Audit Service) als die Komponente zur versichertenzentrierten Protokollierung der Zugriffe auf die Telematikinfrastruktur. Eingearbeitet wurden dabei Änderungen zu Umfang und Ablage der im Auditprotokoll abzulegenden Daten (Reduktion und versichertenindividuelle Verschlüsselung der Auditdaten) sowie die Einbindung des Aufrufs des Audit Service in die Verarbeitung von Telematiknachrichten (asynchron statt synchron). Im Abschnitt über den Broker Service wurde das Konzept der Brokersequenz als Bausteine der Broker-Sequenzen eingeführt. Inhaltliche Änderungen gegenüber der Vorversion sind 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: [gembroker] gematik ( ): Einführung der Gesundheitskarte - Spezifikation der Broker Services Version Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Ersterstellung und Grobstrukturierung gematik, AG bis /06 bis 11/06 Ausgestaltung der Kapitel gematik, AG interne QS gematik, AG Einarbeitung der Review-Kommentare gematik, AG freigegeben zur Vorkommentierung gematik Einarbeitung externer Review-Kommentare gematik, AG freigegeben gematik Einarbeitung der Änderungen am AuditS gematik, AG Einarbeitung der Review Kommentare gematik, AG freigegeben gematik gematik_inf_brokerservices_v1_1_0.doc Seite 2 von 175

3 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokumentes Aufbau und Inhalt des Dokuments Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokuments Verwendung von Schlüsselworten und Konventionen Verwendung von Schlüsselworten Konventionen zur Kennzeichnung von Referenzen und Abkürzungen Konventionen zur Kennzeichnung von Architektur-Tiers Konventionen zur Kennzeichnung von offenen Punkten Notationen Anforderungen und Annahmen Einleitung Funktionale Anforderungen Nichtfunktionale Anforderungen Funktionale Annahmen Nichtfunktionale Annahmen Die Broker Services im Überblick Einordnung: Telematik-Gesamtarchitektur Primärsysteme (Consumer Tier) Telematikinfrastruktur (Telematik-Tier) Fachdienste (Service Provider Tier) Die Broker Services als Teil der Telematikinfrastruktur Aufgaben der Telematikinfrastruktur Aufgaben und Ziele der Broker Services...25 gematik_inf_brokerservices_v1_1_0.doc Seite 3 von 175

4 4.3 Die Broker Services im Einzelnen Basisfunktionalität Architektur Deploymentsicht Broker-Instanzen Registrierungsinstanzen Auditinstanzen Netzwerksicht Anbindung VPN-Zugangsnetz Anbindung an das Backend-Netzwerk Sicherheitssicht Kommunikationssicht Broker Service (i. e. S.) Security Services (TrustedS, SVS, SCS) Schnittstellen TrustedS zu SVS und SCS Schnittstelle SVS zum OCSP-Responder Schnittstelle SCS zu Hardware Security-Modul ( Krypto-Box ) Hochverfügbarkeitssicht Aspekte der Hochverfügbarkeit: Cluster, Ausfallsicherheit und Lastverteilung Globales vs. lokales Clustering: Gesamtsicht vs. Betreibersicht Globale Lastverteilung: Sektorales Betreibermodell Globales Failover: Rückfallszenario bei Ausfall eines Betreibers Lokale Lastverteilung innerhalb eines Betreibers Lokales Failover: Ausfallsicherheit innerhalb eines Betreibers Verteilungssicht Physische Architektur von Broker- und Security-Instanzen Netzwerkanbindung von Broker- und Security-Instanzen Verfügbarkeitsstrategie für Broker- und Security-Instanzen Skalierungsstrategie für Broker- und Security-Instanzen Physische Architektur von Auditinstanzen Netzwerkanbindung von Auditinstanzen Verfügbarkeitsstrategie für Auditinstanzen Skalierungsstrategie für Auditinstanzen Konzeptionelle Umsetzung Plattformunabhängigkeit der Services Web Services als plattformunabhängige Remoting-Technologie Remoting, Plattformunabhängigkeit und Performance Versichertenzentrierte Auditierung von Online-Datenzugriffen Verarbeitungssteuerung durch Broker-Sequenzen Begriffsdefinition: Broker-Sequenz Abgrenzung: Servicetypen vs. Broker-Sequenzen Konfiguration Sequenzschritte Sequenzschritt: Auditierung Sequenzschritt: Anonymisierung Sequenzschritt: Fachdienstaufruf Abarbeitung Leersequenz...56 gematik_inf_brokerservices_v1_1_0.doc Seite 4 von 175

5 5.3.6 MessageTrace Fehlerbehandlung Fachlicher Fehler Technischer Fehler in einem aufgerufenen Service Technischer Fehler im Broker Transaktionssicherheit Caching von Verzeichnis-Informationen (SDS Registry Cache) Abwehr von Replay-Attacken Beispielszenarien Beispiel 1: Update Versichertenstammdaten initiieren Beispiel 2: Verordnung dispensieren Sicherheitsaspekte Allgemeine Grundsätze Konformität mit 291a: Zweistufigkeit der Sicherheitsservices Hybride Verschlüsselung aller medizinischen Daten Nachrichtenbasierte Authentisierung Sicherheitszonen und Sicherheitsdienste Konsequenzen aus der Bedrohungsanalyse Grundsätzliche Überlegungen Maßnahmen zur Abwehr konkreter Bedrohungen System Management Perspektiven auf das System Management Zentrale Überwachung der Service Level Agreements Verfügbarkeit (Availability) Lastzahlen und Antwortzeiten (Performance) Dezentrales Monitoring und Management der Broker Services Lokale Monitoringschnittstellen Lokale Managementschnittstellen Serviceübergreifende Festlegungen Verwendung von Standards Telematikweites Protokoll für den Nachrichtenaustausch Spezifikation TelematikTransport-Details TelematikTransport-Adaptierung Struktur der Telematiknachrichten Transport-Header Telematik-Header Security-Header Body (Fachdaten) Beidseitige Authentifizierung auf Transportebene...76 gematik_inf_brokerservices_v1_1_0.doc Seite 5 von 175

6 8.4 Anforderungen aus Netzwerksicht Anforderungen an Web Service-Endpunkte Anforderungen an Web Services-Clients Anforderungen an sonstige TCP-basierte Netzwerkverbindungen TelematikCoreMessage vs. Standard-Szenario für Web Services Konfiguration und Versionierung Konfiguration der Broker Services i. w. S Versionierung in der Telematikinfrastruktur Änderung von Broker-Sequenzen zu einem Stichtag Transparente Versionierung des Fachdiensts Extern sichtbare Versionierung des Fachdiensts über neue URL Versionierung der Transportschnittstelle (Telematiknachricht) Fehlerbehandlung Struktur der Servicebeschreibungen Aufbau der Kapitel zur Servicebeschreibung XML-Schema-Beschreibungen und Web Service-Definitionen Broker Service i. e. S. (BrokerS) Überblick Anforderungen und Annahmen Fachliche Anforderungen Annahmen Konzeptionelle Umsetzung Prüfung der Broker-Sequenz Konfiguration Bestimmen der Broker-Sequenz Lokalisierung mit Hilfe des Verzeichnis-Cache Lokalisierung der Auditinstanzen im Verzeichnis-Cache Lokalisierung der Fachdienste im Verzeichnis-Cache Abarbeiten der Broker-Sequenz Sequenzschritt Auditierung Sequenzschritt Anonymisierung Sequenzschritt Fachdienstaufruf Service-Operationen Operation TelematikExecute Validieren der Nachricht gegen das XML-Schema der TelematikEnvelope Initialisierung und Aktualisierung des Verzeichnis-Cache Service Consumer Schnittstellen Schnittstelle zum Audit Service Schnittstellenbeschreibung AuditS:WriteAudit Schnittstelle zu den Security Services (hier: TrustedS) Schnittstellenbeschreibung TrustedS:Anonymize Schnittstelle zum Registrierungsdienst (SDS)...97 gematik_inf_brokerservices_v1_1_0.doc Seite 6 von 175

7 Schnittstellenbeschreibung SDS:get_registeredInfo Schnittstellenbeschreibung SDS:find_binding Schnittstellenbeschreibung SDS:get_bindingDetails Schnittstellenbeschreibung SDS:find_service Schnittstelle zu den Fachanwendungen Schnittstellenbeschreibung <Fachdienst>:Execute Konfiguration Fehlerhandling Management- und Monitoringschnittstelle Audit Service (AuditS) Überblick Anforderungen und Annahmen Fachliche Anforderungen Annahmen Konzeptionelle Umsetzung Datenpflege Versichertenindividuelle Verschlüsselung Kartenabhängiges symmetrisches Master-Key-Verfahren Verschlüsselte Auditierung Lesezugriff auf das Auditprotokoll Datenerhalt: Historie kartenabhängiger Pseudonyme Auditinformationen Datenelemente für Auditeinträge Struktur der AuditMessage Ermittlung der Audit Service-Instanz für einen Versicherten Schutz der Integrität der Auditprotokolle Service-Operationen WriteAudit Request Response Service Consumer Schnittstellen Konfiguration Fehlerhandling Management- und Monitoringschnittstelle Security Services Überblick Anforderungen und Annahmen Fachliche Anforderungen Annahmen Konzeptionelle Umsetzung Service-Operationen gematik_inf_brokerservices_v1_1_0.doc Seite 7 von 175

8 Operation Anonymize (Trusted Service) Operation Validate (Security Validation Service) Operation Sign (Security Confirmation Service) Service Consumer Schnittstellen Schnittstelle zum OCSP-Responder Konfiguration Fehlerhandling Management- und Monitoringschnittstelle Service Level Objectives und Volumenmodell Einordnung Segmentierung der SLOs: Segment Broker-Operationen Mengengerüste Verfügbarkeitsanforderungen Verfügbarkeitskategorien Verfügbarkeitsziele für das Segment Broker-Operationen Antwortzeitverhalten Antwortzeitziele Antwortzeitvorgaben für das Segment Broker-Operationen Fehlermanagement, Logging und Tracing Fehlermanagement Abgrenzung: Fehler als unerwartete Abweichungen Informationsmodell: Fehlerschlüssel und Fehlerdetails Fehlerschlüssel Fehlerdetails Anforderungen an die Fehlerbehandlung Transport von Fehlern in der Telematikinfrastruktur Persistentes Speichern von Fehlern in der Telematikinfrastruktur Bereitstellung von Fehlerschlüsseln für das System Management Normative Fehlermeldungen in den Broker Services Logging und Tracing Begriffsbestimmung: Logging vs. Tracing Konzepte für das Logging und Tracing Loglevel Logger Appender Layouts Anforderungen an die Logging- und Tracing-Komponente Datensicherheit Regeln für Log-Meldungen ohne konkreten Fehlerbezug Regeln für Log-Meldungen mit konkretem Fehlerbezug gematik_inf_brokerservices_v1_1_0.doc Seite 8 von 175

9 Anhang A A1 Abkürzungen A2 - Glossar A3 - Abbildungsverzeichnis A4 - Tabellenverzeichnis A5 - Referenzierte Dokumente Anhang B: Leseanleitung für XML-Schema-Fragmente Anhang C: XML-Schema für die Konfiguration der Broker-Sequenzen Anhang D: Broker-Sequenzen Offene Punkte gematik_inf_brokerservices_v1_1_0.doc Seite 9 von 175

10 1 Zusammenfassung Mit Verabschiedung des Gesetzes zur Modernisierung der gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz GMG) wurde die Einführung der elektronischen Gesundheitskarte (egk) für das deutsche Gesundheitswesen beschlossen. 291b des Fünften Sozialgesetzbuches (SGB V), welches zum in Kraft getreten ist, fordert in der Konsequenz den Aufbau und Betrieb der für die Einführung und Anwendung der egk erforderlichen Telematikinfrastruktur. Innerhalb dieser Infrastruktur sind zentrale Brokerdienste bereitzustellen, welche zur Vermittlung von Nachrichten innerhalb der Telematikinfrastruktur zwischen den Konnektoren, Fachdiensten und anderen mittelbaren oder unmittelbaren Diensten dienen. Die sogenannten Broker Services (i. w. S.) bestehen aus mehreren miteinander interagierenden Diensten: Broker Service (BrokerS i. e. S.), Registrierungsdienst (Service Directory Service, SDS), Audit Service (AuditS) sowie Trusted Service (TrustedS) mit den Unterservices Security Validation Service (SVS) und Security Confirmation Service (SCS). Bis auf den Registrierungsdienst (SDS) erfolgen die Spezifikationen all dieser Services in diesem Dokument. Der Registrierungsdienst wird im Dokument [gemregd] beschrieben, weil er eine standardisierte Schnittstelle implementiert, während die oben genannten Dienste Individuallösungen darstellen. Der Broker Service vermittelt auf der Basis von Aufrufketten, den sog. Broker-Sequenzen, Telematiknachrichten innerhalb der Telematikinfrastruktur. Mittels des Registrierungsdiensts (SDS) lokalisiert er die zu adressierenden Fachdienste. Durch Einbeziehung des Trusted Service und der nachgelagerten Dienste SVS und SCS anonymisiert er bestimmte Nachrichtentypen, indem er Signaturen von Heilberuflern validiert, die Rolle aus dem zur Signatur gehörigen Zertifikat in die Nachricht überträgt und durch eine eigene Signatur bestätigt. Der Audit Service protokolliert versichertenzentriert alle Online-Zugriffe auf die Telematikinfrastruktur. Das Konzept der Broker Services basiert auf dem serviceorientierten Architekturansatz ({SOA}) unter Verwendung eines intermediären Kommunikationsstils. Physisch werden die Broker Services als lastverteilte Mehrschichtarchitektur umgesetzt, wobei vor allem die Hochverfügbarkeit der Dienste im Vordergrund steht. gematik_inf_brokerservices_v1_1_0.doc Seite 10 von 175

11 2 Einführung 2.1 Zielsetzung und Einordnung des Dokumentes Die Einführung der elektronischen Gesundheitskarte bedingt den Betrieb verschiedener verteilter Dienste und Komponenten, angefangen von dezentralen Komponenten, wie dem Konnektor, über zentrale Dienste der Telematikinfrastruktur wie Vermittlungs- und Anonymisierungsdienste, Lokalisierungsdienste, Zertifikatserstellungs- und prüfungsdienste (PKI). Gegenstand dieses Dokuments ist die Spezifikation der sog. Broker Services als der zentralen dienstevermittelnden ( intermediären ) Komponente der Telematikinfrastruktur. Die Spezifikation von Protokollen, Komponenten und Diensten im Kontext der Broker Services erfolgt insbesondere mit Sicht auf den Broker als Gateway-Komponente zu den Fachanwendungen, die mit Hilfe von Web Service-Technologien zu implementieren ist. Die Vertraulichkeit und Integrität der vom Broker bearbeiteten Daten wird dabei durch Verschlüsselung und Signatur auf der Basis kryptographischer Verfahren umgesetzt. Zusätzliche Sicherheit wird gewährleistet durch den Betrieb eines abgesicherten Netzes, das nur Benutzergruppen zugänglich ist, die nachweislich authentisiert wurden sowie Komponenten nutzen und Dienste verwenden, deren Authentizität und Zulassungsstatus verifizierbar ist. Diese Spezifikation baut auf der Gesamtarchitektur für die Einführung der Gesundheitskarte [gemgesarch] auf und berücksichtigt dadurch die Architekturentscheidungen der Gesellschafter der gematik und des Architekturboards. Das Gesamtarchitektur-Dokument ist Grundlage und Ausgangspunkt des vorliegenden Dokuments. Wo es zur eigenständigen Lesbarkeit dieser Spezifikation 1 erforderlich ist, werden bewusst Redundanzen in Kauf genommen und Inhalte aus der Gesamtarchitektur wiedergegeben. Diese Stellen sind dann aber eindeutig durch Verweise auf die entsprechenden Abschnitte bzw. Abbildungen aus der Gesamtarchitektur gekennzeichnet. Im Zweifelsfall haben die Festlegungen des Gesamtarchitektur-Dokumentes Vorrang. 2.2 Aufbau und Inhalt des Dokuments Die Spezifikation des Broker Service umfasst die folgenden Themenbereiche: Kapitel 1 Zusammenfassung Kapitel 1 fasst im Sinne eines Management Summary die inhaltlichen Kernaussagen dieses Dokumentes zusammen. 1 d. h. unabhängig davon, ob dem Leser gleichzeitig auch das Gesamtarchitektur-Dokument [gemgesarch] vorliegt gematik_inf_brokerservices_v1_1_0.doc Seite 11 von 175

12 Kapitel 2 Einführung Das vorliegende Kapitel 2 beschreibt die Zielsetzung, Gliederung, Zielgruppen, Geltungsbereich, Arbeitsgrundlagen und Rahmenbedingungen für dieses Dokument sowie die Abgrenzung zu anderen, thematisch verwandten Dokumenten. Kapitel 3 Anforderungen und Annahmen Im Rahmen des Kapitels Anforderungen werden die wichtigsten funktionalen und nichtfunktionalen Anforderungen an die Broker Services als der zentralen Vermittlungskomponente tabellarisch erfasst. Spätere Dokumentteile referenzieren diese Anforderungen, um den Bezug zwischen Lösungsvorschlag und Problemstellung herzustellen. Anforderungen, die sich auf die Spezifikation anderer Komponenten beziehen und dort noch nicht abschließend festgelegt sind, werden gesondert als Annahmen aufgeführt. Sie dienen als Arbeitshypothesen bis zu ihrer Bestätigung im Rahmen des Anforderungsmanagements. Diese Verfahrensweise ist notwendig, da wesentliche Teile der fachlichen und technischen Spezifikationen der gematik aktuell parallel zu diesem Dokument entstehen und somit die Konsistenz von Anforderungen nicht abschließend prüfbar ist. Kapitel 4 Die Broker Services im Überblick Der Überblick beschreibt Zweck, Grundlagen, Basisfunktionalität und die Grobstruktur der Broker Services. Ausgangspunkt sind dabei die in Kapitel 3 formulierten Anforderungen sowie andere referenzierte Dokumente, insbesondere die Gesamtarchitektur [gemgesarch], die Bedrohungs- und Risikonanalyse [gembur] und das Netzwerkkonzept [gemnet]. Hierzu wird die Einordnung der Broker Services in die Telematik-Tier der Gesamtarchitektur hergeleitet, die Basisfunktionalität und zugrunde liegende Architektur beschrieben sowie eine Trennung der Sicherheits- und Funktionsbereiche vorgenommen und erklärt. Außerdem werden die detaillierteren technischen Spezifikationen in den folgenden Abschnitten begründet. Kapitel 5 Konzeptionelle Umsetzung In diesem Kapitel werden einige konzeptionelle Hintergründe zur gewählten Architektur näher beleuchtet bzw. auf geeignete Abschnitte der Gesamtarchitektur [gemgesarch] verwiesen, in denen weiterführende Informationen zu finden sind. Es wird insbesondere das Konzept der Broker-Sequenzen eingeführt, über die sich die durchzuführenden Abarbeitungsschritte für eine beim Broker eintreffende Nachricht in Abhängigkeit vom Servicetyp flexibel konfigurieren lassen. Außerdem werden zwei Beispiele für Broker-Sequenzen zur Abbildung fachlicher Use Cases angegeben. gematik_inf_brokerservices_v1_1_0.doc Seite 12 von 175

13 Kapitel 6 Sicherheitsaspekte Die wichtigsten Grundsätze der Sicherheitsarchitektur für die Telematikinfrastruktur und die aus der Bedrohungsanalyse resultierenden Konsequenzen für die Spezifikation der Broker Services werden erläutert. Kapitel 7 System Management Die Konfiguration und insbesondere der laufende Betrieb des Brokers und der ihm zugeordneten Services müssen sorgfältig geplant und ständig überwacht werden. In Erfüllung ihrer Betriebsverantwortung überwacht die gematik die Einhaltung von Service Level Agreements durch die Betreiber von Broker-Instanzen mit Hilfe von Agenten, die Testnachrichten an die Broker-Komponenten senden. Eine nähere Spezifikation erfolgt in [gemsysmgmt]. Ergänzend stellen die Broker Services ein eigenes Management- und Monitoring-API für die lokale Überwachung und Sicherstellung der Service Level Agreements durch die Betreiber zur Verfügung. Kapitel 8 Serviceübergreifende Festlegungen In diesem Kapitel werden alle Festlegungen von serviceübergeifendem Charakter getroffen, die in gleicher Weise für die in den Kapiteln 10 bis 12 beschriebenen Services gelten. Dazu gehören die zu verwendenden Standards und Kompatibilitätsanforderungen, die Definition der Telematiknachrichtenstruktur, Anforderungen zu Konfigurationsmanagement und Versionierung sowie zur fachlichen Fehlerbehandlung. Kapitel 9 Struktur der Servicebeschreibungen Dieses Kapitel definiert die Struktur der Servicebeschreibungen für die einzelnen Schnittstellen, wie sie für die Beschreibung der Services in den Kapiteln 10 bis 12 verwendet wird. Kapitel 10 Broker Service i. e. S. (BrokerS) In diesem Kapitel wird der Broker Service i. e. S. als zentraler Verteilerknoten der Telematikinfrastruktur im Detail spezifiziert. Kapitel 11 Audit Service (AuditS) Dieses Kapitel beschreibt die Detailfunktionalität sowie die Schnittstellen des Audit Service. Dieser Dienst übernimmt die versichertenzentrierte Auditierung von Zugriffen auf die Fachdienste über die Telematikinfrastruktur. Kapitel 12 Security Services (SVS, SCS, TrustedS) Im Kapitel 12 werden die Security Services spezifiziert: Auf der Strecke zwischen Konnektoren (Service-Consumer-Tier) und Fachdiensten (Service- Provider-Tier) anonymisiert der Broker mit Hilfe der Security Services, gematik_inf_brokerservices_v1_1_0.doc Seite 13 von 175

14 abhängig von der eingehenden Nachricht, die Heilberufler-Identitäten in der Nachrichten. Kapitel 12 Security Services (SVS, SCS, TrustedS) Im Kapitel 12 werden die Security Services spezifiziert: Auf der Strecke zwischen Konnektoren (Service-Consumer-Tier) und Fachdiensten (Service- Provider-Tier) anonymisiert der Broker mit Hilfe der Security Services, abhängig von der eingehenden Nachricht, die Heilberufler-Identitäten in der Nachrichten. Kapitel 13 Service Level Objectives und Volumenmodell In Ergänzung der nicht-funktionalen Anforderungen ist in betrieblicher Hinsicht die detaillierte Formulierung spezieller Zielgrößen für die Dienstgüte (Quality of Service) erforderlich. Diese werden als Service Level Objectives {SLO} bezeichnet. Die endgültige Festlegung konkreter Service Level Objectives für die Broker Services kann erst nach der Definition detaillierter Mengengerüste für die einzelnen fachlichen Use Cases (anstelle der augenblicklichen Grundsatzannahmen zum Volumenmodell) und eingehender Abstimmung mit verschiedenen Arbeitsgruppen der gematik erfolgen und in dieses Dokument mit aufgenommen werden. Kapitel 14 Fehlermanagement, Logging und Tracing Das Kapitel beschäftigt sich mit den Anforderungen an das Fehlermanagement innerhalb der Broker Services sowie den Anforderungen an ein Logging und Tracing-Framework. Dieses Dokument ist unter der Prämisse entstanden, dass die Spezifikation in ihrer Gesamtheit Herstellerunabhängigkeit und Produktneutralität gewährleisten muss. Dies bedingt, dass die Spezifikation in ihrer Gesamtheit wesentlich allgemeiner bleiben muss als bei einer Orientierung an proprietären Lösungen, da sie nur auf herstellerübergreifenden Standards aufbauen kann. Der Vorteil dieses Verfahrens liegt jedoch in der Offenheit, Stabilität und Verfügbarkeit vieler alternativer Produkte bzw. Frameworks für die Implementierung einer Lösung zu einer konkreten Problemstellung. 2.3 Zielgruppe Dieses Dokument richtet sich primär an: die Beteiligten im Angebotsprozess bzw. bei der Vertragsgestaltung für die Entwicklung und Implementierung des Broker Services (seitens gematik und seitens des jeweiligen Anbieters/Vertragspartners) Business-Analysten, Architekten und Entwickler desjenigen Anbieters/Unternehmens, das Vertragspartner für die Entwicklung und Implementierung ist bzw. wird. die Rechtsabteilung der gematik (mittelbar) gematik_inf_brokerservices_v1_1_0.doc Seite 14 von 175

15 die Arbeitsgruppe Entwicklung der gematik (als Leitfaden für eine prototypische Implementierung der Broker Services) die Beteiligten bei der Vertragsgestaltung für den Produktionsbetrieb der Broker Services (seitens gematik und seitens des jeweiligen Anbieters/Vertragspartners). alle sonstigen Personen und/oder Institutionen innerhalb und außerhalb der gematik, die mittelbar oder unmittelbar an Architektur, Design, Entwicklung, Betrieb und System Management der Software- und Infrastrukturkomponenten für die Broker Services beteiligt sind. 2.4 Geltungsbereich Alle in diesem Dokument vorgenommenen Festlegungen sind im Kontext der Telematikinfrastruktur des Gesundheitswesens als verbindlich zu betrachten, außer dort, wo dies explizit ausgewiesen wird. 2.5 Arbeitsgrundlagen Grundlage für die Spezifikation der Broker Services bilden die Anforderungen und Festlegungen aus den folgenden Dokumenten: gematik Gesamtarchitektur [gemgesarch] gematik Bedrohungs- und Risikoanalyse [gembur] nicht öffentlich gematik Schutzbedarfsfeststellung [gemschbedf] nicht öffentlich gematik Sicherheitsanforderungen an die Infrastrukturdienste Broker Services [gemsha_br] gematik Sicherheitsanforderungen an die Infrastrukturdienste Allgemeiner Teil [gemsha_allg] gematik Netzwerkspezifikation [gemnet] gematik Spezifikation Fehlerbehandlung [gemspec_fm] gematik System und Service Level Monitoring [gemsysslm]. gematik Spezifikation TelematikTransport-Details [gemspec_ttd] gematik Spezifikation von Versionsnummern in Schnittstellendefinitionen und Software-Komponenten [gemspec_versnr] gematik Policy [gempolicy] gematik Anforderungen aus Sicht der Wartbarkeit und Änderbarkeit der TI (in Vorbereitung) [gemga_wartg] gematik_inf_brokerservices_v1_1_0.doc Seite 15 von 175

16 gematik Spezifikation des Registrierungsdienstes [gemregd] Diese wie alle weiteren in diesem Konzeptpapier referenzierten fachlichen und technischen Dokumente sind in Anhang A5 aufgelistet. 2.6 Abgrenzung des Dokuments Nicht im Fokus dieses Dokuments sind konzeptionelle Überlegungen zu Netzwerk- Infrastruktur und -Routing, sowie zum Namensdienst (DNS) und Systemzeitdienst (NTP). Existenz und Verfügbarkeit dieser physikalischen und logischen Komponenten werden allerdings vorausgesetzt. Details hierzu finden sich in [gemnet] und [gemntp]. Ebenfalls nicht im Fokus der Betrachtungen sind die Ausprägung anderer Telematikinfrastruktur- und Anwendungsschicht-Dienste (z. B. Verzeichnisdienste, PKI, Datenbank- Anwendungen, etc.) sowie betriebliche Belange. Diesbezüglich wird auf die Arbeitsergebnisse der anderen Arbeitsgruppen der gematik verwiesen. Dieses Dokument macht mit Absicht keinerlei Aussagen oder Empfehlungen hinsichtlich der zu verwendenden Softwareprodukte, Frameworks oder Hardwareplattformen und ist somit insbesondere herstellerneutral. Im Dokument wird mehrfach der Begriff Web Service Provider bzw. von Web Service Consumer verwendet. Diese Begriffe werden hier im Kontext einer serviceorientierten Architektur verwendet. Dieses Konzept basiert auf einer Anzahl voneinander unabhängiger, lose gekoppelter Dienste. Ein Dienst wird von einem Service Provider angeboten. Ein Service Consumer stellt eine Anfrage (Service Request) an einen Dienst und empfängt daraufhin eine Antwort (Service Response) vom Anbieter. Für den Zugriff aus der Consumer Tier (Primärsysteme der Leistungserbringer) ist dabei nur die Schnittstelle zwischen dem Consumer Adapter (Konnektor) und dem Broker Service i. e. S. (siehe Kapitel 10) relevant. Alle übrigen hier beschriebenen Services stellen also keine Funktionalität der Telematik Tier bzw. Service Provider Tier nach außen zur Verfügung. 2.7 Verwendung von Schlüsselworten und Konventionen Verwendung von Schlüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden und in Großbuchstaben geschriebenen deutschen Schlüsselworte verwendet: MUSS. Absolut gültige und normative Festlegungen sind durch das Schlüsselwort MUSS gekennzeichnet. DARF NICHT. Absolut gültige und normative Ausschlüsse sind durch das Schlüsselwort DARF NICHT gekennzeichnet. SOLL. Empfehlungen zu Festlegungen sind durch das Schlüsselwort SOLL gekennzeichnet. Abweichungen sind in begründeten Fällen möglich. gematik_inf_brokerservices_v1_1_0.doc Seite 16 von 175

17 SOLL NICHT. Empfehlungen zu Ausschlüssen sind durch das Schlüsselwort SOLL NICHT gekennzeichnet. Abweichungen sind in begründeten Fällen möglich. KANN bzw. Vollständig fakultative Eigenschaften sind durch das Schlüsselwort KANN gekennzeichnet und haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. OPTIONAL. Wahlweise freigestellte Funktionen sind durch das Schlüsselwort OPTIONAL gekennzeichnet. Sie haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. Jedoch muss bei Verzicht auf die Eigenschaften die uneingeschränkte Funktionalität des beschriebenen Sachverhaltes sichergestellt sein Konventionen zur Kennzeichnung von Referenzen und Abkürzungen Referenzen auf weitere Dokumente und Standards sind in [eckige Klammern] gesetzt und werden im Anhang aufgelöst. Abkürzungen werden bei ihrer ersten Verwendung in {geschweifte Klammern} gesetzt und werden im Abkürzungsverzeichnis aufgelöst Konventionen zur Kennzeichnung von Architektur-Tiers Die Gesamtarchitektur unterscheidet insgesamt sechs Tiers (engl. Fachbegriff für Architekturebene; siehe [gemgesarch], Abschnitt 5: Logische Architektur Tier- und Systemgrenzen). Abbildung 1: Architektur-Tiers und Systemgrenzen In den Abbildungen werden wo immer möglich die folgenden farblichen Konventionen für die Tiers verwendet: Komponenten, Services und Funktionen der Service-Consumer und -Adapter Tiers sind ROT markiert Komponenten, Services und Funktionen der Telematik und Provider-Adapter-Tiers sind GELB markiert Komponenten, Services und Funktionen des Service-Provider-Tiers sind GRÜN markiert gematik_inf_brokerservices_v1_1_0.doc Seite 17 von 175

Einführung der Gesundheitskarte Gesamtarchitektur

Einführung der Gesundheitskarte Gesamtarchitektur Einführung der Gesundheitskarte Gesamtarchitektur Version: 1.5.0 Revision: main/rel_main/rel_r2.3.4/2 Stand: 02.09.2008 Status: freigegeben gematik_ga_gesamtarchitektur.doc Seite 1 von 325 Dokumentinformationen

Mehr

Manuel Koch, Dr. Herbert Bunz 10. September 2009. Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik

Manuel Koch, Dr. Herbert Bunz 10. September 2009. Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik Manuel Koch, Dr. Herbert Bunz 10. September 2009 Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik 2009 gematik 2009 IBM Corporation Der Patient kann selbstbestimmt

Mehr

Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur

Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur Dr. Stefan Buschner gematik - Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117 Berlin

Mehr

Die Umsetzung im Krankenhaussektor

Die Umsetzung im Krankenhaussektor Basis-Rollout Die Umsetzung im Krankenhaussektor Dipl.-Ing. (FH) Helga Mesmer Folie 1 Gliederung Einführung 1. Gesundheits-Telematik-Infrastruktur Die Gesamtarchitektur 2. Anwendungen der egk Eine Übersicht

Mehr

Architektur, Datenschutz und Informationssicherheit der Gesundheitstelematik

Architektur, Datenschutz und Informationssicherheit der Gesundheitstelematik Architektur, Datenschutz und Informationssicherheit der Gesundheitstelematik Die Sicherheitsarchitektur - Grundlage für die Absicherung sensibler Daten Michael Bartkowiak Leiter IT-Strategie Sven Marx

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

Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007

Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007 Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007 1 Die Wahrnehmung der Patienten Der Umfang und die Qualität der

Mehr

Einführung der Gesundheitskarte

Einführung der Gesundheitskarte Einführung der Gesundheitskarte Facharchitektur Version: 2.5.0 Stand: 14.03.2008 Status: freigegeben gematik_vsd_facharchitektur_vsdm_2.5.0.doc Seite 1 von 120 Dokumentinformationen Änderungen zur Vorversion

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Smartcard-Workshop Darmstadt, 9. Februar 2012 Georgios Raptis Bundesärztekammer Notfalldatensatz auf der egk 2003 291a SGB V die egk

Mehr

Einführung der Gesundheitskarte Spezifikation Fehlerbehandlung

Einführung der Gesundheitskarte Spezifikation Fehlerbehandlung Einführung der Gesundheitskarte Spezifikation Version: 1.3.0 Stand: 18.12.2007 Status: freigegeben gematik_ga_spezifikation V1_3_0.doc Seite 1 von 50 Dokumentinformationen Änderungen zur Vorversion Eine

Mehr

E-POSTBRIEF Sicherheit in der digitalen Schriftkommunikation

E-POSTBRIEF Sicherheit in der digitalen Schriftkommunikation E-POSTBRIEF Sicherheit in der digitalen Schriftkommunikation Dr. André Wittenburg, Vice President Architektur & Plattformstragie i2b, Bremen, Februar 2012 1 Der E-Postbrief: Ein kurzer Überflug 2 Sicherheit

Mehr

Festlegungen zu den Notationen

Festlegungen zu den Notationen Einführung der Gesundheitskarte Festlegungen zu den Notationen von Schlüsseln und Zertifikaten kryptographischer Objekte in der TI Version: 1.0.0 Stand: 17.03.2008 Status: freigegeben gematik_pki_notationen_schl_und_zert_v1.0.0.doc

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

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

Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten

Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten Version: 1.0.0 Stand: 23.07.2012 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [geminfo_g2_karten] Autor:

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

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

VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN

VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN Marcel Huth, 31.07.2008 VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN Schwerpunkt DVDV und SAFE Huth, Strack Inhalt 1. Allgemeines zu Verzeichnisdiensten 2. Das Projekt DVDV 1. Allgemeines 2. Komponenten

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen RWE Effizienz GmbH Flamingoweg 1 44139 Dortmund für das IT-System RWE eoperate IT Services die Erfüllung aller

Mehr

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 ÖSTERREICH RECHNET MIT UNS Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 www.brz.gv.at BRZ GmbH 2015 AGENDA Ausgangsbasis Webservice bei E-RECHNUNG.GV.AT SERWS Ziele

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Dynamische Web-Anwendung

Dynamische Web-Anwendung Dynamische Web-Anwendung Christiane Lacmago Seminar Betriebssysteme und Sicherheit Universität Dortmund WS 02/03 Gliederung Einleitung Definition und Erläuterung Probleme der Sicherheit Ziele des Computersysteme

Mehr

Sichere Kommunikation für SOAP-basierte Web Services

Sichere Kommunikation für SOAP-basierte Web Services Whitepaper SOA Security Framework Sichere Kommunikation für SOAP-basierte Web Services Holger Junker, BSI, soa@bsi.bund.de Die Sicherheitsanforderungen an SOA Infrastrukturen und den darin stattfindenden

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Softwaregestütztes Einwilligungsmanagement

Softwaregestütztes Einwilligungsmanagement Softwaregestütztes Einwilligungsmanagement Vom Konzept zum Prototyp Berlin, 24. März 2010 Markus BIRKLE, Oliver Heinze, Lennart Köster, Björn Bergh Sektion Medizinische Informationssysteme Agenda Begriffsbestimmung

Mehr

Sektorübergreifende Zusammenarbeit mit EFA 2.0 und Telematikinfrastruktur

Sektorübergreifende Zusammenarbeit mit EFA 2.0 und Telematikinfrastruktur Sektorübergreifende Zusammenarbeit mit EFA 2.0 und Telematikinfrastruktur Dr. Andreas Kerzmann Projektleiter P75 GDD/EFA gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen SLA Software Logistik Artland GmbH Friedrichstraße 30 49610 Quakenbrück für das IT-System Meat Integrity Solution

Mehr

Einführung der Gesundheitskarte Spezifikation TelematikTransport-Details

Einführung der Gesundheitskarte Spezifikation TelematikTransport-Details Einführung der Gesundheitskarte Spezifikation Version: 1.6.0 Revision: main/rel_main/rel_r2.3.x/9 Stand: 27.06.2008 Status: freigegeben gematik_ga_spezifikation_telematik-transport-details.doc Seite 1

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

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur

Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Version: 1.3.0 Stand: 26.03.2008 Status: freigegeben gematik_ga_spezifikation_kryptographischer_algorithmen_v1_3_0.doc Seite

Mehr

Nutzerbeirat 2012 Bonn 20.11.2012

Nutzerbeirat 2012 Bonn 20.11.2012 Der neue Personalausweis Einsatzmöglichkeiten in der Lucom Interaction Platform Nutzerbeirat 2012 Bonn 20.11.2012 Henning Meinhardt Leiter Software Entwicklung Ab Version 3.2.2 unterstützt die LIP den

Mehr

Dialog ehealth. " Einführung der elektronischen Gesundheitskarte 2006 - planen, prüfen, praktisch proben"

Dialog ehealth.  Einführung der elektronischen Gesundheitskarte 2006 - planen, prüfen, praktisch proben Dialog ehealth " Einführung der elektronischen Gesundheitskarte 2006 - planen, prüfen, praktisch proben" GoCard! das Projekt der DAK zur Einführung der elektronischen Gesundheitskarten bei der DAK Michael

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Elektronische Gewerbemeldung

Elektronische Gewerbemeldung E-Government in der IHK-Organisation Elektronische Gewerbemeldung Arbeitshilfe für die Prozess-Implementierung: Technische Rahmenbedingungen für die Anlieferung von Gewerbemeldungen an die IHK-Organisation

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Agfa HealthCare GmbH Konrad-Zuse-Platz 1-3 53227 Bonn für das IT-System IMPAX/web.Access die Erfüllung aller

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

VPN / Tunneling. 1. Erläuterung

VPN / Tunneling. 1. Erläuterung 1. Erläuterung VPN / Tunneling Ein virtuelles privates Netzwerk (VPN) verbindet die Komponenten eines Netzwerkes über ein anderes Netzwerk. Zu diesem Zweck ermöglicht das VPN dem Benutzer, einen Tunnel

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

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

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Positionspapier: Portalverbund und ehealth

Positionspapier: Portalverbund und ehealth Positionspapier: Portalverbund und ehealth e-government Arbeitsgruppe Integration und Zugänge (AG-IZ) Dr. Wilfried Connert Franz Hoheiser-Pförtner, MSc Rainer Hörbe Peter Pfläging Juli 2009 Inhalt Zielsetzung

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

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda Test nichtfunktionaler in der Praxis am Beispiel einer netzzentrierten Anwendung Februar 2011 Test nichtfunktionaler Agenda 1. 2. 3. 4. 5. 6. TAV Tagung Februar 2011 Julia Remmert Public Wincor Nixdorf

Mehr

Sicherheit integrierter Gebäudesysteme - Bedrohungsszenarien, Lösungsansätze - Markus Ullmann

Sicherheit integrierter Gebäudesysteme - Bedrohungsszenarien, Lösungsansätze - Markus Ullmann Sicherheit integrierter Gebäudesysteme - Bedrohungsszenarien, Lösungsansätze - Markus Ullmann Bundesamt für Sicherheit in der Informationstechnik (BSI) Connected Living 2013 Agenda Studie: Integrierte

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

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Band M, Kapitel 5: Server

Band M, Kapitel 5: Server 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

Einführung der Gesundheitskarte Netzwerkspezifikation

Einführung der Gesundheitskarte Netzwerkspezifikation Einführung der Gesundheitskarte Netzwerkspezifikation Version: 1.5.0 Stand: 15.11.2007 Status: freigegeben gematik_inf_netzwerkspezifikation_v1_5_0.doc Seite 1 von 128 Dokumentinformationen Änderungen

Mehr

Die elektronische Gesundheitskarte Herausforderung und Chancen für die Krankenkassen

Die elektronische Gesundheitskarte Herausforderung und Chancen für die Krankenkassen Die elektronische Gesundheitskarte Herausforderung und Chancen für die Krankenkassen Themenabend der Gesellschaft für Informatik am 23.02.2010 IT im Gesundheitswesen Die elektronische Gesundheitskarte

Mehr

BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter

BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter Alex Didier Essoh und Dr. Clemens Doubrava EuroCloud Deutschland_eco e.v. Köln 02.02.2011 Ziel Ziel des BSI ist es, gemeinsam mit den Marktteilnehmern

Mehr

R016 Beilage 5: SOA-Glossar

R016 Beilage 5: SOA-Glossar Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB R016 Beilage 5: SOA-Glossar Ausgabedatum: 2015-02-25 Version: 2.01 Status: Genehmigt Ersetzt: 2.0 Verbindlichkeit: Weisung

Mehr

Inhaltsverzeichnis. 2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 17

Inhaltsverzeichnis. 2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 17 xi 1 Einleitung 1 1.1 Warum REST?...................................... 1 1.1.1 Lose Kopplung................................ 2 1.1.2 Interoperabilität............................... 3 1.1.3 Wiederverwendung.............................

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

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

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

Jörg Knaupp. Cryptomathic München

Jörg Knaupp. Cryptomathic München Kryptografie- Management durch Crypto as a Service Jörg Knaupp Cryptomathic München Cryptomathic Firmenüberblick Headquarter History Aarhus, Dänemark Gegründet 1986 von Kryptogafieexperten der Universitat

Mehr

IT-Security on Cloud Computing

IT-Security on Cloud Computing Abbildung 1: IT-Sicherheit des Cloud Computing Name, Vorname: Ebert, Philipp Geb.: 23.06.1993 Studiengang: Angewandte Informatik, 3. FS Beruf: IT-Systemelektroniker Abgabedatum: 08.12.2014 Kurzfassung

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

Session Initiation Protocol

Session Initiation Protocol Session Initiation Protocol Funktionsweise, Einsatzszenarien, Vorteile und Defizite von Dipl. Inform. Petra Borowka Markus Schaub Seite i Inhaltsverzeichnis INHALTSVERZEICHNIS I 1 MOTIVATION 1-1 1.1 Die

Mehr

Kompetenz der GAIN-Gruppe im Gesundheitswesen. Kompetenz der GAIN-Gruppe im Gesundheitswesen 1

Kompetenz der GAIN-Gruppe im Gesundheitswesen. Kompetenz der GAIN-Gruppe im Gesundheitswesen 1 Kompetenz der GAIN-Gruppe im Gesundheitswesen Kompetenz der GAIN-Gruppe im Gesundheitswesen 1 bis 2005: Arbeiten überwiegend im Kostenträgerumfeld Entwicklung einer Software für den Außendienst (Akquisition

Mehr

Kommunikation in der Intersektoralen Versorgung

Kommunikation in der Intersektoralen Versorgung Kommunikation in der Intersektoralen Versorgung Dr. Gert Funkat funkat@imise.uni-leipzig.de Was ist ISV? Das Informationsdilemma Die Information, die Du hast, ist nicht die, die Du willst Die Information,

Mehr

Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell

Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell F. Burchert, C. Hochberger, U. Kleinau, D. Tavangarian Universität Rostock Fachbereich Informatik Institut für Technische

Mehr

CDN services sicherheit. Deutsche Telekom AG

CDN services sicherheit. Deutsche Telekom AG CDN services sicherheit Deutsche Telekom AG International Carrier Sales and Solutions (ICSS) CDN Services Sicherheit Sichere und stets verfügbare Websites Integriert und immer verfügbar Dank der Cloud-/Edge-basierten

Mehr

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences WISSENSCHAFTLICHE WEITERBILDUNG Fernstudium Industrial Engineering Produktions- und Betriebstechnik Kurseinheit 98 und

Mehr

Astaro Mail Archiving Service Version 1.0

Astaro Mail Archiving Service Version 1.0 Astaro Mail Archiving Service Version 1.0 Verfahrensdokumentation Inhaltsverzeichnis 1. Einleitung... 2 2. Übersicht... 2 2.1 Production-Cloud... 3 2.2 Backup-Cloud... 3 2.3 Control-Cloud... 3 2.4 Zugangsschutz...

Mehr

Reporting Services Dienstarchitektur

Reporting Services Dienstarchitektur Reporting Services Dienstarchitektur Reporting Services Dienstarchitektur In Reporting Services wird ein Berichtsserver als ein Windows - Dienst implementiert, der aus unterschiedlichen Featurebere i-

Mehr

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release White Paper Konfiguration und Verwendung des Auditlogs 2012 Winter Release Copyright Fabasoft R&D GmbH, A-4020 Linz, 2011. Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen

Mehr

Programmierhandbuch SAP NetWeaver* Sicherheit

Programmierhandbuch SAP NetWeaver* Sicherheit Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit

Mehr

Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte.

Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte. Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte. 3. Kann ich nicht einfach meine alte Krankenversichertenkarte behalten? Die elektronische Gesundheitskarte ist

Mehr

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com Von 0 auf SOA in 10 Schritten Stefan Tilkov innoq stefan.tilkov@innoq.com 1 Stefan Tilkov Geschäftsführer und Principal Consultant, innoq Deutschland GmbH Fokus auf SOA, Web-Services, REST SOA-Editor InfoQ.com

Mehr

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure)

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Unterrichtseinheit 5: Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Verschlüsselung mit öffentlichen Schlüsseln ist eine bedeutende Technologie für E- Commerce, Intranets,

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Anforderungen an die langfristige, veränderungssichere Aufbewahrung elektronischer Dokumente.

Anforderungen an die langfristige, veränderungssichere Aufbewahrung elektronischer Dokumente. Anforderungen an die langfristige, veränderungssichere Aufbewahrung elektronischer Dokumente. Die langfristige, veränderungssichere Aufbewahrung elektronischer Dokumente ist in vielen Anwendungsgebieten

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Technische Konzeption der Bürgerportale

Technische Konzeption der Bürgerportale Technische Konzeption der Bürgerportale Armin Wappenschmidt (secunet) Weitere Informationen unter www.buergerportale.de www.bmi.bund.de 1 Agenda Technische Übersicht über Bürgerportale Postfach- und Versanddienst

Mehr

Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten

Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten Einführung der Gesundheitskarte Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten Version: 1.2.0 Revision: main/rel_main/32 Stand: 01.07.2008 Status: freigegeben

Mehr

Elektronische Signatur praktischer Nutzen für Unternehmen. Grundlagen der Informationssicherheit

Elektronische Signatur praktischer Nutzen für Unternehmen. Grundlagen der Informationssicherheit Elektronische Signatur praktischer Nutzen für Unternehmen Grundlagen der Informationssicherheit Knut Haufe Studium der Wirtschaftsinformatik an der Technischen Universität Ilmenau Vom Bundesamt für Sicherheit

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Richtlinie für den Betrieb der Gesundheitstelematik

Richtlinie für den Betrieb der Gesundheitstelematik Einführung der Gesundheitskarte Richtlinie für den Betrieb der Gesundheitstelematik (Plicy) Versin 1.0.0 Stand: 30.11.2006 Status freigegeben gematik_betr_betrieb_plicy_v1.0.0.dc Seite 1 vn 17 Versin:

Mehr

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07. Zusicherung von Qualitätskriterien bei WebServices Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.2003 Agenda Verteilte Systeme am am Beispiel Beispiel Aspekte von Verteilung

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

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

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

Anlage 1 Vertragssoftware

Anlage 1 Vertragssoftware Anlage 1 Vertragssoftware Diese Anlage 1 zum HzV-Vertrag regelt die Anforderungen an die Erstellung und Nutzung der Vertragssoftware gemäß 11 Abs. 1 Satz 1 und ihre Zulassung gemäß 11 Abs. 2 des HzV-Vertrages.

Mehr

Stephan Groth (Bereichsleiter IT-Security) 03.05.2007. CIO Solutions. Zentrale E-Mail-Verschlüsselung und Signatur

Stephan Groth (Bereichsleiter IT-Security) 03.05.2007. CIO Solutions. Zentrale E-Mail-Verschlüsselung und Signatur Stephan Groth (Bereichsleiter IT-Security) 03.05.2007 CIO Solutions Zentrale E-Mail-Verschlüsselung und Signatur 2 Wir stellen uns vor Gegründet 2002 Sitz in Berlin und Frankfurt a. M. Beratung, Entwicklung

Mehr

Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen. Christoph Thiel

Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen. Christoph Thiel Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen Christoph Thiel Stuttgart, 4. November 2014 Das extented enterprise SSL E-Mail Grundlegende Sicherheitsanforderungen Authentisierung

Mehr

CLOUDCYCLE Ferner integriert der Broker neue Konzepte zur geographischen Eingrenzung der Nutzung von Cloud-Diensten und assoziierter Daten.

CLOUDCYCLE Ferner integriert der Broker neue Konzepte zur geographischen Eingrenzung der Nutzung von Cloud-Diensten und assoziierter Daten. TRusted Ecosystem for Standardized and Open cloud-based Resources Das Vorhaben hat den Aufbau eines Cloud-Ecosystems zum Ziel, welches exemplarisch für den Anwendungsbereich der Patientenversorgung im

Mehr

Erfassung von Umgebungskontext und Kontextmanagement

Erfassung von Umgebungskontext und Kontextmanagement Erfassung von Umgebungskontext und Kontextmanagement Jörg Schneider, Christian Mannweiler, Andreas Klein, Hans D. Schotten 13.05.2009 Inhalt 1. Einleitung 2. Anforderungen 3. Kontext Erfassung und Verteilung

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

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

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr