Version 2.2.0 vom 10.03.2008 - Gematik

Einführung der GesundheitskarteÜbergreifendes Sicherheitskonzeptder TelematikinfrastrukturVersion: 2.2.0Stand: 10.03.2008Status:freigegebengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 1 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDokumentinformationenÄnderungen zur VorversionDie Kommentare aus der Kommentierung wurden eingearbeitet. Insbesonders ergabensich folgende Änderungen:• Alle Anforderungen haben eine eindeutige Anforderungs-ID erhalten und wurdenin Tabellen zusammengefasst. Diese zusätzlichen Tabellen wurden aufGrund der Beibehaltung der Übersicht nicht gelb markiert. Inhaltlich sind beidieser Änderung keine neuen Anforderungen hinzugekommen. Falls durch dieKommentierung Änderungen an einzelnen Anforderungen erforderlich waren,sind diese gelb markiert.• Die Anforderungen selbst werden ggf. teilweise für die nächste Version desÜbergreifenden Sicherheitskonzepts noch überarbeitetEs wurde sichergestellt, dass insbesondere im Krankenhausbereich die nachfolgendenPunkte konsistent dargestellt sind:• Die medizinische Versorgung von Patienten in Krankenhäusern wird durch telematischeAnforderungen nicht behindert. Insbesondere wird der Versichertenicht gehindert, das Krankenhaus (und damit alle in seine Behandlung einbezogenenMitarbeiter) zum Zugriff auf die medizinischen Daten seiner eGK zuberechtigen.• Die Zuständigkeit der gematik endet an den dezentralen Komponenten (Konnektor,Kartenterminal) und greift nicht mit verbindlichen Vorgaben in die interneIT-Infrastruktur („Primärsysteme“) der Krankenhäuser ein.Die vorgenommenen Änderungen gegenüber der Vorversion wurden farblich hervorgehoben.Bei Ergänzungen von Kapiteln oder Abschnitten wurde der besseren Lesbarkeit wegenlediglich die Überschrift markiert.ReferenzierungDie Referenzierung in weiteren Dokumenten der gematik erfolgt unter:[gemSiKo] gematik (10.03.2008): Einführung der Gesundheitskarte -Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVersion 2.2.0DokumentenhistorieVersion StandKap./SeiteGrund der Änderung, besondere HinweiseBearbeitung1.0.9 16.08.06 Sicherheitskonzept –Offline, Version 1.0.9 gematik, AG601.10.06 Klassifizierung der Kommentare und Berück- gematik, AG6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 2 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVersion StandKap./SeiteGrund der Änderung, besondere Hinweisesichtigung der Ergebnisse der AB-Sitzung vom15. 09. 06Zusammenlegung SiKo Offline und Online,daher neu beginnende VersionierungBearbeitunggematik, AG61.1.1 20.12.06 Grundsätze und Sicherheitsstrategie gematik, AG61.1.3 12.01.07 Kryptokonzept, PIN/PUK-Policy,Sicherheitsprozesse Betriebgematik, AG61.1.5 05.02.07 Berechtigungsmodell gematik, AG61.1.8 16.03.07 Übergreifendes Sicherheitskonzept der Telematikinfrastruktur1.1.9 31.03.07 Einarbeitung Kommentare nach iQS, Formatierunggematik, AG6gematik,AG6, IQS1.9.0 03.04.07 freigegeben zur Vorkommentierung gematik1.9.1 04.04.07 Vorbereitung Version 2.0 AG61.9.2 16.08.07 Einarbeitung Kommentare der Vorkommentierunggematik AG62.0.0 24.08.07 Freigegeben gematik2.0.1 –2.0.931.10.07 Abschnitt zu Treuhändler erstellt, Zonenkonzeptüberarbeitet, Abschnitt zu Pseudonymisierung/Anonymisierungerstellt, Sicherheitsanforderungenzu Infrastrukturdiensten und –netzen eingearbeitet und überarbeitet, Sicherheitsanforderungenan Fachdienste überarbeitet,Schutzbedarfsfeststellung überarbeitet,generelle Bedrohungen und Schadenskategorienaufgenommen, KryptographiekonzeptüberarbeitetITS/SI2.0.10 formelle Überarbeitung gematik, QM2.0.11 28.11.07 Einarbeitung Kommentare ITS/SI2-0-12-2.0.192.0.20,2.1.007.12.07 Editorische UmstrukturierungFortschreibung Übergreifendes Sicherheitskonzept07.12.07,10.12.07Inhaltsgleiche Versionen zur Kommentierung2.1.1 04.03.08 Einarbeitung der Kommentierung im Zuge derRVOITS/SIITS/SI, QMITS/SI2.2.0 10.03.08 freigegeben gematik.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 3 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturInhaltsverzeichnisDokumentinformationen..................................................................................... 2Inhaltsverzeichnis................................................................................................ 41 Zusammenfassung ..................................................................................... 172 Einführung................................................................................................... 182.1 Zielsetzung und Einordnung des Dokumentes............................................182.2 Zielgruppe.......................................................................................................192.3 Geltungsbereich.............................................................................................192.4 Arbeitsgrundlagen..........................................................................................192.5 Abgrenzung des Dokumentes.......................................................................192.6 Methodik.........................................................................................................202.6.1 Nomenklatur................................................................................................202.6.2 Verwendung von Schlüsselworten...............................................................212.6.3 Normative und informative Kapitel...............................................................213 Externe Anforderungen und allgemeine Annahmen................................ 233.1 Datenschutz....................................................................................................243.2 Sicherheitsziele für die Telematikinfrastruktur............................................253.3 Bedrohungen der Telematikinfrastruktur.....................................................273.4 Zusammenstellung der Ausgangsanforderungen.......................................304 Sicherheitsstrategie.................................................................................... 344.1 Eckpunkte der Sicherheitsstrategie..............................................................344.1.1 Übergreifendes Sicherheitskonzept.............................................................354.1.2 Zwei-Karten-Prinzip für den Zugriff auf medizinische Daten........................364.1.3 Schutz der Daten in der Telematikinfrastruktur............................................384.1.4 Versichertenindividuelle Verschlüsselung....................................................394.1.5 Datenvermeidung, Datensparsamkeit und Datentrennung..........................394.1.6 Aufteilung der Architektur in gestufte Sicherheitszonen...............................404.1.7 Proaktive Prozesse zur schnellen Reaktion.................................................404.1.8 Schutz der Beteiligten .................................................................................414.2 Schutzziele der Telematikinfrastruktur.........................................................424.3 Überblick über die Telematikinfrastruktur....................................................444.4 Konsequenzen der Eckpunkte und Prinzipien (Roadmap)..........................484.5 Zusammenstellung der Ausgangsanforderungen.......................................515 Sicherheitsaspekte der Fachkonzepte und Facharchitekturen............... 625.1 Sicherheits- und Zugriffsbedingungen der TI-Anwendungen.....................62gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 4 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur5.2 Fachliche Akteure...........................................................................................645.3 Schutzbedarf für Datenklassen fachlicher Objekte......................................645.4 Zusammenstellung der Ausgangsanforderungen.......................................686 Berechtigungsmodell.................................................................................. 696.1 Prinzipien des Berechtigungsmodells..........................................................696.2 Einordnung des Berechtigungsmodells.......................................................716.2.1 Berechtigungsmodell als Abstraktionsschicht..............................................716.3 TI-adaptierte benutzerbestimmbare Informationsflusskontrolle.................746.4 Datenorte und ihre Systemgrenzen ..............................................................756.5 Beschreibungssprache für Berechtigungsrichtlinien..................................766.5.1 Berechtigungsrichtlinie................................................................................766.5.2 Informationsflussregeln...............................................................................766.5.3 Zugriffsoperation.........................................................................................766.5.4 Subjekt (Benutzer und Rolle).......................................................................776.5.5 Constraint....................................................................................................776.5.6 Datenklasse und Informationsobjekt............................................................786.5.7 Informationsflussvorschriften.......................................................................786.6 Zusammenstellung der Ausgangsanforderungen.......................................797 Sicherheitsarchitektur................................................................................ 807.1 Überblick Sicherheitsdienste der Netzebene...............................................807.2 Überblick Sicherheitsdienste der Anwendungsebene.................................817.2.1 Offline- und Online-Modus der Telematikinfrastruktur..................................827.2.1.1 Migrations- und Releaseplanung.........................................................837.3 Schutzbedarf für Datenklassen technischer Objekte ..................................837.4 Zonenkonzept.................................................................................................877.4.1 Tiers, Sicherheitszonen und Sicherheitsbereiche........................................877.4.2 Klassifizierung der Zonen............................................................................907.4.2.1 Top-Level-Zonen.................................................................................907.4.2.2 Zonentypen .........................................................................................917.4.2.3 Anwendertypen....................................................................................927.4.2.4 Typen des Datenflusses......................................................................927.4.2.5 Schutzstufen für Zonenübergänge.......................................................927.4.2.6 Gesamtliste der vorgegebenen Zonen und Subzonen.........................937.4.3 Beschreibung der Zonen.............................................................................947.4.3.1 Zone 1 - Dezentral Extern....................................................................947.4.3.2 Zone 2 - Zentral Extern........................................................................967.4.3.3 Zone 3 - Zentral Intern.........................................................................977.4.3.4 Zone 4 - Zentral Backend Intern..........................................................987.4.3.5 Zone 5 - Dezentral Backend Extern.....................................................997.4.3.6 Zone 6 - Mehrwertdienste..................................................................1007.4.4 Sicherheitsanforderungen an Zonen..........................................................1007.4.4.1 Nummerierung...................................................................................1007.4.4.2 Allgemeine Sicherheitsanforderungen an Topologie-Eigenschaften..1017.4.4.2.1 Topologie-Eigenschaft – Extern...................................................1017.4.4.2.2 Topologie-Eigenschaft – Intern.....................................................1037.4.4.2.3 Topologie-Eigenschaft – Dezentral...............................................103gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 5 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4.4.2.4 Topologie-Eigenschaft – Zentral...................................................1037.4.4.3 Detaillierte Sicherheitsanforderungen an Zonen................................1047.4.4.3.1 Zone 1 – Dezentral Frontend Extern.............................................1047.4.4.3.2 Zone 1.1 Dienste...........................................................................1057.4.4.3.3 Zone 1.9 Netzwerk........................................................................1057.4.4.3.4 Zone 2 Zentral extern („Service Zone“)........................................1057.4.4.3.5 Zone 2.3 Eingeschränkte Dienste.................................................1067.4.4.3.6 Zone 2.4 Benutzerindividuelle Dienste..........................................1067.4.4.3.7 Zone 2.4.1 Externe Dienste..........................................................1067.4.4.3.8 Zone 2.4.2 Interne Dienste............................................................1067.4.4.3.9 Zone 3 Zentral intern („Support Zone“)..........................................1077.4.4.3.10 Zone 3.6 Sicherheitsdienste........................................................1077.4.4.3.11 Zone 3.7 Administrationsdienste.................................................1077.4.4.3.12 Zone 3.8 Monitoring Dienste.......................................................1077.4.4.3.13 Zone 4 Zentral Backend intern....................................................1077.4.4.3.14 Zone 4.7 Administrationsdienste.................................................1077.4.4.3.15 Zone 4.6 Sicherheitsdienste........................................................1077.4.4.3.16 Zone 5 Dezentral Backend extern...............................................1077.4.4.3.17 Zone 6 Mehrwertdienste.............................................................1087.4.4.4 Erlaubte und verbotene Zonenübergänge..........................................1087.4.4.5 Sicherheitsanforderungen Zonenübergänge......................................1087.4.4.6 Zuordnung von Komponenten der Gesamtarchitektur zu Zonen........1137.5 Berechtigungsverwaltung............................................................................1177.5.1 Service- und ObjektTickets zur Verwaltung von Berechtigungen...............1187.5.1.1 Benutzerbestimmte Informationsflusskontrolle auf dem Fachdienst...1197.5.2 Schutzbedarf und Sicherheitsanforderungen für Tickets............................1197.5.3 Umgebungen und Schnittstellen für die Rechteverwaltung durch denVersicherten..........................................................................................................1217.5.3.1 Umgebungen zur Wahrnehmung der Versichertenrechte..................1227.5.3.2 Schnittstelle zur Rechteverwaltung....................................................1227.5.4 Strategie für die schrittweise Einführung der Ticketverwaltung..................1237.6 Protokollierungskonzept..............................................................................1247.6.1 Begriffsbestimmung...................................................................................1247.6.2 Dezentrale Protokollierung........................................................................1257.6.2.1 Protokollierung auf eGK.....................................................................1257.6.3 Zentrale Protokollierung............................................................................1257.6.3.1 Versichertenzentrierter Audit (AuditS)................................................1257.6.3.2 Technische Protokollierung................................................................1267.6.4 Alarme bei Sicherheitsverletzungen..........................................................1267.7 Zeitdienste und Zeitstempel........................................................................1267.7.1 Begriffsbestimmungen...............................................................................1267.7.2 Zeitangaben/Zeitdienst in der Telematikinfrastruktur.................................1277.7.3 Zeitstempel................................................................................................1287.8 Kryptographiekonzepte für die Telematikinfrastruktur..............................1287.8.1 Grundlegende Anforderungen...................................................................1297.8.2 Langfristige Perspektive für eingesetzte Algorithmen................................1307.9 Anonymisierung und Pseudonymisierung.................................................1327.9.1 Pseudonymisierung bei Pflichtanwendungen............................................1337.9.2 Freiwillige Anwendungen mit Personenbezug (KVNR)..............................1357.9.3 Anonymisierung des Leistungserbringerbezugs........................................1357.10 Treuhänder ..............................................................................................136gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 6 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.10.1 Beschreibung der Rolle des Treuhänders..............................................1367.10.2 Sicherheitsanforderungen an den Treuhänderdienst.............................1367.11 Zusammenstellung der Ausgangsanforderungen................................1388 Sicherheitsmanagement........................................................................... 1638.1 Begriffsbestimmung.....................................................................................1638.2 Sicherheitspolicy der Telematikinfrastruktur.............................................1638.2.1 Definition und Abgrenzung........................................................................1638.2.2 Geltungsbereich........................................................................................1648.2.3 Inhalte, grundsätzliche Ziele und Strategien..............................................1648.3 Delegation von Verantwortung....................................................................1648.4 Organisation und Verantwortlichkeiten......................................................1668.4.1 Telematik-Informationssicherheit-Board (TIB) ...........................................1668.5 Risikomanagementprozess.........................................................................1668.5.1 Vorgehensweise........................................................................................1668.5.2 Risikoanalysestrategien.............................................................................1668.5.2.1 Allgemeines.......................................................................................1668.5.2.2 Varianten...........................................................................................1678.5.2.3 Akzeptables Restrisiko......................................................................1678.5.2.4 Vorgehensweise bei außergewöhnlichen Restrisiken........................1678.5.3 Detaillierte Risikoanalyse..........................................................................1688.5.4 Grundschutzanalyse..................................................................................1688.5.5 Kombinierter Ansatz..................................................................................1698.5.5.1 Vorgehensweise................................................................................1698.6 Spezifisches Sicherheitskonzept................................................................1708.6.1 Abgrenzung...............................................................................................1708.6.2 Inhaltsübersicht.........................................................................................1708.6.3 Beschreibung des Dienstes.......................................................................1718.6.4 Spezifische Sicherheitspolicy....................................................................1718.6.4.1 Aufgaben und Ziele............................................................................1718.6.4.2 Inhalte................................................................................................1718.6.4.3 Fortschreibung der spezifischen Sicherheitspolicy.............................1718.6.5 Schutzbedarf der Daten.............................................................................1728.6.5.1 Vordefinierte Schutzobjekte...............................................................1728.6.5.2 Selbst definierte Schutzobjekte..........................................................1728.6.6 Bedrohungsanalyse...................................................................................1728.6.7 Sicherheitsanforderungen der gematik......................................................1738.6.8 Sicherheitsmaßnahmen.............................................................................1738.6.8.1 Auswahl von Maßnahmen.................................................................1738.6.8.2 Bewertung der Maßnahmen..............................................................1748.6.9 Ablauforganisation.....................................................................................1748.6.10 Besondere technische Komponenten....................................................1748.6.11 Schlüssel- und Zertifikatsmanagement..................................................1758.6.12 Wirksamkeit der Sicherheitsmaßnahmen ..............................................1768.6.13 Erstellung einer Restrisikoabschätzung.................................................1768.6.14 Erstellung eines Notfallkonzepts............................................................1788.6.15 Einordnung des Dienstes in das Zonenkonzept der gematik.................1788.6.16 Fortschreibung des spezifisches Sicherheitskonzept.............................1798.6.16.1 Umsetzung des spezifischen Sicherheitskonzepts.........................1798.7 Implementierung von Maßnahmen..............................................................180gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 7 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur8.7.1.1 Dokumentation..................................................................................1808.7.1.2 Implementierung von technischen und organisatorischen Abläufen...1808.7.1.3 Prüfung der Maßnahmen auf Übereinstimmung mit der Sicherheitspolicy1808.8 Sicherheitsanforderungen an den Betrieb..................................................1808.9 Zulassungs- und Akkreditierungsprozesse................................................1818.9.1 gematik: Zulassungsverfahren der dezentralen IT- Komponente...............1818.9.2 Verfahrensablauf.......................................................................................1838.9.3 Einspruchsverfahren vom Antragsteller und Entzug von Zulassungen......1858.9.4 Besonderheiten der Einführungsphase......................................................1858.9.5 Besonderheiten der Zulassung der eGk....................................................1868.10 Zusammenstellung der Ausgangsanforderungen................................1889 Zusammenfassung der akzeptierten Restrisiken................................... 2009.1 Zusammenfassung der Ausgangsanforderungen.....................................203Anhang A.......................................................................................................... 206Anhang B – Sicherheitsanforderungen......................................................... 207B1 - Normative Anforderungen des Datenschutzes.............................................207B1.1 - Grundsätzliche Anforderungen und Eckpunkte des Datenschutzes.............207B1.2 - Fachliche Anforderungen und rechtliche Rahmenbedingungen...................213B1.2.1 - Anforderungen und Funktionen für Pflichtanwendungen.......................223B1.2.2 - Anforderungen und Funktionen für freiwillige Anwendungen................224B1.3 - Anforderungen an die Architektur................................................................226B2 - Grundlegende Sicherheitsanforderungen.....................................................234B2.1 - Sicherheitsziele(-anforderungen) ................................................................234B2.1 – Zusammenfassung der Ausgangsanforderungen.......................................236B3 - Fachliche Sicherheitsanforderungen.............................................................238B3.1 - Anwendungsübergreifende Anforderungen.................................................239B3.2 - Versichertenstammdaten (VSD)..................................................................240B3.3 - Verordnungsdaten (VOD)............................................................................242B3.4 - Freiwillige Anwendungen............................................................................243B3.4.1 - Anwendung des Versicherten (AdV).....................................................243B3.4.2 - Verwaltung freiwilliger Anwendungen (VfA)..........................................245B3.4.3 – Notfalldaten..........................................................................................246B3.4.4 - Weitere freiwillige Anwendungen..........................................................248B4 - Sicherheitsanforderungen an Komponenten/Dienste/Netze........................248B4.1 - Übergreifende Anforderungen.....................................................................248B4.1.1 - Technische Protokollierung...................................................................252B4.2 - eHealth-Kartenterminal...............................................................................253B4.2.1 – Allgemein.............................................................................................253B4.2.2 - Inbetriebnahme/Betrieb ........................................................................256B4.2.3 - Management/Administration.................................................................257B4.2.4 – Software..............................................................................................258B4.2.5 – Netzwerk..............................................................................................259B4.3 - Konnektor....................................................................................................260B4.3.1 – Allgemein.............................................................................................260B4.3.2 - Inbetriebnahme/Betrieb ........................................................................266B4.3.3 - Management/Administration.................................................................266gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 8 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.3.4 – Software..............................................................................................268B4.3.5 – Netzwerk..............................................................................................271B4.4 - Smartcards..................................................................................................273B4.4.1 – Allgemein.............................................................................................273B4.4.2 – eGK.....................................................................................................276B4.4.3 – HBA.....................................................................................................278B4.4.4 – SMC ....................................................................................................280B4.5 - PKI und Zertifikate.......................................................................................280B4.5.1 – Allgemein.............................................................................................280B4.5.2 - X.509 Zertifikate...................................................................................286B4.5.3 - CV Zertifikate........................................................................................286B4.5.4 - Private Schlüssel in HSMs....................................................................291B4.6 - Dienste und Netze.......................................................................................292B4.6.1 - Verzeichnisdienst/Nameserver.............................................................292B4.6.2 - Zeitdienst/NTP......................................................................................299B4.6.3 - Netzwerksicherheit allgemein...............................................................300B4.6.4 - Schutz der VPN-Zugangsdaten............................................................304B4.6.5 - Sichere Verbindung zwischen Konnektor und Telematik ......................305B4.6.6 – Broker..................................................................................................308B4.6.7 - System Management............................................................................318B4.6.8 – Audit....................................................................................................318B4.6.9 – VPN-Konzentrator................................................................................322B4.6.10 – Trusted Service..................................................................................325B4.6.11 – MPLS-Backbone................................................................................328B4.6.12 - Update Flag Service (UFS)/VSDD......................................................329Anhang C – Schutzbedarfsanalyse................................................................ 330C1 - Einführung.......................................................................................................330C1.1 - Zielsetzung und Einordnung .......................................................................330C1.2 - Abgrenzung................................................................................................330C1.3 - Methodik der Schutzbedarfsfeststellung......................................................331C.1.4 - Zusammenhang Schutzbedarfsfeststellung von Informationsobjekten undDatenklassen.........................................................................................................333C2 - Schutzbedarfsdarstellung...............................................................................334C2.1 - Io001 – Versichertendaten..........................................................................334C2.2 - Io002 – Leistungserbringerdaten.................................................................335C2.3 - Io004 - eVerordnung für Arzneimittel...........................................................336C2.3.1 - Allgemeine Anforderungen/Weiteres Vorgehen....................................336C2.4 - Io005 - Verordnung zur Krankenhausbehandlung.......................................337C2.4.1 - Allgemeine Anforderungen/Weiteres Vorgehen....................................337C2.5 - Io006 - Verordnung zur physikalischen Therapie und Podologen................338C2.5.1 - Allgemeine Anforderungen/Weiteres Vorgehen....................................338C2.6 - Io007 - Verordnung zu Maßnahmen der Stimm-, Sprech- und Sprachtherapie..............................................................................................................................339C2.6.1 - Allgemeine Anforderungen/Weiteres Vorgehen....................................339C2.7 - Io008 - Verordnung einer Hörhilfe...............................................................340C2.7.1 - Allgemeine Anforderungen/Weiteres Vorgehen....................................340C2.8 - Io009 - Verordnung einer Ergotherapie.......................................................341C2.8.1 - Allgemeine Anforderungen/Weiteres Vorgehen....................................341C2.9 - Io010 - Verordnung einer Soziotherapie......................................................342C2.9.1 - Allgemeine Anforderungen/Weiteres Vorgehen....................................342C2.10 - Io011 - Verordnung einer Sehhilfe.............................................................343C2.10.1 - Allgemeine Anforderungen/Weiteres Vorgehen..................................343gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 9 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.62 - Io086 – ObjektTicket.................................................................................390C2.63 - Io087 – ServiceTicket................................................................................391C2.64 - Io090 – SMC-A CVC Zertifikat und dazugehöriger Public-Key..................392C2.65 - Io091 – Privater CVC-Key der SMC-A ......................................................393C2.66 - Io092 – SMC-B Public-Keys zu Zertifikaten...............................................394C2.67 - Io093 – SMC-B Private Keys.....................................................................395C2.68 - Io094 – SMC-B CVC Zertifikat und dazugehöriger Public-Key..................396C2.69 - Io095 – Privater CVC-Key der SMC-B ......................................................397C2.70 - Io103 – Versichertenzentriertes Audit (Einzeleintrag eines Versicherten)..398C2.71 - Io104 – Versichertenzentriertes Audit .......................................................399C2.72 - Io105 – Antwort des OCSP Basisdienst...................................................400C2.73 - Io106 – CRListen des CRL Validation und CRL Provider Basisdienste.....401C2.74 - Io107 – TSL des TSL Retrieval Basisdienst..............................................402C2.75 - Io108 – TS-Listen des TSL Creator Basisdienst........................................403C2.76 - Io109 – Private-Key des TSL Creator Basisdienst zum Signieren der TSL404C2.77 - Io110 – Public-Key und dazugehöriges Zertifikat des TSL Creator Basisdienst..............................................................................................................................405C2.78 - Io111 – Cache des ServiceDirectoryService (SDS)...................................406C2.79 - Io114 – Private-Key des SecurityConfirmationService (SCS)....................407C2.80 - Io115 – Public-Key und dazugehöriges Zertifikat des SCS .......................408C2.81 - Io116 - Liste aller Einträge einer Person im Update Flag Service (UFS)...409C2.82 - Io117 – Menge aller Listen von allen Personen im UFS............................410C2.83 - Io118 – Private-Key des VPN-Konzentrator..............................................411C2.84 - Io119 – Public-Key und dazugehöriges Zertifikat des VPN-Konzentrators 412C2.85 - Io120 – Private-Key des Ticket-Treuhänders............................................413C2.86 - Io121 – Public-Key und dazugehöriges Zertifikat des Ticket-Treuhänders 414C2.87 - Io122 - Private-Key der CV-Root...............................................................415C2.88 - Io123 – Public-Key und dazugehöriges Zertifikat der CV-Root..................416C2.89 - Io124 – Private-Keys der CV-SUB-CA......................................................417C2.90 - Io125 – Public-Keys und dazugehörige Zertifikate der CV-SUB-CA..........418C2.91 - Io126 – Private-Keys eines Telematikservices (SSL)................................419C2.92 - Io127 – Public-Keys und dazugehörige X.509-Zertifikate einesTelematikservices (SSL)........................................................................................420C2.93 - Io128 – Private-Key der X.509-Telematik Service-CA...............................421C2.94 - Io129 – Public-Key und dazugehöriges Zertifikat der X.509-TelematikService-CA............................................................................................................422C2.95 - Io130 – Private-Key der X.509-Telematik-Netz-CA...................................423C2.96 - Io131 – Public-Key und dazugehöriges Zertifikat der X.509-Telematik-Netz-CA.........................................................................................................................424C2.97 - Io132 – Private-Key der eGK-X.509 Root..................................................425C2.98 - Io133 – Public-Key und dazugehöriges Zertifikat der eGK-X.509-Root.....426C2.99 - Io134 – Private-Keys der eGK-X.509-SUB-CA..........................................427C2.100 - Io135 – Public-Keys und dazugehörige Zertifikate der eGK-X.509-SUB-CA..............................................................................................................................428C2.101 - Io136 – Private-Key des SM-K................................................................429C2.102 - Io137 – Public-Key und dazugehöriges Zertifikat des SM-K....................430C2.103 - Io138 – Private-Key des SM-KT..............................................................431C2.104 - Io139 – Public-Key und dazugehöriges Zertifikat des SM-KT..................432C2.105 - Io140 – Symm. Objektschlüssel bzgl. verschlüsselter pers. bezogenermedizinischer Daten..............................................................................................433C2.106 - Io141 – Liste der Berechtigungen............................................................434C2.107 - Io142 – ObjektTicket (unsigniert).............................................................435C2.108 - Io143 – ServiceTicket (unsigniert)...........................................................436C2.109 - Io144 – Hybridschlüssel..........................................................................437gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 11 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.110 - Io145 – Berechtigungshistorie.................................................................438C3 - Beschreibung der Schutzziele........................................................................439C3.1 - Schutzbedarfsklassen für Schutzziel Vertraulichkeit ...................................439C3.2 - Schutzbedarfsklassen für Schutzziel Integrität............................................440C3.3 - Schutzbedarfsklassen für Schutzziel Verfügbarkeit.....................................440C3.4 - Schutzbedarfsklassen für Schutzziel Nichtabstreitbarkeit............................441C3.5 - Schutzbedarfsklassen für Schutzziel Authentizität ......................................441C4 - Informationsobjekte und Datenklassen.........................................................442C4.1 - Informationsobjekte.....................................................................................442C4.2 - Datenklassen..............................................................................................455Anhang D – Berechtigungsrichtlinien für TI-Anwendungen........................ 457D1 - Akteure.............................................................................................................457D2 - Abbildung fachlicher Aktionen auf Zugriffsoperationen..............................457D3 - Datenklassen...................................................................................................458D4 - Rollenhierarchie..............................................................................................459D5 - Berechtigungsrichtlinie..................................................................................460D5.1 - Notation von Berechtigungsrichtlinien.........................................................460D5.2 - Pflichtanwendungen....................................................................................461D5.2.1 - Versichertenstammdatenmanagement.................................................461D5.2.2 - Verordnungsdatenmanagement...........................................................463D5.3 - Versichertenzentrierte Auditdaten...............................................................464D5.4 - Freiwillige Anwendungen............................................................................465D5.4.1 - Notfalldatenmanagement......................................................................465D5.4.2 - Arzneimitteltherapiesicherheit...............................................................467Anhang E – PIN/PUK- Policy........................................................................... 469E1 - Einführung.......................................................................................................469E2 - PIN- und PUK-Verfahren .................................................................................472E2.A - Zusammenfassung der Sicherheitsanforderungen......................................474E2.1 - Mindestanforderungen und Sicherheits-Policies für die Behandlung PIN/PUK..............................................................................................................................475E2.1.1 - PIN/PUK-Erzeugung.............................................................................478E2.1.2 - PIN/PUK-Speicherung..........................................................................479E2.1.3 - PIN/PUK-Transport...............................................................................480E2.1.4 - PIN/PUK-Verwendung..........................................................................482E2.1.5 - PIN/PUK-Änderung...............................................................................483E2.1.6 - PIN/PUK-Löschung...............................................................................484E2.1.7 - PIN/PUK-Aktivierung............................................................................485E2.1.8 - PIN/PUK-Deaktivierung........................................................................485E2.1.8 – Zusammenfassung der Ausgangsanforderungen.................................486E2.2 - Mindestanforderungen und Sicherheits-Policies für die Behandlung derSchlüssel zum Schutz der PIN/PUK......................................................................494E2.2.1 - Allgemeine Anforderungen und einzuhaltende Mindeststandards.........494E2.2.2 - Schlüssel-Erzeugung............................................................................497E2.2.3 - Schlüssel-Speicherung.........................................................................498E2.2.4 - Schlüssel-Verteilung.............................................................................498E2.2.5 – Schlüssel-Aktivierung...........................................................................499E2.2.6 – Schlüssel-Verwendung........................................................................500gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 12 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturE2.2.7 - Schlüssel-Deaktivierung und Schlüssel-Wechsel..................................500E2.2.8 - Schlüssel-Zerstörung............................................................................501E2.2.9 - Prozessgestaltung und spezifisches Sicherheitskonzept des Betreibers501E2.2.9 – Zusammenfassung der Ausgangsanforderungen.................................506Anhang F – Kryptographiekonzept................................................................ 519F1 - Zusammenfassung..........................................................................................519F1.1 - Zusammenfassung der Sicherheitsanforderungen......................................520F2 - Einführung.......................................................................................................521F2.1 - Verwendung der Technischen Richtlinie TR-03116 des BSI........................521F2.2 - Zielsetzung und Einordnung des Kryptographiekonzepts der gematik.........521F2.3 - Spezifikationen und Facharchitekturen........................................................522F3 - Mindestanforderungen und Rahmenbedingungen für Krypto-Algorithmen522F3.1 - Betrachtungszeitraum der Technischen Richtlinie TR-03116 des BSI.........523F3.2 - Umsetzungsprobleme mit der TR-03116.....................................................529F3.2.1 - CV-Authentifizierung: Konflikte mit der eGK Spezifikation.....................529F3.2.2 - Technische Schwierigkeiten mit SHA-2 im Zusammenhang mit XMLStandards..........................................................................................................529F3.2.3 - Konflikte mit Schlüssellänge und Hashalgorithmus für IPSec Zertifikate530F3.2.4 - Konflikte mit Schlüssellänge und Hashalgorithmus für TLS(SSLZertifikate)..........................................................................................................................530F3.2.5 - Fehlende Verfahren..............................................................................530F3.2.6 – Unterschiedliche Gültigkeitszeiträume für Signaturen für Dokumente oderfür Authentikationen...........................................................................................531F3.2.7 – Verschlüsselung und Signatur langfristig gespeicherter medizinischerDokumente........................................................................................................533F3.2.8 - Symmetrische Card-to-Server Authentisierung. CAMS oder VSDD......534F3.3 - Ergebnis der Abstimmung zwischen BMG, BSI und gematik.......................534F3.3.1 - Generation Testkarten: RSA und 2TDES..............................................537F3.3.2 - Generation 1: RSA und 3TDES, Ausgabe ab Q2 / 2008.......................537F3.3.3 - Generation 2: Elliptische Kurven (ELC) und AES, Ausgabe ab etwa 2011..........................................................................................................................539F3.4- Zusammenfassung der Sicherheitsanforderungen.......................................543F4 - Anwendungen und Einsatzumgebungen.......................................................546F4.1 - Anwendungsebene......................................................................................546F4.1.1 – Signatur von Dokumenten....................................................................548F4.1.2 – Verschlüsselung von Dokumenten.......................................................550F4.1.3 – Nachrichten-Authentisierung der Telematik-Core Message..................552F4.1.4 – Session Authentisierung und sicherer Kanal (C2S)..............................554F4.1.5 – Session Authentisierung und sicherer Kanal (C2C mit SMC/HBA).......554F4.2 - Transport-, Netz- und Systemebene............................................................555F4.2.1 – VPN, IPSEC.........................................................................................556F4.2.2 –TLS/SSL Authentisierung......................................................................556F4.2.3 –Systemebene technische Absicherung von Zulassungen......................557F4.3 - Einsatzumgebungen....................................................................................557F4.3.1 – Sichere Hardwareumgebungen............................................................557F4.3.2 – Betriebsumgebungen...........................................................................558F4.3.3 – Privatumgebungen...............................................................................559F4.3.4 – Rechenzentren.....................................................................................559F4.4 - Transportarten.............................................................................................562F4.5 – Zusammenfassung der Ausgangsauforderungen.......................................563gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 13 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF5 - Lebenszyklus des eingesetzten Schlüsselmaterials.....................................567F5.1 - Key-Management-Infrastrukturen und Verantwortlichkeiten für dieTelematikinfrastruktur............................................................................................573F5.1.1 - Allgemeine Anforderungen und einzuhaltende Mindeststandards.........574F5.1.2 - Schlüssel-Erzeugung (Generation )......................................................579F5.1.3 - Schlüsselregistrierung...........................................................................580F5.1.4 - Erzeugung eines Schlüssel-Zertifikats..................................................580F5.1.5 - Schlüsselverteilung...............................................................................581F5.1.6 - Schlüsselinstallation..............................................................................582F5.1.7 - Schlüsselspeicherung...........................................................................583F5.1.8 - Schlüsselableitung................................................................................584F5.1.9 - Schlüsselarchivierung...........................................................................585F5.1.10 - Schlüsselsuspendierung (Revoke-key)...............................................586F5.1.11 - Aufheben der Registrierung eines Schlüssels.....................................587F5.1.12 - Schlüsselzerstörung............................................................................588F5.1.13 - Prüfung der Schlüsselverwendung......................................................588F5.1.14 - Schlüssel-Wechsel..............................................................................589F5.1.15 - Reaktivierung (Reactivation)...............................................................589F5.1.16 - Prozessgestaltung und spezifisches Sicherheitskonzept des Betreibersfür die Schlüsselverwaltung................................................................................590F5.1.16 – Zusammenfassung der Ausgangsanforderungen...............................595F5.2 – Beschreibung mit Hilfe von exemplarischen Schlüssel-Lebenszyklen.........616F5.2.1 - Objektschlüssel zur Verschlüsselung medizinischer Daten...................618F5.2.2 - Kartenindividueller CAMS-Schlüssel.....................................................622F5.2.3 - Privater Schlüssel der eGK zur Authentifikation....................................629F5.2.4 - Privater CVC Schlüssel der eGK zur Authentifikation............................634F5.2.5 - Privater Schlüssel der HBA zur Qualifizierten Elektronischen Signatur.638F5.2.6 - Passwörter für User und Admin Kartenterminal....................................644F5.2.7 - Passwörter für Admin-Passwort Konnektor...........................................645F5.2.8 - Privater Schlüssel zur Authentisierung im TLS-Protokoll Konnektor......647F6 - Sicherheitsvorfälle und Notfallmaßnahmen...................................................649F6.1 - Maßnahmen, die in jedem Kryptosystem vorzusehen sind: Ersetzen vonSchlüsseln.............................................................................................................649F6.2 - Anpassungen der Kryptoverfahren, die vorgesehen werden MÜSSEN .......649F6.2.1 - Wechsel der Hashfunktion....................................................................649F6.3 - Anpassungen der Kryptoverfahren, die vorgesehen werden KÖNNEN .......650F6.3.1 - Vergrößerung der RSA-Schlüssellänge................................................650F6.4 - Vorgaben zur Alarmierung bei kryptographischen Problemen.....................650F6.5 – Zusammenfassung der Ausgangsanforderungen.......................................651F7 - Kryptographische Entitäten............................................................................652Anhang G –Sicherheitsanforderungen Betrieb............................................. 655G1 - Personelle Anforderungen.............................................................................655G1.1 Zusammenfassung der Ausgangsanforderungen.......................................657G2 - Physische Sicherheitsmaßnahmen...............................................................659G2.1 - Physische Sicherheitsmaßnahmen in Bereichen, die der Kontrolle vonDienstbetreibern unterstehen.................................................................................659G2.1.1 - Zugang zum Datenzentrum..................................................................659G2.1.2 - Kontrollierte Bereiche...........................................................................660G2.1.3 - Standort von Systemen und Komponenten..........................................662G2.2 - Drucker.......................................................................................................664gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 14 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur1 ZusammenfassungDas vorliegende übergreifende Sicherheitskonzept der Telematikinfrastruktur im Rahmender Einführung der elektronischen Gesundheitskarte gibt einen Überblick über die einzu¬haltendensicherheitsrelevanten Mindeststandards der Telematikinfrastruktur. DetaillierteFestlegungen zu einzelnen Bereichen sind in den Anhängen getroffen. Das übergreifendeSicherheitskonzept gibt damit Rahmenbedingungen und Mindeststandards fürdie Telema¬tikinfrastruktur vor, insbesondere:• Anforderungen des Datenschutzes und der Datensicherheit: Die identifizier¬tenAnforderungen des Datenschutz und der Datensicherheit in den Konzeptenund Spezifikationen der gematik sind gesammelt dargestellt und aufdie einzelnen Bereiche aufgeteilt.• Sicherheitsaspekte der Fachkonzepte und Facharchitekturen: DerSchutzbedarf für fachliche Datenklassen und Informationsobjekte sowie dieübergreifende Sicherheitsleitlinie für die sicherheitskritischsten Objekte (PIN,PUK) ist dargestellt• Berechtigungsmodell: Die spezifizierten fachlichen Berechtigungen werdenein¬heitlich in Berechtigungsrichtlinien umgesetzt.• Sicherheitsarchitektur: Die Aufteilung der Telematikinfrastruktur in gestufteSi¬cherheitszonen ist dargestellt und Mindestanforderungen für sicherheitsrele¬vanteKomponenten und Dienste u. a. kryptographische Algorithmen undSchlüssel sind dargestellt.• Operationales Sicherheitsmanagement: Die Grundsätze für das Operatio¬naleSicherheitsmanagement, u. a. die Festlegung der Unternehmensgrund¬sätze,der Verantwortlichkeiten sind dargestellt und Anforderungen undVorga¬ben an den Betrieb der Telematikinfrastruktur sind ausgearbeitet.Dabei soll die konkrete technische Ausgestaltung, die Umsetzung und der Betrieb durchdiese Mindestanforderungen nicht unnötig eingeschränkt werden. Daher gibt die gematikin diesem Dokument nur die einzuhaltenden Mindeststandards vor. Im spezifischenSi¬cherheitskonzept eines Bereichs oder eines Betreibers werden die zur Umsetzungnot¬wendigen organisatorischen und technischen Schutzmaßnahmen im Detail beschriebenund die Wirksamkeit der dort festgelegten Sicherheitsmaßnahmen nachgewiesen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 17 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur2 Einführung2.1 Zielsetzung und Einordnung des DokumentesAuf der Basis des Sicherheitskonzepts offline (Version 1.0.9, 16.8.2006) [gemSi-Ko_offline] wurden folgende Erweiterungen durchgeführt• Berücksichtigung der Kommentare• Berücksichtigung der Online-Anbindung und Online-Interaktions- und Kommunikationsmuster,• insbesondere Einbeziehung der in der Zwischenzeit abgenommenen Fachkonzepte,Facharchitekturen, Gesamtarchitektur und Spezifikationen der gematik.Der Aufbau des übergreifenden Sicherheitskonzeptes der gematik ist in der nachfolgendenAbbildung dargestellt.Rechtliche und Geschäftspolitische RahmenbedingungenSigGBDSG§SGB V§§Gesellschafter-beschlüsseSicherheitskonzeptSicherheitsanforderungenSicherheitsstrategieFachliche SicherheitBerechtigungsmodellSicherheitsarchitektur•Zonenkonzept•Berechtigungsverwaltung•Protokollierung•Zeit- & Zeitstempeldienste•KryptographieOp. SicherheitsmanagementG•Prozesse (ISO 2700x)•Asset ManagementRestrisikenBCDEFAnhangPIN/PUKPolicyKryptokonzeptSicherheitsanf.SchutzbedarfFachlicheZugriffspol.Si.Anf.BetriebVSDVSDMFachkonzepteVOD NFD AMTS AdV,VfA CMSFacharchitekturenVODM NFDM AMTS AdV,VfA CAMSübergreifende Architekturbausteine, Dienste .Spezifikationen von Schnittstellen, KomponentenCC SchutzprofilCC SchutzprofilCC SchutzprofilSicherheitskonzeptSicherheitsprofilSicherheitsprofilGesamtarchitektur KonzeptAbbildung 1: Einordnung und Abgrenzung dieses Dokumentes.Dieses Dokument gibt einen Überblick über die sicherheitsrelevanten Mindeststandardsder Telematikinfrastruktur. Detaillierte Festlegungen zu einzelnen Bereichen sind in denAnhängen getroffen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 18 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur2.2 ZielgruppeDas übergreifende Sicherheitskonzept ist für die Spezifikation, Implementierung und denBetrieb aller Komponenten und Fachdienste der Telematikinfrastruktur relevant.2.3 GeltungsbereichDas übergreifende Sicherheitskonzept legt die einzuhaltenden Mindestanforderungen fürdie Spezifikation, Implementierung und den Betrieb aller Komponenten, Infrastruktur- undFachdienste der Telematikinfrastruktur normativ fest, um das notwendige Sicherheitsniveauzu gewährleisten.2.4 ArbeitsgrundlagenGesetzliche Grundlage für die Erstellung des übergreifenden Sicherheitskonzepts der gematikist § 291b, Abs. 1, Sozialgesetzbuch (SGB) V• Satz 1: Im Rahmen der Aufgaben nach § 291a Abs. 7 Satz 2 hat die Gesellschaftfür Telematik• die technischen Vorgaben einschließlich eines Sicherheitskonzepts zu erstellen,• Inhalt und Struktur der Datensätze für deren Bereitstellung und Nutzung festzulegen• sowie die notwendigen Test- und Zertifizierungsmaßnahmen sicherzustellen.• Satz 4: ….; hierbei sind durch die Gesellschaft für Telematik Interoperabilität,Kompatibilität und das notwendige Sicherheitsniveau der Telematikinfrastrukturzu gewährleisten.Auf weitere Basisdokumente wird in Anhang Z5 verwiesen.2.5 Abgrenzung des DokumentesFür die Komponenten und Dienste der Telematikinfrastruktur sind auf der Basis der Mindestanforderungendieses übergreifenden Sicherheitskonzepts jeweils spezifische Sicherheits-und Schutzprofile zu erstellen. Die Umsetzung der Mindestanforderungen diesesübergreifenden Sicherheitskonzepts und die Wirksamkeit der festgelegten konkretenSicherheitsmaßnahmen sind bei der Evaluierung bzw. Zulassung der Komponenten oderDienste der Telematikinfrastruktur nachzuweisen.Die Verantwortung der gematik endet an den Sicherheitsgrenzen der Telematikinfrastrukturund deshalb sind die existierenden Systeme der Leistungserbringer und Kostenträgervon den in diesem Sicherheitskonzept festgelegten Regelungen und Mindeststandardsder gematik nicht direkt betroffen. Die existierenden IT-Systeme der Leistungserbringerund Kostenträger werden entsprechend der dort jeweils gültigen Sicherheitsanforderungenund sektorspezifischen Policies betrieben. Die spezifische Einsatz- und Betriebsumgebungder Schnittstellenkomponenten muss adäquat geschützt werden und der Dienst-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 19 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturbetreiber muss die Verantwortung für den adäquaten Schutz und die verbleibenden Restrisikentragen.2.6 Methodik2.6.1 NomenklaturIn diesem Übergreifenden Sicherheitskonzept existieren zurzeit zwei Methoden, um Anforderungeneindeutig zu identifizieren. Einerseits wird an vielen Stellen auf Grund derRückwärtskompatibilität bis zur Version 2.1.0 des Übergreifenden Sicherheitskonzeptsnachfolgend beschriebene Strukturierung der Anforderungsnummern verwendet. Andererseitshaben alle Anforderungen eine neue, gematik-weit eindeutige Anforderungsnummer,die mit "A_" beginnt.Nachfolgend die Strukturierung der Anforderungsnummern, wie sie bis Version 2.1.0 desÜbergreifenden Sicherheitskonzepts ausschließlich verwendet wurden.AnforderungsID WertebereichTypAnwendungAnwendungsnr.Anforderungs-Typ:AD = Anforderung DatenschutzAS = Anforderung DatensicherheitSP = Sicherheitspolicy für SicherheitsobjekteTyp_FachanwendungDie Anforderungen des Datenschutz und der Datensicherheit sindz. T. übergreifend, betreffen alle Fachanwendungen, Architekturdomänen,Dienste und Komponenten und können nicht einerFachanwendung zugeordnet werden. Daher wird folgende Strukturierungverwendet:EPEckpunkteGRU Datenschutz GrundsätzeFKGADEZSABERPINKRYBetrifft alle Fachkonzepte und FacharchitekturenGesamtarchitekturDezentrale KomponentenSicherheitsarchitekturBerechtigungsmodellPIN/PUKsKryptographieAnwendungsnr.Hinweis: Wird wg. Verständlichkeit etc. durch eine Abkürzung fürjede Operation/Phase im Lebenszyklus der Sicherheitsobjekteersetzt werden. Im Gegensatz zu den Fachkonzepten und derArchitektur sind die Operationen/bzw. Phasen der Sicherheitsobjektefestgelegt und eine derartige Nummerierung fördert sowohldie Konsistenz, als auch eine Prüfung der Vollständigkeit.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 20 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur00 ALL Allgemeine Anforderungen und Mindeststandardsan die Sicherheitsobjekte(z. B. PIN/PUK, Schlüssel) die über die einzelnenPhasen des Lebenszyklus hinweg eingehaltenwerden MÜSSEN.01 CRE Erzeugung von PIN/PUK oder Schlüsseln02 STO Speicherung von PIN/PUK oder Schlüsseln03 TRA Transport der PIN/PUK und Verteilung derSchlüssel04 USE Verwendung der PIN/PUK oder Schlüssel05 MOD Änderung von PIN/PUK oder Wechsel derSchlüsseln06 DEL Sichere Löschung von PIN/PUK und der Schlüssel07 ACT Aktivierung von PIN/PUK oder Schlüsseln08 DEA Deaktivierung09 ARC Archivierung und Backup10 PRO Mindestanforderungen an die Prozessgestaltungund das spezifischen Sicherheitskonzepts desBetreibersAnforderungsnr.nn – fortlaufende Nummer2.6.2 Verwendung von SchlüsselwortenFür die genauere Unterscheidung zwischen normativen und informativen Inhalten werdendie dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschenSchlüsselworte verwendet:MUSS bedeutet, dass es sich um eine absolut gültige und normative Festlegung bzw. Anforderunghandelt.DARF NICHT bezeichnet den absolut gültigen und normativen Ausschluss einer Eigenschaft.SOLL beschreibt eine Empfehlung. Abweichungen zu diesen Festlegungen sind in begründetenFällen möglich.SOLL NICHT kennzeichnet die Empfehlung, eine Eigenschaft auszuschließen. Abweichungensind in begründeten Fällen möglich.KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungenhaben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter.2.6.3 Normative und informative KapitelIn der nachfolgenden Tabelle 1 sind die normativen Festlegungen des Sicherheitskonzeptsder gematik zusammenfassend dargestellt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 21 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 1: Normative Festlegungen des Sicherheitskonzepts der gematikNr. normativ Beschreibung Gültigkeitsbereich1 Ja Übergreifendes Sicherheitskonzept Telematikinfrastruktur2 Ja Anhang B - SicherheitsanforderungenTelematikinfrastruktur3 Ja Anhang C – Schutzbedarfsanalyse. Fachliche und technische Informationsobjekte4 Ja Anhang D – Berechtigungsrichtlinienfür TI-AnwendungenFachanwendungen und Fachdienste5 Ja Anhang E – PIN/PUK- Policy Alle Komponenten der Telematikinfrastruktur,die PIN PUKverwenden, die einen Zugriffauf geschützte Versichertendatenermöglichen.6 Ja Anhang F – Kryptographiekonzept Kryptographische Schlüssel inder Telematikinfrastruktur7 Ja Anhang G – Sicherheitsanforderungenan den BetriebMindestanforderungen für densicheren BetriebDie Einordnung der einzelnen Kapitel bzw. der Anhänge ist in Kapitel 4 Sicherheitsstrategiedargestellt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 22 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur3 Externe Anforderungen und allgemeine AnnahmenDie Stärkung der Versichertensouveränität, der Versichertenrechte und eine Ausweitungder Eigenverantwortung und Beteiligungsrechte der Versicherten sind die wesentlichenZiele des GKV-Modernisierungsgesetzes (GMG) zur Steigerung der Wirtschaftlichkeit undQualität des Gesundheitswesens. Durch die im GMG festgelegte Einführung der Gesundheitskarteund Telematikinfrastruktur werden diese Ziele technisch unterstützt und durchdie Einhaltung der Datenschutzgrundsätze nachhaltig umgesetzt. Die Infrastruktur in derTelematik richtet sich prioritär am Nutzen für den Versicherten aus, alle Komponenten,Schnittstellen, Dienste und Prozesse in der Telematik müssen an erster Stelle den Erfordernissendes Datenschutzes und der Datensicherheit entsprechen (siehe[Grundsatzentscheidung]). Daher MÜSSEN alltagstaugliche, für alle Versicherten praktikable,technische Verfahren zur aktiven Wahrnehmung dieser Beteiligungsrechte bereitgestelltwerden und die Durchsetzbarkeit der Betroffenenrechte ist zu gewährleisten. Beider Einführung der Telematikinfrastruktur sind die datenschutzrechtlichen Anforderungenzu gewährleisten. Die datenschutzrechtliche Position des Versicherten ist zu stärken.Grundsätzlich hat der Versicherte die Datenhoheit für alle seine Anwendungen und Gesundheitsdatenin der Telematikinfrastruktur. Ohne die Einwilligung und Freigabe desZugriffs durch den Versicherten können die freiwilligen medizinischen Anwendungen nichtgenutzt werden. Bei Pflichtanwendungen entscheidet der Versicherte wer auf seine Datenzugreifen darf. Der Grundsatz der Freiwilligkeit der Speicherung von Gesundheitsdatenmuss bewahrt werden d. h.• Die Versicherten müssen darüber entscheiden können, welche ihrer Gesundheitsdatenaufgenommen und welche gelöscht werden und ob und wenn ja,welche Daten sie einem Leistungserbringer zugänglich machen.• Die Versicherten haben das Informations- und Leserecht, über ihre in der Telematikinfrastrukturgespeicherten Daten und alle diese Daten betreffendenVorgänge.Aufgrund des sehr hohen Schutzbedarfs der Daten, die von medizinischen Systemen verarbeitetwerden, ergeben sich spezielle Sicherheitsanforderungen und Sicherheitsmaßnahmen,die aus datenschutzrechtlicher Sicht als unabdingbar anzusehen sind. Es gibtdaher einen engen Zusammenhang zwischen den Datenschutz- und den Sicherheitsanforderungen,die in der nachfolgendenAbbildung 2 1 dargestellt sind.Aus datenschutzrechtlicher Sicht muss die Informationssicherheit insbesondere die Verlässlichkeitund Beherrschbarkeit von Systemen gewährleisten. Kriterien für die Verlässlichkeit- d. h. die Sicherheit des Systems selbst - sind die Verfügbarkeit, Integrität undVertraulichkeit der Daten. Zu den Kriterien für die Beherrschbarkeit - d. h. die Sicherheitvor dem System- gehören die Zurechenbarkeit der Daten; die Nicht-Abstreitbarkeit derKommunikation und Revisionsfähigkeit von Kommunikationsprozessen; die Nutzungsfestlegungdurch Zugriffskontrolle die Durchsetzbarkeit der Betroffenenrechteu. a. Auskunft, Berichtigung, Sperrung, Löschung sowie die Praktikabilität und Alltagstauglichkeitder Nutzung. Durch Datenvermeidung und Datensparsamkeit bei der Übertragungund Speicherung sind die Risiken zu begrenzen.1 Einführung in die Begriffsbildungen siehe u. a. A. Roßnagel, Handbuch Datenschutz, Verlag C.H.Beck, 2003.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 23 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturBeherrschbarkeitVerantwortlichkeitNutzungsfestlegungNachweisbarkeitRevisionsfähigkeitUnabstreitbarkeitBeweissicherheitInformationsqualitätDatenschutzDatenschutzfördernde TechnikSelbstdatenschutzBeteiligungsrechteFreiwilligkeitTransparenzDatenvermeidung und -sparsamkeitVertraulichkeitVerlässlichkeitFokus desDatenschutzkonzeptsInformationssicherheitSchutz von Informationen vorMissbrauch, unberechtigter Einsichtoder Verwendung, Änderung oderVerfälschung (einschließlichKatastrophenschutz).IT-SicherheitDas System tut das, was manvon ihm erwartet und nichtsanderes. Insbesondere gewährtes IT-Sicherheit.Fokus desDatensicherheits-konzeptsDatensicherheit in einem IT-System mit dem Schutz derIntegrität des IT-Systems.Abbildung 2: Anforderungen des Datenschutzes und der Sicherheit.In den nachfolgenden Unterkapiteln werden die Datenschutz- und Datensicherheitsanforderungenim Überblick dargestellt. Eine detaillierte Beschreibung der Datenschutzanforderungenist in Anhang B im Abschnitt B1 gegeben. Eine detaillierte Beschreibung derDatensicherheitsanforderungen enthält Anhang B in den Abschnitten B2 bis B4.3.1 DatenschutzBei der Einführung der Telematikinfrastruktur wird sich die datenschutzrechtliche Positionder Versicherten nicht verschlechtern. Der Versicherte hat die Datenhoheit für alle seine§291a-Anwendungen und die darin enthaltenen Gesundheitsdaten in der Telematikinfrastruktur.Die gematik ist dafür verantwortlich, dass technische Vorkehrungen getroffenund dem Versicherten verfügbar gemacht werden, mit denen sie die Zugriffsrechte undihre Daten selbst aktiv verwalten können. Dabei muss die einfache Bedienbarkeit dieserDienste der Telematikinfrastruktur für alle Versicherten sichergestellt sein. AlltagstauglicheVerfahren zur aktiven Wahrnehmung der Versichertenrechte und der Ausübung derDatenhoheit sind - ohne Einschränkungen im Recht auf informationelle Selbstbestimmung- eine Grundvoraussetzung für die Testvorhaben und den Wirkbetrieb der Telematikinfrastruktur.Die technisch-organisatorische Unterstützung der Ziele des Datenschutzes geht jedochweit über die Maßnahmen der IT-Sicherheit hinaus. Durch die Telematikinfrastruktur sindnicht nur die Kontroll- und Abschottungsanforderungen des Datenschutzrechtes (siehegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 24 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturu. a. Anhang zu § 9 Satz 1 BDSG 2 ) zu unterstützen. Die Stärkung der Versichertensouveränität,der Versichertenrechte und die Ausweitung der Eigenverantwortung und Beteiligungsrechteder Versicherten erfordert zusätzlich datenschutzgerechte und datenschutzförderndeTechnik. Dies sind insbesondere:• Selbstdatenschutz - Für die Gewährleistung der Rechte der Betroffenenwerden technische Hilfsmittel in der Telematikinfrastruktur für die Versichertenbereitgestellt, um ihre Daten selbst zu verwalten oder nach ihren Wünschenverwalten zu lassen und unzulässige Datenzugriffe und Datenverarbeitung zuverhindern.• Beteiligungsrechte - Um die Betroffenen zu Beteiligten zu machen, muss dieHemmschwelle zur Rechtewahrnehmung der Versicherten durch praktikableund alltagstaugliche Verfahren für alle Versichertengruppen gesenkt werden.• Freiwilligkeit - Der Versicherte darf nicht bevorzugt oder benachteiligt werden,weil er einen Zugriff bewirkt oder verweigert hat, und er ist vor Zugriffenauf seine personenbezogenen medizinischen Daten aus Versehen, unterDruck oder aus Zwang geschützt.• Transparenz - Durch Verfahren und technische Funktionen für die Aufklärung,Auskunft und Information des Versicherten muss der Versicherte in Erfahrungbringen können, wer bei welcher Gelegenheit auf die Daten in der Telematikinfrastrukturzugegriffen und diese Daten genutzt hat.• Datensparsamkeit und Datentrennung - Es sollen sowenig personenbezogenemedizinische Daten wie möglich erhoben, verarbeitet oder genutzt werden.Dies umfasst Datenvermeidung, frühzeitiges Löschen, sowie die Vermeidungvon Personenbezug in der Telematikinfrastruktur durch Anonymisierungund Pseudonymisierung. Daten die für einen Zweck verarbeitet werden dürfennicht mit anderen zusammengebracht und z. B. für eine Profilbildung verkettetwerden können.Aus Sicht des Datenschutzes ist die Umsetzung der differenzierten Zugriffsrechte desVersicherten ein wichtiger einzuhaltender Grundsatz. Dieser Grundsatz spiegelt sich insbesonderein den datenschutzfördernden Techniken des Selbstdatenschutzes und derBeteiligungsrechte wider. Die für die Versicherten bereitgestellten technischen Hilfsmittelund Verfahren für die aktive Wahrnehmung der Betroffenenrechte sind im Datenschutzkonzeptder gematik zu beschreiben. Zusätzlich muss die Verwendbarkeit und Wirksamkeitder technischen-organisatorischen Funktionen und Verfahren beurteilt werden.3.2 Sicherheitsziele für die TelematikinfrastrukturFür den datenschutzgerechten Einsatz der Telematikinfrastruktur und der Gesundheitskarteist eine konsequente und überzeugende Sicherheitstechnologie erforderlich. Für dieautomatisierte Verarbeitung und Nutzung der personenbezogenen Daten der Versichertenin der Telematikinfrastruktur, MÜSSEN insbesondere Maßnahmen getroffen werden (sieheAnhang zu § 9 Satz 1 BDSG 3 ), die je nach der Art der zu schützenden personenbezogenenDaten oder Datenkategorien geeignet sind,2 http://bundesrecht.juris.de/bdsg_1990/anlage_73.html3 http://bundesrecht.juris.de/bdsg_1990/anlage_73.htmlgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 25 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Unbefugten den Zutritt zu Datenverarbeitungsanlagen, mit denen personenbezogeneDaten verarbeitet oder genutzt werden, zu verwehren (Zutrittskontrollemit dem Schutzziel der Integrität der IT-Systeme),• zu verhindern, dass Datenverarbeitungssysteme von Unbefugten genutztwerden können (Zugangskontrolle mit dem Schutzziel der Integrität derIT-Systeme),• zu gewährleisten, dass die zur Benutzung eines DatenverarbeitungssystemsBerechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegendenDaten zugreifen können, und dass personenbezogene Daten bei der Verarbeitung,Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändertoder entfernt werden können (Zugriffskontrolle mit den SchutzzielenAuthentizität, Integrität und Autorisierung),• zu gewährleisten, dass personenbezogene Daten bei der elektronischen Ü-bertragung oder während ihres Transports oder ihrer Speicherung auf Datenträgernicht unbefugt gelesen, kopiert, verändert oder entfernt werden können,und dass überprüft und festgestellt werden kann, an welche Stellen eine Ü-bermittlung personenbezogener Daten durch Einrichtung zur Datenübertragungvorgesehen ist (Weitergabekontrolle durch eine Informationsflusskontrolledie die Schutzziele Vertraulichkeit, Integrität, Authentizität undAutorisierung gewährleistet),• zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann,ob und von wem personenbezogene Daten in Datenverarbeitungssystemeeingegeben, verändert oder entfernt worden sind (Eingabekontrolle durchRevisionsfähigkeit 4 der Protokollierung und Nichtabstreitbarkeit der Datenübermittlung),• zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitetwerden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werdenkönnen (Auftragskontrolle durch eine Rechteverwaltung durch denVersicherten die eine benutzerbestimmte Informationsflusskontrolle ermöglicht),• zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörungoder Verlust geschützt sind (Verfügbarkeitskontrolle mit den SchutzzielenVerfügbarkeit und Integrität). Weitere Bedrohungen u. a. eine unbefugteVorenthaltung von Informationen oder Betriebsmitteln z. B. durch Denial-of-Service-Attacks werden durch dieses Schutzziel ebenfalls abgedeckt.• zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrenntverarbeitet werden.Diese Schutzziele sind sowohl zu gewährleisten, wenn die Daten auf der Chipkarte gespeichertwerden, als auch dann, wenn sie in einer Komponente der Telematikinfrastrukturgespeichert werden, die durch die Gesundheitskarte zugänglich gemacht wird.4 Die Revisionsfähigkeit des Systems wird im Wesentlichen durch die heute schon vorhandenenDokumentationspflichten in den Primärsystemen der Leistungserbinger umgesetzt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 26 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur3.3 Bedrohungen der TelematikinfrastrukturAuf die Telematikinfrastruktur wirken unterschiedlichste Bedrohungen. Die meisten konkretenBedrohungen der Telematikinfrastruktur lassen sich auf allgemeine Bedrohungenzurückführen. Sie basieren auf unterschiedlichen Quellen und Bedrohungskatalogen, z.B.dem Leitfaden „IT Sicherheit auf Basis der Common Criteria – ein Leitfaden“ des BSI[BSILF], dem IT-Grundschutz des BSI [BSI_GK], anerkannten Best-Practice-Lösungenund aktuellen Sicherheitsproblemen. Die in [BSILF] und [BSI_GK] aufgeführten Bedrohungs-bzw. Maßnahmenkataloge MÜSSEN bei den spezifischen Sicherheitskonzeptenbetrachtet werden.Der BSI Leitfaden zur IT-Sicherheit auf Basis der Common Criteria (siehe [BSILF]) präsentiertden Katalog der Sicherheitsfunktionen sowie einen Bedrohungskatalog, der vollständigdie Bedrohungen und die Zuordnung der Bedrohungen zu den CC-Sicherheitsfunktionen darstellt. Dieser sehr umfassende Überblick über die bisherige Evaluationserfahrungwird verwendet, um die Bedrohungen zu detaillieren und insbesondereeine Abdeckung der Gefährdungen durch Maßnahmen der Telematikinfrastruktur zu identifizieren.Die Kategorisierung der Bedrohungen erfolgt dabei analog zu [BSILF#4.2.1]anhand der Verursacher (Angreifer, Benutzer, administratives Personal und Hardware /Software).• T.USER…. Benutzer Diese Kategorie betrifft Anwender, die vorsätzlich/fahrlässigAktionen von Innerhalb gegen die Vertraulichkeit, Verfügbarkeitoder Integrität ausführen.• T.ADMIN… Administratives Personal Diese Kategorie beschreibt dieBedrohungen und Verwendung von Politiken, die Fehler in der Installation, imBetrieb, in der Verwaltung oder in der Ersetzung des EvaluierungsgegenstandsEVG beschreiben.• T.ATTACK…. Angreifer Ein Angreifer stellt einen unautorisierten Benutzervon außerhalb dar. Es ist eine Person, die unerlaubten Zugriff auf Datenvorsätzlich erzielen will. Hier wird eine vorsätzlich strafbare Handlung unterstellt.• T.HWSW…. Hardware / Software Diese Kategorie beschreibt Bedrohungen,die auf Versagen von Hardware, Software oder Firmware zurückzuführensind.Eine Liste allgemeiner Bedrohungen der Telematikinfrastruktur, welche die wesentlichenGrundprobleme abdecken, findet sich nachfolgend.T.USER• Es wird eine zu hohe Anzahl von auf Wissen basierenden Authentisierungsmerkmaleneingesetzt, dies führt zu Fehlern im Umgang.• Aufgrund nicht integerer Daten werden Entscheidungen getroffen, die negativefinanzielle, materielle und persönliche Folgen haben.• Benutzer erlangen unerlaubt Zugriff auf externe Dienste, wodurch bösartigeSoftware importiert wird.• Ein Versicherter wird dazu veranlasst den Zugriff auf seine vertraulichen Datenfreizugeben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 27 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturT.ADMINT.ATTACK• Durch eine mangelhafte Benutzerfreundlichkeit des Systems kommt es zu einererhöhten Fehlbedienungsrate und dadurch zu Datenschutz/Sicherheitsverletzungen.• Durch mangelnden Einsatz handhabbarer Technologien kommt es zumZwang zur Preisgabe vertraulicher Informationen von Mitgliedern verschiedenerGruppen (z. B. Behinderte). (Verstoß gegen das Antidiskriminierungsgesetz)• Ein Leistungserbringer signiert unwissentlich ein untergeschobenes Dokument.• Verlust von Entwicklungs-Know-how durch Abwanderung des Personals.• Zugriffe auf Daten in der Hoheit des Versicherten werden nicht auditiert.• Auditeinträge werden bewusst oder unbewusst gelöscht oder verändert.• Datenschutzverletzung durch ungeeigneten Aufbewahrungsort, ungeeignetenTransportweg, ungeeignete Entsorgung, unberechtigtes Kopieren von Medien.• Fehlerhaft konfigurierte Komponenten oder Dienste ermöglichen einen Angriffauf die TI.• Betreiben von nicht von der gematik zugelassenen IT- und Kommunikationskomponenten,dadurch werden Angriffe möglich und das angestrebte Sicherheitsniveaukann nicht nachgewiesen werden.• Bei Sicherheitsvorfällen wird ungeeignet reagiert, dies ermöglicht Angriffe oderDatenschutzverletzungen.• Sicherheitsverstöße werden durch unzureichendes Problembewusstsein in Sicherheitsfragenvon Akteuren in der Telematikinfrastruktur ermöglicht.• Sicherheitsrelevante Prozesse sind nicht hinreichend definiert und umgesetzt,dadurch werden Angriffe ermöglicht.• Eine unzureichende bzw. fehlende Festlegung von Verantwortlichkeiten führtzur Durchführung von unberechtigten Aktionen bzw. anderen Angriffen.• Durch unautorisierte Zusammenführung verschiedener Datenbestände werdenunerlaubt Profile erstellt oder die Vertraulichkeit von Daten verletzt.• Aufgrund eines ungeeigneten Umgangs mit oder bzw. ungeeigneterPIN/Passwörtern kann ein Angreifer unbefugt auf Daten zugreifen.• Vertrauliche und unverzichtbare Daten werden von einem Angreifer unbefugtgelesen, verändert oder gelöscht.• TI-relevante Daten werden von einem Angreifer unbefugt erstellt.• Vertrauliche personenbezogene Daten werden absichtlich oder unabsichtlichunbefugt ausgelesen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 28 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturT.HWSW• Angreifer nutzen Schwächen von Software-Produkten aus, um Malware einzubringen.• Eine Versichertenkarte wird verloren oder entwendet, ein Unberechtigter gibtsich als Besitzer aus, erspäht Daten des berechtigten Besitzers und lässt sichbehandeln.• Software-Produkte beinhalten neben ihrer offensichtlichen Funktionalität unerlaubteNebenfunktionen.• Ausfall einer technischen Komponente aufgrund eines Elementarereignisses(Feuer, Wasser, Blitz, Flugzeugabsturz, Terroranschlag, Ausfall der Stromversorgung,Überspannungs- & Unterspannungs-Schutz, Sabotage, Diebstahl)• Aufgrund mangelhafter Notfallsplanung und eines Notfalls, gelangen Daten ineine weniger sichere Umgebung, die nicht den Anforderungen entspricht.• Eine technische Störung führt zu (nicht häufigen) Veränderungen von Daten,so dass signierte Dokumente nicht mehr gültig sind.• Gespeicherte Daten gehen durch Versagen des Speichermediums, ungeeignetesBackup, äußere physikalische Einwirkungen oder eine allgemeine IT-Bedrohung verloren.• PKI-Dienste, die zur Verifikation von Sicherheitseigenschaften notwendig sind,sind nicht erreichbar. Durch die nicht möglichen Prüfungen könne Angriffedurchgeführt werden.• Unvorhersehbare Innovation im Bereich der Kryptoanalyse bzw. diese unterstützendeBasistechnologien die unter Umständen einen vorzeitigen Austauschaller Karten bedingen.• Die Beweiskraft (richterlicher Augenschein) elektronischer Signaturen wirddurch Präzedenzfälle bei denen berechtigte Zweifel bestehen, dass der Signaturerstellerdie Signatur auch tatsächlich erstellen wollte, verringert.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 29 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

3.4 Zusammenstellung der AusgangsanforderungenÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-IDAnfo Art Titel Beschreibung Rel. QuelleA_02266SVersichertensouveränitätFür alle Versicherten MÜSSEN alltagstaugliche, praktikable,technische Verfahren zur aktiven Wahrnehmung dieserBeteiligungsrechte bereitgestellt werden und die Durchsetzbarkeitder Betroffenenrechte ist zu gewährleisten. Beider Einführung der Telematikinfrastruktur sind die datenschutzrechtlichenAnforderungen zu gewährleisten. Diedatenschutzrechtliche Position des Versicherten ist zu stärken.Grundsätzlich hat der Versicherte die Datenhoheit füralle seine Anwendungen und Gesundheitsdaten in der Telematikinfrastruktur.Ohne die Einwilligung und Freigabedes Zugriffs durch den Versicherten können die freiwilligenmedizinischen Anwendungen nicht genutzt werden. BeiPflichtanwendungen entscheidet der Versicherte wer aufseine Daten zugreifen darf. Der Grundsatz der Freiwilligkeitder Speicherung von Gesundheitsdaten muss bewahrtwerden d. h.Kap. 3Die Versicherten müssen darüber entscheiden können,welche ihrer Gesundheitsdaten aufgenommen und welchegelöscht werden und ob und wenn ja, welche Daten sieeinem Leistungserbringer zugänglich machen.Die Versicherten haben das Informations- und Leserecht,über ihre in der Telematikinfrastruktur gespeicherten Datenund alle diese Daten betreffenden Vorgänge.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 30 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-IDAnfo Art Titel Beschreibung Rel. QuelleA_02267A_02268SSDatenhoheit_der VersichertenDatenschutzBei der Einführung der Telematikinfrastruktur wird sich diedatenschutzrechtliche Position der Versicherten nicht verschlechtern.Der Versicherte hat die Datenhoheit für alleseine §291a-Anwendungen und die darin enthaltenen Gesundheitsdatenin der Telematikinfrastruktur. Die gematikist dafür verantwortlich, dass technische Vorkehrungengetroffen und dem Versicherten verfügbar gemacht werden,mit denen sie die Zugriffsrechte und ihre Daten selbstaktiv verwalten können. Dabei muss die einfache Bedienbarkeitdieser Dienste der Telematikinfrastruktur für alleVersicherten sichergestellt sein. Alltagstaugliche Verfahrenzur aktiven Wahrnehmung der Versichertenrechte und derAusübung der Datenhoheit sind - ohne Einschränkungenim Recht auf informationelle Selbstbestimmung - eineGrundvoraussetzung für die Testvorhaben und den Wirkbetriebder Telematikinfrastruktur.Für den datenschutzgerechten Einsatz der Telematikinfrastrukturund der Gesundheitskarte ist eine konsequenteund überzeugende Sicherheitstechnologie erforderlich.Für die automatisierte Verarbeitung und Nutzung derpersonenbezogenen Daten der Versicherten in der Telematikinfrastruktur,MÜSSEN insbesondere Maßnahmengetroffen werden (siehe Anhang zu § 9 Satz 1 BDSG), dieje nach der Art der zu schützenden personenbezogenenDaten oder Datenkategorien geeignet sind,Kap. 3Kap. 3• Unbefugten den Zutritt zu Datenverarbeitungsanlagen,mit denen personenbezogene Daten verarbeitet oder genutztwerden, zu verwehren (Zutrittskontrolle mit demSchutzziel der Integrität der IT-Systeme),gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 31 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-IDAnfo Art Titel Beschreibung Rel. Quelle• zu verhindern, dass Datenverarbeitungssysteme von Unbefugtengenutzt werden können (Zugangskontrolle mitdem Schutzziel der Integrität der IT-Systeme),• zu gewährleisten, dass die zur Benutzung eines DatenverarbeitungssystemsBerechtigten ausschließlich auf dieihrer Zugriffsberechtigung unterliegenden Daten zugreifenkönnen, und dass personenbezogene Daten bei der Verarbeitung,Nutzung und nach der Speicherung nicht unbefugtgelesen, kopiert, verändert oder entfernt werden können(Zugriffskontrolle mit den Schutzzielen Authentizität, Integritätund Autorisierung),• zu gewährleisten, dass personenbezogene Daten bei derelektronischen Übertragung oder während ihres Transportsoder ihrer Speicherung auf Datenträger nicht unbefugt gelesen,kopiert, verändert oder entfernt werden können, unddass überprüft und festgestellt werden kann, an welcheStellen eine Übermittlung personenbezogener Daten durchEinrichtung zur Datenübertragung vorgesehen ist (Weitergabekontrolledurch eine Informationsflusskontrolle die dieSchutzziele Vertraulichkeit, Integrität, Authentizität undAutorisierung gewährleistet),• zu gewährleisten, dass nachträglich überprüft und festgestelltwerden kann, ob und von wem personenbezogeneDaten in Datenverarbeitungssysteme eingegeben, verändertoder entfernt worden sind (Eingabekontrolle durchRevisionsfähigkeit der Protokollierung und Nichtabstreitbarkeitder Datenübermittlung),• zu gewährleisten, dass personenbezogene Daten, die imAuftrag verarbeitet werden, nur entsprechend den Weisungendes Auftraggebers verarbeitet werden können (Auftragskontrolledurch eine Rechteverwaltung durch den Ver-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 32 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-IDAnfo Art Titel Beschreibung Rel. QuelleA_02269SBSI_GK und BSILFsicherten die eine benutzerbestimmte Informationsflusskontrolleermöglicht),• zu gewährleisten, dass personenbezogene Daten gegenzufällige Zerstörung oder Verlust geschützt sind (Verfügbarkeitskontrollemit den Schutzzielen Verfügbarkeit undIntegrität). Weitere Bedrohungen u. a. eine unbefugte Vorenthaltungvon Informationen oder Betriebsmitteln z. B.durch Denial-of-Service-Attacks werden durch diesesSchutzziel ebenfalls abgedeckt.• zu gewährleisten, dass zu unterschiedlichen Zweckenerhobene Daten getrennt verarbeitet werden.Diese Schutzziele sind sowohl zu gewährleisten, wenn dieDaten auf der Chipkarte gespeichert werden, als auchdann, wenn sie in einer Komponente der Telematikinfrastrukturgespeichert werden, die durch die Gesundheitskartezugänglich gemacht wird.Die in [BSI, IT Sicherheit auf Basis der Common Criteria -ein Leitfaden (31.10.2007)] und [BSI (2005):IT-Grundschutz-Kataloge] aufgeführten Bedrohungs- bzw.Maßnahmenkataloge MÜSSEN bei den spezifischen Sicherheitskonzeptenbetrachtet werdenKap. 3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 33 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur4 SicherheitsstrategieDieses Kapitel beschreibt die grundlegenden Sicherheitsprinzipien, auf denen die Telematikinfrastrukturberuht und die Entscheidungen innerhalb des Sicherheitskonzepts für Sicherheitsprozesseund die Sicherheitsarchitektur nach sich ziehen.Es werden zunächst die Eckpunkte der Sicherheitsstrategie vorgestellt. Danach werdendie getroffenen Entscheidungen für Prozesse und Architektur aus diesen Sicherheitsprinzipienabgeleitet und die Vorgehensweise zur Umsetzung der Sicherheitsstrategie vorgestellt.4.1 Eckpunkte der SicherheitsstrategieAufgrund des sehr hohen Schutzbedarfs der Daten, die in der Telematikinfrastruktur gespeichertund übertragen werden, sind abgestimmte organisatorische und technische Sicherheitsmaßnahmenzur Begrenzung der Schadenshöhe sowie der Reduktion der Bedrohungennotwendig, um damit ein akzeptables Niveau der Restrisiken zu erreichen.Diese Eckpunkte zur Begrenzung der Restrisiken sind in der nachfolgenden Abbildung 3dargestellt.akzeptableRestrisikenSehr hochSchadenshöhehochmittelniedrigSchutz der VersichertendateneGK & HBAStarke KryptoalgorithmenversichertenindividuelleVerschlüsselung2-Karten PrinzipProaktive Prozesseschnelle ReaktionAufteilung in Zonenevaluierte KomponentenDatenvermeidungDatensparsamkeitBegrenzung der SchadenshöheTelematikinfrastrukturniedrig mittel hoch sehr hochEintrittswahrscheinlichkeitTechnische und organisatorischeMaßnahmen zur RisikoreduktionAbbildung 3: Strategie zur Begrenzung der Restrisiken.Folgende Eckpunkte bilden die Grundlage der Sicherheitsstrategie.• Übergreifendes Sicherheitskonzept angepasst an die aktuellen Bedrohungenund Risiken (siehe AS_EP_01 in Kapitel 4.1.1).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 34 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Der Schutz der Daten und des Zugriffs und damit eine Verringerung derBedrohungen und damit der Eintrittswahrscheinlichkeit eines Schadens wirdim Wesentlichen durch die nachfolgenden Eckpunkte erzielt:• 2 Karten-Prinzip (HBA/SMC, eGK) und damit nur einen Zugriff berechtigterLeistungserbringer auf die Daten des Versicherten (siehe AS_EP_02 in Kapitel4.1.2).• Schutz der Daten in der Telematikinfrastruktur durch Kryptoalgorithmenmit Mechanismenstärke mindestens „hoch“ (siehe AS_EP_03 in Kapitel 4.1.3).• Versichertenindividuelle Verschlüsselung der Daten mit Schlüsseln in derHoheit des Versicherten (siehe AS_EP_04 in Kapitel 4.1.4).• Eine Begrenzung der Schadenshöhe wird im Wesentlichen durch die Berücksichtigungder folgenden Eckpunkte erzielt:• Datenvermeidung, Datensparsamkeit und Datentrennung (keine Datensammlung)(siehe AS_EP_05 in Kapitel 4.1.5).• Aufteilung der Architektur in gestufte Sicherheitszonen mit evaluierten Komponentenund Diensten für sicherheitskritische Funktionen (siehe AS_EP_06in Kapitel 4.1.6).• Proaktive Prozesse zur schnellen Reaktion mit getesteten Notfall- und Ersatzmaßnamen(siehe AS_EP_07 in Kapitel 4.1.7).• Der Schutz der Beteiligten Die an der Telematikinfrastruktur Beteiligten(Versicherte, Leistungserbringer und deren Mitarbeiter) MÜSSEN sicher seinkönnen, dass das besondere Vertrauensverhältnis zwischen Versicherten undLeistungserbringer durch die Nutzung der Telematikinfrastruktur nicht gestörtwird (siehe AS_EP_08 in Kapitel 4.1.8).4.1.1 Übergreifendes SicherheitskonzeptEin übergreifendes Sicherheitskonzept ist eines der zentralen Dokumente bei der Entwicklungder Telematikinfrastruktur und in §291b Abs.1 Satz 1 explizit gefordert. In diesemSicherheitskonzept der gematik werden die von der Telematikinfrastruktur zu gewährleistendenSicherheitsziele und Sicherheitsanforderungen basierend vor allem aufgesetzlichen Vorgaben und dem daraus resultierenden Schutzbedarf der Informationsobjektedefiniert. Das Sicherheitskonzept gibt die organisatorischen und technischen Mindeststandardsvor, die für die gesamte Telematikinfrastruktur in allen „Lebensphasen“mindestens eingehalten werden MÜSSEN, um das notwendige Sicherheitsniveau zu gewährleisten.Nr.EckpunktAS_EP_01 Übergreifendes Sicherheitskonzept(siehe §291b, Absatz 1, SGB V)Das übergreifende Sicherheitskonzeptοοenthält eine, vor allem auf gesetzlichen Vorgaben basierendeSchutzbedarfsanalyse (siehe Anhang C),definiert die mindestens zu erreichenden Schutzziele (siehe Kap.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 35 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.Eckpunkt5.3, 7.3 und Anhang C), die in den Designentscheidungen für dieArchitektur, die Dienste und Komponenten der Telematikinfrastrukturumgesetzt werden MÜSSEN. Die Risiken werden gemindertdurch die Umsetzung der Eckpunkte der Sicherheitsstrategie sowohldurch die Begrenzung der Schadenshöhe als auch durch denSchutz der Daten des Versicherten.οοstellt Mindestanforderungen an sicherheitsrelevante Prozesse, Rollenund Verantwortlichkeiten (siehe u. a. Kap. 8, Anhang D, G)wird zeitgerecht aktualisiert um die Angemessenheit und Wirksamkeitder Maßnahmen zu prüfen und auf neue Bedrohungen angemessenzu reagieren (siehe auch AS_EP_07).Konsequenzen:οοSchutzprofile, Sicherheitskonzepte und Sicherheitsprofile derDienste und Komponenten der Telematikinfrastruktur MÜSSEN dievon der gematik vorgegebenen und aktuell gültigen Mindestanforderungenund Mindeststandards einhalten und in ihrem jeweiligenGültigkeitsbereich die konkreten Sicherheitsmaßnahmen definierensowie die Wirksamkeit der realisierten Maßnahmen zeigen.Umsetzung der Anforderungen und EckpunkteMaßnahmen zur Reduktion von Schadenspotentialen wird im Entscheidungsfallegegenüber Maßnahmen zur Reduktion der Eintrittswahrscheinlichkeiteines Schadens der Vorzug gegeben. ZurVerringerung des Schadenspotentials bei einer möglichen Kompromittierungmuss eine Aufteilung der Architektur in mehreren Dimensionenmit unabhängigen Sicherheitsmaßnahmen erfolgen.Insbesondere muss eine Aufteilung in• OSI-Schichten z. B. Trennung der Sicherheitsdienste auf Netzwerk-(siehe Kap. 7.1) und Anwendungsschicht (siehe Kap.7.2).οο• verschiedene Tiers in gestuften Sicherheitszonen (siehe Kap.7.4 Zonenkonzept)berücksichtigt werden. Die Datenhaltung SOLL verteilt erfolgen.Jährliche Anpassung der übergreifenden Mindeststandardsum die Angemessenheit und Wirksamkeit der Maßnahmen zu prüfenund auf neue Bedrohungen angemessen zu reagieren. Die Sicherheitsvorschriftenwerden dadurch kontinuierlich an die Prozessrisikenund Bedrohungen angepasst. Ein entsprechender Sicherheitsmanagement-Prozesswird definiert und für die Telematikinfrastrukturbereitgestellt (siehe auch AS_EP_07).4.1.2 Zwei-Karten-Prinzip für den Zugriff auf medizinische DatenDer Zugriff auf Daten des Versicherten mittels der elektronischen Gesundheitskarte ist in§291a Abs. 5 geregelt und darf (bis auf die im §291a Abs. 5 definierten Ausnahmefälle)nur in Verbindung mit einem elektronischen Heilberufsausweis erfolgen. Damit sind derZugriff und die Verarbeitung von Daten unter Einsatz der elektronischen Gesundheitskartegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 36 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturgrundsätzlich an zwei Voraussetzungen gebunden. Erstens muss der eGK-Inhaber in derRegel den Zugriff freigeben (z. B. durch einen PIN-Code) und zweitens wird grundsätzlichvorgeschrieben, dass der Zugriff auf Versichertendaten nur von berechtigten Leistungserbringernerfolgt und ein missbräuchlicher Zugriff von Personen außerhalb des Gesundheitswesensohne einen entsprechenden Heilberufsausweis verhindert wird. Mit elektronischenHeilberufsausweisen werden die zugreifenden Leistungserbringer eindeutig authentifiziert.Mit einer SMC werden Leistungserbringer-Institutionen authentifiziert. DieInstitutionenkarte (SMC) ist bezüglich der Zugriffe auf die eGK einem personenbezogenenHBA gleichgestellt. Es muss dabei im Primärsystem nachweisbar protokolliert werden,wer auf die Daten zugegriffen hat und von welcher Person die zugreifende Person autorisiertwurde.Abbildung 4 illustriert das Zwei-Karten-Prinzip. Im äußeren Ring, in dem weder die eGKnoch ein HBA/SMC vorhanden sind, ist ein Zugriff auf Daten von Versicherten nicht möglich.Gleiches gilt für den Fall, in dem nur ein HBA/SMC, aber keine eGK vorliegen 5 . Alleinemittels der eGK ist ein Zugriff in der Regel ebenfalls nicht möglich. Ausnahme ist derVersicherte selbst, der durch Eingabe der zur eGK gehörenden PIN in begrenztem Umfangauf seine Daten zugreifen kann (z. B. das Lesen von elektronischen Verordnungen).Ein Zugriff auf die medizinischen Daten eines Versicherten ist nur bei der Anwesenheitbeider Karten möglich: die eGK dient als Mittel, mit dem der Versicherte zu einem Zugriffauf seine Daten einwilligt und der HBA/SMC erzwingt, dass ausschließlich die im §291aAbs. 4 genannten Personen auf die Daten eines Versicherten zugreifen können. In Fällen,in denen der Versicherte nicht anwesend ist, ist ein geeignetes, nachvollziehbares technischesVerfahren einzusetzen, bei dem die Zustimmung und Information des Versichertennachvollziehbar und revisionsfähig sichergestellt ist.Abbildung 4: Zwei-Karten-PrinzipNr.EckpunktAS_EP_02 2 Karten-Prinzip (eGK, HBA/SMC)(siehe §291a, Abs. 5, SGB V)Der Zugriff auf medizinische Daten mittels der elektronischen GesundheitskarteMUSS in Verbindung mit einem elektronischen Heilberufsausweisoder mittels einer SMC erfolgen, die über eine Möglichkeit zur sicherenAuthentifizierung verfügen. Der HBA MUSS über eine qualifizierte elektro-5 In dieser Darstellung wird bewusst auf Ausnahmefälle verzichtet, in denen Leistungserbringerauch ohne Anwesenheit der eGK auf Daten des Versicherten zugreifen können, da der Fokus diesesAbschnittes auf der Erklärung des Grundprinzips liegt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 37 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.Eckpunktnische Signatur verfügen. Der Zugriff mittels SMC ist nur für die Personengruppenach §291a Abs. 4 Satz 1 Nr. 1 Buchstabe d und e sowie Nr. 2Buchstabe d und e SGB V möglich. Es MUSS dabei im Primärsystemnachweisbar protokolliert werden, wer auf die Daten zugegriffen hat undvon welcher Person die zugreifende Person autorisiert wurde.Konsequenzen:οοοDie aktuelle Gültigkeit der Karten muss vor der Verwendung unddem Zugriff geprüft werden und Verfahren zum Sperren verlorengegangener oder kompromittierter Karten (eGK, HBA, SMC) MÜS-SEN bereitgestellt werden.Kartenmanagementprozesse müssen sicherstellen, dass Karten(eGK, HBA, SMC) nur an Berechtigte ausgegeben werden (sieheauch Anhang E).In Fällen, in denen die eGK des Versicherten nicht anwesend ist,MUSS ein geeignetes, nachvollziehbares technisches Verfahreneingesetzt werden, bei dem die Zustimmung und Information desVersicherten nachvollziehbar und revisionsfähig sichergestellt ist(siehe auch Kapitel 7.5).4.1.3 Schutz der Daten in der TelematikinfrastrukturDie Telematikinfrastruktur enthält personenbezogene Daten, die nach §9 BDSG durchtechnische und organisatorische Maßnahmen zu schützen sind. Eine unautorisierte Bekanntgabevon in der Telematikinfrastruktur befindlichen Daten kann das für eine erfolgreichemedizinische Behandlung und Versorgung zwingend notwendige Vertrauensverhältniszwischen Leistungserbringern und Versicherten gefährden und so die Qualität derGesundheitsfürsorge senken. Ebenso dürfen unautorisiert modifizierte oder zerstörte Datenin der Telematikinfrastruktur nicht mehr als Grundlage für Behandlungen und Begutachtungenherangezogen werden, da eine Verfälschung oder Unvollständigkeit zu falschenmedizinischen Entscheidungen mit gesundheitlichen Folgen für den Versichertenund rechtlichen Konsequenzen für die Leistungserbringer führen können.Nr.EckpunktAS_EP_03 Schutz der Informationen durch starke KryptoalgorithmenDie unautorisierte Modifikation oder Zerstörung von Daten, die unautorisierteBekanntgabe von Informationen MÜSSEN beim Transfer von Daten,bei deren Verarbeitung und Speicherung in der Telematikinfrastruktur mitKryptoalgorithmen mindestens der Mechanismenstärke „hoch“ erkannt bzw.verhindert werden.Konsequenzen:οοSicherheitsdienste und Sicherheitsinfrastrukturen der Mechanismenstärke„hoch“ und „sehr hoch“ MÜSSEN von der Telematikinfrastrukturbereitgestellt werden und MÜSSEN entsprechend derSchutzbedarfsfestlegung für die fachlichen und technischen Objekteverwendet werden.Der aktuell gültige Algorithmenkatalog der gematik MUSS verwendetwerden (siehe Anhang F).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 38 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur4.1.4 Versichertenindividuelle VerschlüsselungDie Daten der Versicherten gemäß §291a Absatz 2 und Absatz 3 sind in der Telematikinfrastrukturimmer verschlüsselt. Die Verschlüsselung der medizinischen Daten einesVersicherten erfolgt individuell für diesen Versicherten und die zur Entschlüsselung notwendigenSchlüssel liegen in der alleinigen Hoheit des Versicherten. Der Versichertekann damit steuern, wem er welche seiner Daten unter welchen Bedingungen herausgibt.Nr.EckpunktAS_EP_04 Versichertenindividuelle VerschlüsselungMedizinische Daten sind in der Telematikinfrastruktur immer verschlüsselt(siehe [Grundsatzentscheidung]) und im Klartext nicht verfügbar und bearbeitbar.Die Verschlüsselungsschlüssel sind in der alleinigen Verfügungsgewalt desVersicherten, damit dieser und nur dieser entscheiden kann, welche Datenwelchen dritten Personen zugänglich gemacht werden.Konsequenzen:οDie Anforderungen an die Verwaltung der Verschlüsselungsschlüsselwerden in Anhang F – Kryptographiekonzept festgelegt.4.1.5 Datenvermeidung, Datensparsamkeit und DatentrennungDurch das Prinzip der Datensparsamkeit, d. h. die Vermeidung der Speicherung vertraulicherpersonenbezogener Daten, sollen Vertraulichkeitsrisiken per se verringert werden.Im Speziellen müssen hier operationale und technische Anforderungen (z. B. Logfiles)gegenüber Datenschutzanforderungen abgewogen werden. Kann eine Speicherung vertraulicherDaten aufgrund einer höher bewerteten Anforderung nicht vermieden werden,müssen diese Daten – entsprechend der Zweckbestimmung- dezentralisiert und organisatorischgetrennt vorgehalten werden. Ein direkter Zugriff auf die Daten des jeweils anderenzur Verknüpfung der Datenbestände darf in einem solchen Fall nicht möglich sein.Nr.EckpunktAS_EP_05 Datenvermeidung und Datentrennung(Siehe §3a, BDSG, §78b, SGBX)Um u. a. das Erstellen von Bewegungsprofilen oder z. B. eine Analyse desVerschreibungsverhalten, zu verhindern, DÜRFEN in der Telematikinfrastrukturnur die minimal für die Funktionalität notwendigen Daten übertragenund gespeichert werden. Die Daten sind in der Telematikinfrastrukturso zu übertragen bzw. zu speichern, dass eine Zusammenführung undProfilbildung nicht möglich ist.Soweit es möglich ist, wird eine zeitliche, räumliche, technische und organisatorischeTrennung der gespeicherten Daten angestrebt um Datensammlungenzu vermeiden. Insbesondere ist von den Möglichkeiten der Anonymisierungund Pseudonymisierung Gebrauch zu machen, soweit dies möglichist und der Aufwand in einem angemessenen Verhältnis zu dem angestrebtenSchutzzweck steht.Konsequenzen:οDie Erfordernisse des Datenschutzes sind bei allen Architekturentscheidungenexplizit zu berücksichtigen und es sind nur die mini-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 39 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.Eckpunktmal notwendigen Informationen entsprechend der festgelegtenZweckbestimmung zu übertragen und zu speichern.4.1.6 Aufteilung der Architektur in gestufte SicherheitszonenGestufte Sicherheitszonen mit einheitlichen Sicherheitsmaßnahmen werden eingeführtund erlauben eine unabhängige Sicherheitsbetrachtung innerhalb einer (Sub-)Zone, dasich Schwachstellen, Bedrohungen, Risiken und Sicherheitsmaßnahmen nur innerhalbeiner Sicherheitszone auswirken und daher zu einheitlichen Schutzprofilen zusammenstellenlassen. Das Zonenkonzept stellt ein Rahmenwerk für die Aufteilung in unabhängige,schwach gekoppelte Sicherheitszonen zur Verfügung. Sicherheitszonen unterscheidensich durch:• den Eigentümer der Prozesse und Daten,• die Klassifikation und Sensitivität der vorhandenen Daten,• die Benutzergruppen, die auf diese Daten zugreifen dürfen,• die Bedrohungen, die in der Risikoanalyse zu berücksichtigen sind.Eine sicherheitstechnische Trennung der Architekturschichten bzw. der Sicherheitsmechanismenauf den unterschiedlichen OSI-Schichten wird durchgeführt.Für besonders sicherheitskritische Komponenten muss die Wirksamkeit der Sicherheitsmaßnahmenim Rahmen der Evaluierung und Zulassung nachgewiesen werden.Nr.EckpunktAS_EP_06 Aufteilung in gestufte Zonen mit evaluierten KomponentenDie Telematikinfrastruktur wird in Sicherheitszonen entsprechend Kap. 7.4aufgeteilt.Konsequenzen:οVertrauenswürdige Einrichtung zur Datenverarbeitung SicherheitskritischeKomponenten und Dienste der Telematikinfrastrukturmüssen die Wirksamkeit der Sicherheitsmassnahmen im Gegenstandder Evaluation durch zugelassene Prüfstellen bzw. im Rahmender Zulassungsverfahren der gematik zeigen.4.1.7 Proaktive Prozesse zur schnellen ReaktionEine vollständige Vermeidung von Schwachstellen ist nicht möglich – u. a. werden laufendneue Bedrohungen festgestellt. Diese vorhandenen Restrisiken sollen berücksichtigt unddurch schnelle Reaktionszeiten – u. a. mit getesteten Notfall- und Ersatzmaßnamen - begrenztwerden. Damit werden die Risiken beim Ausnutzen auftretender Schwachstellenbegrenzbar und beherrscht. Die Zeitintervalle für die Erkennung eines Angriffs und derdarauf folgenden Reaktion sollte zusammen geringer sein, als das Zeitintervall für einenerfolgreich durchgeführten Angriff. Bei der Gestaltung der Sicherheitsmanagement-Prozessesind die folgenden Punkte bei der Ausgestaltung der Prozesse zu berücksichtigen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 40 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Reaktion: Festlegung der maximalen Reaktionszeit für alle Prozesse undMaßnahmen, die bei auftretenden Angriffen eine schnelle Reaktion erlauben,um die eingetretenen Schäden zu begrenzen. Beispiele sind CERT-Teamsund die Definition und Bereitstellung von Notfall- und Ersatzmaßnahmen; z. B.Installieren einer neuen Virenkennung, eines Sicherheitspatches innerhalb dermaximalen Ausfallzeit einer Anwendung oder ggf. umschalten auf einen definiertenErsatzprozess.• Entdecken: Festlegung der maximalen Erkennungszeit für alle Prozesse undMaßnahmen die es erlauben, Angriffe und Schwachstellen frühzeitig zu entdecken.Beispiele sind Intrusion Detection Systeme, die Abweichungen vom inder Sicherheitsarchitektur festgelegten Verhalten entdecken und die entsprechendenStellen alarmieren. Ein aktueller Angriff auf eine neue Sicherheitsschwachstellemuss so schnell entdeckt werden können (z. B. durch IDS),dass innerhalb der maximalen Ausfallzeit die entsprechenden Gegenmaßnahmenin dem entsprechenden operationalen System installiert werden können.• Vorbeugen: Festlegen einer maximalen Reaktionszeit für alle Prozesse undMaßnahmen, die potentielle Schwachstellen schließen, z. B. durch die Installationaller neuen Sicherheitspatches auf den möglicherweise betroffenen Systemen.Nr.EckpunktAS_EP_07 Proaktive Prozesse zur schnellen ReaktionAuf erkannte Schwachstellen und Kompromittierungen MUSS eine schnelleReaktion erfolgen und eine koordinierte, proaktive Bereitstellung von Ersatz-und Notfallmaßnahmen MUSS vorgesehen werden. Proaktivität bedeutetfrühzeitiges Handeln, noch ehe der volle Schaden eingetreten ist.Daher MÜSSEN proaktiv Notfall- und Ersatzmaßnahmen geplant werdenum zu gewährleisten, dass diese bei einem Sicherheitsvorfall innerhalb derdefinierten Reaktionszeiten zum Tragen kommen und so die Auswirkungendes Sicherheitsvorfalles begrenzen.Konsequenzen:οDie Sicherheitsmanagement-Prozesse müssen entsprechend denMindestanforderungen in Kapitel 8 sowie Anhang G aufgebautwerden.4.1.8 Schutz der Beteiligten„Wer sich in Behandlung begibt, muss und darf erwarten, dass alles, was der Arzt imRahmen seiner Berufsausübung über seine gesundheitliche Verfassung erfährt, geheimbleibt und nicht zur Kenntnis Unbefugter gelangt. Nur so kann zwischen Versicherten undArzt jenes Vertrauen entstehen, das zu den Grundvoraussetzungen ärztlichen Wirkenszählt, weil es die Chancen der Heilung vergrößert und damit – im Ganzen gesehen – derAufrechterhaltung einer leistungsfähigen Gesundheitsfürsorge dient.“ (BVerfG 32, 373,380). Die in der ärztlichen Berufsordnung und dem Strafgesetzbuch normierte ärztlicheSchweigepflicht schützt das Vertrauensverhältnis zwischen Versicherten und Arzt. Leistungserbringermüssen die Vertraulichkeit der erhobenen, gespeicherten, übermitteltenoder sonst verarbeiteten Daten gewährleisten, d. h. nur Befugte dürfen personenbezogeneDaten zur Kenntnis erhalten bzw. davon Kenntnis nehmen können. Auch die daten-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 41 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturschutzrechtlichen Regelungen, die das Recht des Versicherten auf informationelle Selbstbestimmungkonkretisieren, schützen die Vertrauensbeziehung zwischen Versichertenund Leistungserbringer. Eine Kenntnisnahme medizinischer Daten durch Unbefugte (z. B.Arbeitgeber, Versicherungen, Pharmaindustrie) kann erhebliche soziale bzw. materielleFolgen für den Versicherten nach sich ziehen.Nr.EckpunktAS_EP_08 Schutz der BeteiligtenDie an der Telematikinfrastruktur Beteiligten (Versicherte, Leistungserbringerund deren Mitarbeiter, Kostenträger) MÜSSEN sicher sein, dass dierechtlichen Vorgaben von der Telematikinfrastruktur technisch erzwungenwerden. Durch einen vorbeugenden Ausschluss unzulässiger Zugriffe (sieheKap. 7.7) sowie eine nachträgliche Erkennung unzulässiger Zugriffe(siehe Kap. 7.8) MUSS technisch ein Schutz der Beteiligten vor ungerechtfertigtenVerdächtigungen bereitgestellt werden.4.2 Schutzziele der TelematikinfrastrukturAus den sicherheitsstrategischen Eckpunkten leiten sich die Schutzziele der Telematikinfrastrukturab. Die Grundprinzipien haben teilweise eine Entsprechung im Datenschutz,wo sie sich aus der Verlässlichkeit und Beherrschbarkeit des Systems ableiten. Teile derGrundprinzipien basieren auf Anforderungen der Datenschutzbeauftragten der Ländersowie des Bundes an Systeme der medizinischen Datenverarbeitung im Gesundheitswesen[BWB02]Im Bereich der Informationssicherheit lassen sich bestimmte Schutzziele definieren, diean ein IT-System oder eine IT-Infrastruktur gestellt werden. Diese Sicherheitsziele geltenfür die TI und die verschiedenen medizinischen Anwendungen. Dazu gehören folgendePunkte:• Verfügbarkeit: Die Verfügbarkeit aller erfassten, übermittelten und gespeichertenDaten muss gewährleistet sein. Das bedeutet, dass die Daten einesVersicherten immer zeitnah zur Verfügung stehen müssen, um ordnungsgemäßbe- und verarbeitet werden zu können.• Vertraulichkeit: Personenbezogene Daten (insbesondere Sozialdaten undmedizinische Daten) im Umfeld der medizinischen Versorgung müssen in derRegel als streng vertraulich behandelt werden. Dieser Vertraulichkeitsanspruchdes Versicherten ist in verschiedenen Gesetzen festgelegt. Des Weiterenbeinhaltet der Anspruch nach vertraulicher Behandlung von Daten denAnspruch des Versicherten, seine informationelle Selbstbestimmung wahrnehmenzu können, indem er die Daten nur Berechtigten zugänglich macht.Eine Verletzung dieser Sicherheitsanforderung kann für den Versicherten zunicht unerheblichen sozialen oder materiellen Schäden führen. Andererseitsmuss der Versicherte darüber informiert werden, dass er dieses Recht auf informationelleSelbstbestimmung dem behandelnden Arzt bzw. dem Leistungserbringerund sich selbst gegenüber in vertrauenswürdiger Weise nutzensollte, damit Schadensfälle vermieden werden. Aus den EckpunktenAS_EP_03 und AS_EP_04 ergibt sich, dass die personenbezogenen Datenbei der Übertragung und Speicherung in der Telematikinfrastruktur versichertenindividuellverschlüsselt sein müssen. Das Schlüsselmanagement mussgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 42 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturnach dem aktuellen Stand der Technik und Wissenschaft sicher sein (sieheAnhang F).• Integrität: Die Integrität der erhobenen, verarbeiteten, transportierten und gespeichertenDaten muss gewährleistet sein. Die Daten dürfen nicht unbemerktmanipuliert werden. Ihre Korrektheit und Echtheit ist für den Behandlungserfolgwichtig.• Authentizität: Die Authentizität der im medizinischen Umfeld erhobenen, gespeicherten,verarbeiteten und transportierten Daten muss gewährleistet sein,d.h. der Autor bzw. der Verantwortliche von patientenbezogenen Daten sowieder Auslöser eines Verarbeitungsganges muss jederzeit eindeutig feststellbarsein (siehe AS_EP_08). Dabei ist es unerheblich, ob es sich dabei um einenatürliche Person, eine Organisation oder eine technische Komponente handelt.Des Weiteren muss die Herkunft (eine natürliche oder juristische Person)der im Rahmen der Personalisierung auf eine Karte aufgebrachten Daten ausder Sicht der personalisierenden Stelle eindeutig bestimmbar und prüfbarsein.• Nichtabstreitbarkeit von Datenübermittlung: Die Nichtabstreitbarkeit desSendens und Empfangens von patientenbezogenen Informationen/ Dokumentenmuss gewährleistet sein (siehe AS_EP_08). Diese Nichtabstreitbarkeitmuss sich sowohl auf den Vorgang der Übertragung wie auch auf das Objektder Übertragung beziehen. Die Nichtabstreitbarkeit ist eine Voraussetzung derRevisionsfähigkeit.• Autorisierung und Zugriffskontrolle: Medizinische Datenverarbeitungssystememüssen es ermöglichen, dass der Kreis der Zugriffsberechtigten aufpersonenbezogene Daten und insbesondere medizinische Daten des Versichertendurch abgestufte Nutzungsrechte exakt bestimmbar und abgrenzbarist. Durch geeignete Verfahren ist sicherzustellen, dass ein Zugriff auf die Datendes Versicherten nur mit seinem Einverständnis erfolgen kann. Sollte derVersicherte nicht in der Lage sein, diese Rechte wahrnehmen zu können, soist durch geeignete organisatorische wie auch technische Verfahren sicherzustellen,dass entsprechend den gesetzlichen Vorgaben seine medizinischeVersorgung nicht beeinträchtigt wird. Die Erteilung von Zugriffsberechtigungendarf bei den medizinischen Pflichtanwendungen nicht zu Diskriminierungenauf Grund der angewandten technischen Verfahren führen.Der Versicherte ist der Besitzer seiner Informationsobjekte. Er ist Zugriffsberechtigterfür seine Informationsobjekte welche auf Verlangen der Versichertengelöscht werden müssen (§291a Abs. 4 und Abs. 6). Neben dem Versichertendürfen auf Informationsobjekte des Versicherten ausschließlich die im§291a Abs. 4 genannten Personen (im Folgenden als Leistungserbringer bezeichnet)zugreifen, wenn sie vom Versicherten entsprechend autorisiert wurden(siehe AS_EP_02, AS_EP_04). Nur der Versicherte kann diese Autorisierungdurchführen. Der Versicherte kann erteilte Zugriffsberechtigungen jederzeitzurücknehmen.Das Erzeugen und jede Änderung der Zugriffsinformation eines Informationsobjekteseines Versicherten kann ebenfalls nur auf Basis einer Einwilligungdes Versicherten (Besitzer des Informationsobjektes) erfolgen.Durch technische Vorkehrungen ist zu gewährleisten, dass der Zugriff auf Datendes Versicherten nur durch Autorisierung des Versicherten möglich istgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 43 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur(§291a Abs. 5).Medizinische Datenverarbeitungssysteme müssen es ermöglichen, für jedespatientenbezogene Dokument den Nutzerkreis sowie abgestufte Nutzungsrechtefestzulegen und Nutzungsausschlüsse zu definieren.Vom Versicherten darf nicht verlangt werden, den Zugriff auf seine Informationsobjekteanderen Personen als den in §291a Abs. 4 genannten Leistungserbringernoder zu anderen Zwecken als der Versorgung des Versicherten zugestatten. Es darf auch nicht vereinbart werden, Derartiges zu gestatten.• Revisionsfähigkeit: Die Revisionsfähigkeit der erhobenen, gespeicherten,übermittelten oder verarbeiteten Daten muss gewährleistet sein, damit dieVerarbeitungsprozesse lückenlos nachvollzogen werden können. Für denArzt, Apotheke bzw. das Krankenhaus besteht nach der Berufsordnung diePflicht zur Dokumentation der Behandlung. Diagnosen und Therapien müssenzwecks Ausschluss von Haftungen lückenlos nachvollziehbar werden. Die e-xistierenden Systeme der Leistungserbringer und Kostenträger decken dieseAnforderungen der Revisionsfähigkeit ab.4.3 Überblick über die TelematikinfrastrukturDie zuvor definierten Eckpunkte und daraus abgeleiteten Grundprinzipien beeinflussenden Entwurf der Architektur der Telematikinfrastruktur. Dieser Abschnitt gibt einen grobenÜberblick über die Architektur und dient als Grundlage, für Abschnitt 4.4, in dem die Konsequenzender Eckpunkte und Grundprinzipien auf die Architektur und Prozesse dargestelltwerden. Für eine ausführliche Architekturbeschreibung ist auf [gemGesArch] verwiesen.Die elektronische Gesundheitskarte (eGK) des Versicherten ist ein wichtiger Teil der Lösungsarchitektur.Mit einer gültigen eGK identifizieren sich Versicherte und haben mit derKarte die Möglichkeit, persönliche Gesundheitsdaten zu verwalten und einzelnen Leistungserbringernzur Verfügung zu stellen. Die eGK ist das Mittel des Versicherten, umseine Einwilligung zum Erheben, Verarbeiten und Nutzen seiner Informationsobjekte auszudrücken.Der Versicherte willigt bei Pflichtanwendungen (gemäß §291a) durch Übergabeseiner eGK und bei freiwilligen Anwendungen zusätzlich durch Eingabe der PIN(Ausnahme: Notfalldaten) in die Nutzung seiner Daten ein.Die Identifikation von Leistungserbringern erfolgt durch einen elektronischen Heilberufsausweis(HBA/SMC), d. h. mit dieser Karte weisen sich Leistungserbringer wie Ärzte undApotheker beim Zugriff auf medizinische Daten aus. Der HBA garantiert, dass nur die in§291a Abs. 4 genannten Personengruppen auf medizinische Daten zugreifen können. DieIdentifikation einer Institution (z. B. Apotheke, Krankenhaus) erfolgt über eine Secure ModuleCard (SMC-B), die Identifikation von vertrauenswürdigen dezentralen Komponentenerfolgt z.B. über eine SM-NK oder SM-KT und von Diensten durch Serverzertifikate undzugehörige Schlüssel.Die Telematikinfrastruktur bietet eine Infrastruktur, über die u. a. Ärzte, Zahnärzte, Psychotherapeuten,Krankenhäuser, Apotheken, Krankenkassen und Versicherte miteinanderkommunizieren. Dienstenutzer der Telematikinfrastruktur sind Leistungserbringer wie Ärzte,Apotheker etc. und die Versicherten. Diensteanbieter der Telematikinfrastruktur sindvor allem Betreiber von Systemen zur Bereitstellung von (Anwendungs-)Daten, also insbesonderegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 44 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Krankenversicherungen,• Betreiber von Fachdiensten (z. B. für die elektronische Patientenakte) und• Anbieter von Verzeichnisdiensten (z. B. Trustcenter für die ausgegebenenZertifikate).Die Architektur zeichnet sich im Wesentlichen durch eine verteilte Datenhaltung aus, wobeidie Speicherung personenbezogener medizinischer Daten auf der eGK, auf Servernoder auf anderen Datenträgern möglich ist. Diese Speichermedien können unter der Verantwortungunterschiedlicher Betreiber verwaltet werden.In der nachfolgenden Abbildung 5 sind die Architekturschichten der Telematikinfrastrukturim Überblick dargestellt, und die für die Wahrnehmung der aktiven Versichertenrechterelevanten Komponenten und Dienste sind den jeweiligen Architektur-Tiers zugeordnet.Abbildung 5: Relevante Komponenten und Dienste in den Verteilungsschichten der TelematikinfrastrukturFür die Wahrnehmung der aktiven Versichertenrechte relevant sind im Wesentlichen diedezentralen Komponenten (u. a. eKiosk, Versicherter@home) sowie die Fachdienste undSicherheitsdienste (Authentisierung, Autorisierung, Audit) auf der Anwendungsebene.• Die dezentralen Komponenten binden die Praxisverwaltungssysteme (PVS)für Ärzte, Zahnärzte und Psychotherapeuten, die Krankenhausinformationssysteme(KIS) der Krankenhäuser und die Apothekenverwaltungssysteme(AVS) der Apotheker an die Telematikinfrastruktur an. Für die Versicherten relevantsind die Anwendungen eKiosk und Versicherter@home. Sie stellendem Versicherten Funktionen zur Einsicht in seine Daten, zum „Verbergen /Sichtbarmachen“ bestimmter Daten sowie zur Verwaltung der Berechtigungenfür die Nutzung seiner Daten zur Verfügung. Die Primärsysteme werden überden Konnektor an die Telematikinfrastruktur angebunden. Der Konnektor realisiertden Zugang zur Telematik, zu den Anwendungen des Versicherten(AdV), der Rechteverwaltung und die Nutzung der Chipkarten über die Kartenterminals.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 45 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Die Fachdienste umfassen die Online-Dienste im Service-Provider-Tier. Diesestellen folgende Dienste bereit:odie für die Versicherten verpflichtenden Anwendungen• Versichertenstammdaten-, Verordnungsdatenmanagementodie für die Versicherten freiwilligen Anwendungen• Es werden die freiwilligen Anwendungen Notfalldaten, AMTS realisiert.• Es wird das Patientenfach erprobt.• Die Anwendungen Arztbrief, ePatientenakte, Patientenquittungwerden eingeführt.• Anwendungsbezogene Sicherheitsdienste und Rechteverwaltung derFachdienste der Telematikinfrastruktur: Relevant für die Wahrnehmung deraktiven Versichertenrechte sind hier fachdienstbezogene Sicherheitsdienstefür die Authentifizierung, Autorisierung und die Nicht-Abstreitbarkeit desZugriffs (Audit) sowie die Vergabe und Verwaltung der Zugriffsrechte durchden Versicherten. Dem Versicherten wird dabei über die Anwendungsverwaltungeine einheitliche logische Sicht auf seine Anwendungen und die vergebenenRechte gegeben.Zur Veranschaulichung der physischen Verteilung der obigen Komponenten sind inAbbildung 6 und Abbildung 7 die Verbindung der Primärsysteme und Fachdienste übersektorenspezifische Zugangsnetze, Netzwerk- und Anwendungs-Gateways sowie derBackenend-Netze dargestellt. Zusätzlich ist noch die Anbindung der Mehrwertdienste ü-ber Mehrwertnetze dargestellt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 46 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 6: Übersicht GesamtarchitekturDienste in der Telematikinfrastruktur sind je nach Sicherheits- und Verfügbarkeitsanforderungin unterschiedliche Sicherheitszonen eingeordnet (siehe Kap. 7.4).Die eGK eines Versicherten sowie die Heilberufsausweise sind über Kartenterminals lesbar[gemSpec_KT]. So können zum Beispiel Versicherte über eKioske die auf ihrer Kartegespeicherten Daten einsehen und ausgewählte Daten für bestimmte Leistungserbringersichtbar machen.Der Zugang zur Telematikinfrastruktur ist auf registrierte, über Konnektoren angebundeneNutzer beschränkt. Die Identifikation der Nutzer, Institutionen und Komponenten erfolgtdabei über Chipkarten (z. B. eGK, HBA im Falle natürlicher Personen und SMC-B im Fallevon Institutionen). Die Zugangssicherung zur Telematikinfrastruktur wird durch Gateways(VPN- Gateways und Anwendungs-Gateways) realisiert, so dass nur autorisierte NutzerZugang zur Kommunikationsinfrastruktur und den Fachdiensten erhalten.Ein Zugriff auf Kartenterminals erfolgt ausschließlich über einen Konnektor. Anfragen lokalerSysteme (Primärsysteme) und zentraler Systeme (z. B. VSDD) an Karten müssenan einen Konnektor gerichtet werden.Die Daten der Fachdienste werden über eine einheitliche Zugriffssicherung eingebunden.Diese realisiert die komplexen Anforderungen, die für die Wahrung der Versichertenrechtebei gleichzeitigen flexiblen Betreibermodellen umzusetzen sind. Grundsätzlich bleibt dieKontrolle der Zugriffsrechte beim Versicherten und wird mit Hilfe der eGK ausgeübt.Vertrauliche Informationen werden mittels eines Hybrid-Verfahrens behandelt. Die symmetrischeVerschlüsselung vertraulicher medizinischer Informationen erfolgt innerhalb desKonnektors. Die asymmetrische Entschlüsselung vertraulicher Informationen (z. B. dergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 47 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturverwendete symmetrische Schlüssel zur Verschlüsselung von eVerordnungen) erfolgt mitdem zur Entschlüsselung vorgesehenen Private-Key der jeweiligen Karte (eGk,HBA/SMC) und muss innerhalb der jeweiligen Karte erfolgen. Qualifizierte Signaturenwerden mit dem Signaturschlüssel des HBA erstellt.Unterschiedliche Sicherheitsmechanismen werden sowohl auf der Netzwerk- und Transportebene(z. B. VPN) als auch auf der Anwendungsebene (z. B. Objekt-Tickets) angewendetund sind unabhängig voneinander. Diese Sicherheitsmechanismen auf NetzwerkundTransportebene schützen noch zusätzlich die Übertragung der – schon für den Versichertenverschlüsselten – medizinischen Daten und wirken sich auf die Versichertenrechtenicht aus.Abbildung 7: Übersicht über Infrastrukturkomponenten und Telematiknetz4.4 Konsequenzen der Eckpunkte und Prinzipien (Roadmap)Die zuvor beschriebenen Eckpunkte und die daraus abgeleiteten Grundprinzipien beeinflussenEntscheidungen bzgl. der ablaufenden fachlichen und sicherheitstechnischen Prozesseund haben Auswirkungen auf Architekturentscheidungen. Eckpunkte und Prinzipienmüssen in allen Phasen der Systementwicklung eingehalten werden (Design, Implementierung,Wirkbetrieb etc.). Die Konsequenzen der Eckpunkte und Prinzipien betreffen jedochvordringlich die Koordination und die Abstimmung der Sicherheitsmanagementprozesseder Verantwortlichen (siehe Kapitel 8).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 48 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturSpezifikationTestvorhabenRolloutIdent. Risiko fürSektorenFestlegung Risikoklassen, Policiesund zugehöriger HaftungsregelungenFestlegungVerantwortlicherAbstimmung derübergreifendenAnforderungenAusarbeitung, Aktualisierung der Sicherheitsstrategie und -architekturÜbergr. SicherheitskonzeptSpez. SicherheitskonzepteBewertung und Optimierungvon Sec. Mgmt. ProzesseGesamtarchitekturFK, FA, VSD, VOD.Spez. eGK, Konn., ..MusterlösungNetzwerkkonzeptSpez. DNS, NTP, ….MusterlösungTeilumsetzungMKT+, Rel. 1, 2onlineErprobungZugangsnetzBackendnetzRel. 3,4,…RolloutSektorennetzeAbbildung 8: Roadmap für die Umsetzung der SicherheitsstrategieDie Komponenten und Fachdienste der Telematikinfrastruktur auf Infrastruktur und Anwendungsebenewerden schrittweise eingeführt. Insbesondere die sicherheitsrelevantenFunktionalitäten werden dabei in aufeinander aufbauenden Schritten entwickelt, erprobtund erst dann eingeführt. Durch diese gestufte Vorgehensweise werden mögliche Bedrohungenund Restrisiken begrenzt. Die nachfolgenden aufeinander aufbauenden Schritteund Erweiterungen sind vorgesehen:• Im Release 1 ist keine Online-Verbindung vorhanden und die Versichertenstammdaten,Verordnungen und Notfalldaten werden lokal von der eGK desVersicherten verwendet. Bedrohungen durch die Netzanbindung der Primärsystemesind nicht vorhanden.• Im Release 2 sind die Sicherheitsanforderungen und die Restrisiken nochstark reduziert, da die eGK und der Versicherte sowohl bei der Prüfung derAktualität der eGK als auch beim Einstellen, Lesen und Einlösen einer Arzneimittelverordnunganwesend ist. Es sind auch nur eingeschränkte Anforderungenan das Zulassungsverfahren vorhanden, z. B. noch keine vollständigeZertifizierung der Komponenten. Mit den noch nicht zertifizierten Komponentenkann natürlich noch keine qualifizierte Signatur durchgeführt werden, dieseist in Release 2 daher noch nicht verlangt. Es erfolgt in diesem Abschnitt dahernur eine fortgeschrittene elektronische Signatur der medizinischen Daten.Die wesentlich abzusichernde Funktion in Release 2 ist die Anbindung derPrimärsysteme und der lokalen Netze bei den Leistungserbringern an die Telematikinfrastruktur.Es ist sicherzustellen, dass durch diese Anbindung keinezusätzlichen Risiken entstehen. Dazu sind nachfolgende Punkte einzuhalten:• Dezentral sind die von der gematik zugelassenen Komponenten für diesenRelease 2 (u. a. Kartenterminal und Konnektor) zu verwendengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 49 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Zugangsnetze und zentrale Infrastrukturdienste wie Broker, SDS, NTP, DNSmüssen die Sicherheitsanforderungen im Anhang B erfüllen und entsprechendden Vorgaben der gematik betrieben werden.• Sicherheitsinfrastrukturen wie z.B. PKI erfüllen die Policies der gematik undsind von der gematik zugelassen.• Die Fachdienste VSDM, VODM müssen den Mindestanforderungen bezüglichDatenschutz und Datensicherheit genügen. Es darf z. B. keine Profilbildungmöglich sein. Dies gilt sowohl für den Versicherten- als auch den Leistungserbringerbezug.• Release 3: Sowohl beim Einstellen eines Eintrages in die medizinischen Datensammlungen(z. B. eVerordnung) eines Versicherten durch einen Heilberufler(schreiben) als auch beim Lesen (z. B. Dispensieren eVerordnung) istdie Anwesenheit der eGK nicht mehr erforderlich. Vorausgehen muss dasAusstellen einer Zugriffsberechtigung durch den Versicherten unter Nutzungder eGk (Schutzbedarf sehr hoch) in einer Umgebung zur Wahrnehmung derVersichertenrechte (eKiosk).Zeitversetzte Zugriffe sind möglich, d. h. der Heilberufler kann nach der Behandlung- z. B. die eVerordnung (Einweisung) - zeitversetzt füllen bzw. voreiner Behandlung lesen. Sicherheitskritische Funktionen, komplexere Verfahrenkommen gegenüber dem Release 2 hinzu und erhöhen die Sicherheitsrisikenin diesem Release.Neben der Ausarbeitung, Aktualisierung der Sicherheitsstrategie und -architektur sindspezifische Sicherheitskonzepte und Schutzprofile für einzelne Dienste und sicherheitsrelevanteKomponenten entsprechend der Releases festzulegen. Parallel zur Einführungder Komponenten und Fachdienste der Telematikinfrastruktur werden darauf abgestimmtdie Sicherheitsorganisation und Sicherheitsprozesse (siehe Kap. 8, 9) in den nachfolgendenSchritten operational:• Festlegung der Verantwortlichkeiten und der Sicherheitsverantwortlichen• Abstimmung der übergreifenden Anforderungen• Identifikation der Risiken und Rahmenbedingungen für Sektoren• Festlegung Risikoklassen, spezifischer Policies und zugehöriger Haftungsregelungen• Bewertung und Optimierung von Sicherheits-Management Prozessengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 50 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur4.5 Zusammenstellung der AusgangsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02270AS_EP_01SÜbergreifendes SikoDas übergreifende Sicherheitskonzept• enthält eine, vor allem auf gesetzlichen Vorgaben basierendeSchutzbedarfsanalyse (siehe Anhang C),Kap. 4• definiert die mindestens zu erreichenden Schutzziele (siehe Kap.5.3, 7.3 und Anhang C), die in den Designentscheidungen für dieArchitektur, die Dienste und Komponenten der Telematikinfrastrukturumgesetzt werden MÜSSEN. Die Risiken werdengemindert durch die Umsetzung der Eckpunkte der Sicherheitsstrategiesowohl durch die Begrenzung der Schadenshöhe alsauch durch den Schutz der Daten des Versicherten.• stellt Mindestanforderungen an sicherheitsrelevante Prozesse,Rollen und Verantwortlichkeiten (siehe u. a. Kap. 8, Anhang D, G)• wird zeitgerecht aktualisiert um die Angemessenheit und Wirksamkeitder Maßnahmen zu prüfen und auf neue Bedrohungenangemessen zu reagieren (siehe auch AS_EP_07).Konsequenzen:• Schutzprofile, Sicherheitskonzepte und Sicherheitsprofile derDienste und Komponenten der Telematikinfrastruktur MÜSSENdie von der gematik vorgegebenen und aktuell gültigen Mindestanforderungenund Mindeststandards einhalten und in ihrem jeweiligenGültigkeitsbereich die konkreten Sicherheitsmaßnahmendefinieren sowie die Wirksamkeit der realisierten Maßnahmen zei-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 51 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellegen.• Umsetzung der Anforderungen und Eckpunkte• Maßnahmen zur Reduktion von Schadenspotentialen wird im Entscheidungsfallegegenüber Maßnahmen zur Reduktion der Eintrittswahrscheinlichkeiteines Schadens der Vorzug gegeben. ZurVerringerung des Schadenspotentials bei einer möglichen Kompromittierungmuss eine Aufteilung der Architektur in mehrerenDimensionen mit unabhängigen Sicherheitsmaßnahmen erfolgen.• Insbesondere muss eine Aufteilung in• OSI-Schichten z. B. Trennung der Sicherheitsdienste auf Netzwerk-(siehe Kap. 7.1) und Anwendungsschicht (siehe Kap. 7.2).• verschiedene Tiers in gestuften Sicherheitszonen (siehe Kap. 7.4Zonenkonzept)berücksichtigt werden.Die Datenhaltung SOLL verteilt erfolgen.Jährliche Anpassung der übergreifenden Mindeststandards um die Angemessenheitund Wirksamkeit der Maßnahmen zu prüfen und auf neue Bedrohungenangemessen zu reagieren. Die Sicherheitsvorschriften werden dadurchkontinuierlich an die Prozessrisiken und Bedrohungen angepasst. Ein entsprechenderSicherheitsmanagement-Prozess wird definiert und für die Telematikinfrastrukturbereitgestellt (siehe auch AS_EP_07).A_02271AS_EP_02S2-Karten-PrinzipDer Zugriff auf medizinische Daten mittels der elektronischen GesundheitskarteMUSS in Verbindung mit einem elektronischen Heilberufsausweis odermittels einer SMC erfolgen, die über eine Möglichkeit zur sicheren Authentifi-Kap. 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 52 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellezierung verfügen. Der HBA MUSS über eine qualifizierte elektronische Signaturverfügen. Der Zugriff mittels SMC ist nur für die Personengruppe nach§291a Abs. 4 Satz 1 Nr. 1 Buchstabe d und e sowie Nr. 2 Buchstabe d und eSGB V möglich. Es MUSS dabei im Primärsystem nachweisbar protokolliertwerden, wer auf die Daten zugegriffen hat und von welcher Person die zugreifendePerson autorisiert wurde.Konsequenzen:• Die aktuelle Gültigkeit der Karten muss vor der Verwendung unddem Zugriff geprüft werden und Verfahren zum Sperren verlorengegangener oder kompromittierter Karten (eGK, HBA, SMC)MÜSSEN bereitgestellt werden.• Kartenmanagementprozesse müssen sicherstellen, dass Karten(eGK, HBA, SMC) nur an Berechtigte ausgegeben werden (sieheauch Anhang E).• In Fällen, in denen die eGK des Versicherten nicht anwesend ist,MUSS ein geeignetes, nachvollziehbares technisches Verfahreneingesetzt werden, bei dem die Zustimmung und Information desVersicherten nachvollziehbar und revisionsfähig sichergestellt ist(siehe auch Sicherheitskonzept, Kapitel 7.5).A_02272AS_EP_03SSchutz der Informationendurch starke KryptoalgorithmenDie unautorisierte Modifikation oder Zerstörung von Daten, die unautorisierteBekanntgabe von Informationen MÜSSEN beim Transfer von Daten, bei derenVerarbeitung und Speicherung in der Telematikinfrastruktur mit Kryptoalgorithmenmindestens der Mechanismenstärke „hoch“ erkannt bzw. verhindertwerden. Konsequenzen:o Sicherheitsdienste und Sicherheitsinfrastrukturen der Mechanismenstärke„hoch“ und „sehr hoch“ MÜSSEN von der Telematikinfrastruktur bereitgestelltwerden und MÜSSEN entsprechend der Schutzbedarfsfestlegung für dieKap. 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 53 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02273AS_EP_04SÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVersichertenindividuelleVerschlüsselungA_02274 S Datenvermeidung,Datensparsamkeit,Datentrennungfachlichen und technischen Objekte verwendet werden.Der aktuell gültige Algorithmenkatalog der gematik MUSS verwendet werden(siehe Sicherheitskonzept, Anhang F).Medizinische Daten sind in der Telematikinfrastruktur immer verschlüsselt undim Klartext nicht verfügbar und bearbeitbar.Die Verschlüsselungsschlüssel sind in der alleinigen Verfügungsgewalt desVersicherten, damit dieser und nur dieser entscheiden kann, welche Datenwelchen dritten Personen zugänglich gemacht werden.Konsequenzen:Die Anforderungen an die Verwaltung der Verschlüsselungsschlüssel werdenin Anhang F – Kryptographiekonzept festgelegtUm u. a. das Erstellen von Bewegungsprofilen oder z. B. eine Analyse desVerschreibungsverhalten, zu verhindern, DÜRFEN in der Telematikinfrastrukturnur die minimal für die Funktionalität notwendigen Daten übertragen undgespeichert werden. Die Daten sind in der Telematikinfrastruktur so zu übertragenbzw. zu speichern, dass eine Zusammenführung und Profilbildungnicht möglich ist.Soweit es möglich ist, wird eine zeitliche, räumliche, technische und organisatorischeTrennung der gespeicherten Daten angestrebt um Datensammlungenzu vermeiden. Insbesondere ist von den Möglichkeiten der Anonymisierungund Pseudonymisierung Gebrauch zu machen, soweit dies möglich ist undder Aufwand in einem angemessenen Verhältnis zu dem angestrebtenSchutzzweck steht.Kap. 4Kap. 4Konsequenzen:Die Erfordernisse des Datenschutzes sind bei allen Architekturentscheidungenexplizit zu berücksichtigen Informationen entsprechend der festgelegtenZweckbestimmung zu übertragen und zu speichern.und es sind nur die minimalnotwendigen Informationen entsprechend der festgelegten Zweckbestimmungzu übertragen und zu speicherngematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 54 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02275 AS_EP_06A_02276 AS_EP_07A_02277 AS_EP_08SSSAufteilung in SicherheitszonenProaktive Prozessezur schnellen ReaktionA_02278 S Schutzziel-Verfügbarkeit TIAufteilung in gestufte Zonen mit evaluierten KomponentenDie Telematikinfrastruktur wird in Sicherheitszonen entsprechend Kap. 7.4aufgeteilt.Konsequenzen:Vertrauenswürdige Einrichtung zur Datenverarbeitung SicherheitskritischeKomponenten und Dienste der Telematikinfrastruktur müssen die Wirksamkeitder Sicherheitsmassnahmen im Gegenstand der Evaluation durch zugelassenePrüfstellen bzw. im Rahmen der Zulassungsverfahren der gematik zeigen.Proaktive Prozesse zur schnellen ReaktionAuf erkannte Schwachstellen und Kompromittierungen MUSS eine schnelleReaktion erfolgen und eine koordinierte, proaktive Bereitstellung von ErsatzundNotfallmaßnahmen MUSS vorgesehen werden. Proaktivität bedeutetfrühzeitiges Handeln, noch ehe der volle Schaden eingetreten ist. DaherMÜSSEN proaktiv Notfall- und Ersatzmaßnahmen geplant werden um zu gewährleisten,dass diese bei einem Sicherheitsvorfall innerhalb der definiertenReaktionszeiten zum Tragen kommen und so die Auswirkungen des Sicherheitsvorfallesbegrenzen.Konsequenzen:Die Sicherheitsmanagement-Prozesse müssen entsprechend den Mindestanforderungenim Sicherheitskonzept, Kapitel 8 sowie Anhang G aufgebautwerdenSchutz der Beteiligten Die an der Telematikinfrastruktur Beteiligten (Versicherte, Leistungserbringerund deren Mitarbeiter, Kostenträger) MÜSSEN sicher sein, dass die rechtlichenVorgaben von der Telematikinfrastruktur technisch erzwungen werden.Durch einen vorbeugenden Ausschluss unzulässiger Zugriffe (siehe Kap. 7.7)sowie eine nachträgliche Erkennung unzulässiger Zugriffe (siehe Kap. 7.8)MUSS technisch ein Schutz der Beteiligten vor ungerechtfertigten Verdächtigungenbereitgestellt werden.Die Verfügbarkeit aller erfassten, übermittelten und gespeicherten Datenmuss gewährleistet sein. Das bedeutet, dass die Daten eines VersichertenKap 4.Kap 4.Kap 4.Kap 4.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 55 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02279 S Schutzziel VertraulichkeitTIimmer zeitnah zur Verfügung stehen müssen, um ordnungsgemäß be- undverarbeitet werden zu können.Personenbezogene Daten (insbesondere Sozialdaten und medizinische Daten)im Umfeld der medizinischen Versorgung müssen in der Regel als strengvertraulich behandelt werden. Dieser Vertraulichkeitsanspruch des Versichertenist in verschiedenen Gesetzen festgelegt. Des Weiteren beinhaltet derAnspruch nach vertraulicher Behandlung von Daten den Anspruch des Versicherten,seine informationelle Selbstbestimmung wahrnehmen zu können,indem er die Daten nur Berechtigten zugänglich macht. Eine Verletzung dieserSicherheitsanforderung kann für den Versicherten zu nicht unerheblichensozialen oder materiellen Schäden führen. Andererseits muss der Versichertedarüber informiert werden, dass er dieses Recht auf informationelle Selbstbestimmungdem behandelnden Arzt bzw. dem Leistungserbringer und sichselbst gegenüber in vertrauenswürdiger Weise nutzen sollte, damit Schadensfällevermieden werden. Aus den Eckpunkten AS_EP_03 und AS_EP_04 ergibtsich, dass die personenbezogenen Daten bei der Übertragung und Speicherungin der Telematikinfrastruktur versichertenindividuell verschlüsselt seinmüssen. Das Schlüsselmanagement muss nach dem aktuellen Stand derTechnik und Wissenschaft sicher sein (siehe Anhang F).A_02280 S Schutzziel Integrität TI Die Integrität der erhobenen, verarbeiteten, transportierten und gespeichertenDaten muss gewährleistet sein. Die Daten dürfen nicht unbemerkt manipuliertwerden. Ihre Korrektheit und Echtheit ist für den Behandlungserfolg wichtig.A_02281 S Schutzziel AuthentizitätTIDie Authentizität der im medizinischen Umfeld erhobenen, gespeicherten,verarbeiteten und transportierten Daten muss gewährleistet sein, d.h. der Autorbzw. der Verantwortliche von patientenbezogenen Daten sowie der Auslösereines Verarbeitungsganges muss jederzeit eindeutig feststellbar sein (sieheAS_EP_08). Dabei ist es unerheblich, ob es sich dabei um eine natürlichePerson, eine Organisation oder eine technische Komponente handelt. DesWeiteren muss die Herkunft (eine natürliche oder juristische Person) der imRahmen der Personalisierung auf eine Karte aufgebrachten Daten aus dergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 56 von 802Version: 2.2.0 © gematik Stand: 10.03.2008Kap 4.Kap 4.Kap 4.

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleSicht der personalisierenden Stelle eindeutig bestimmbar und prüfbar sein.A_02282 S Schutzziel-NichtabstreitbarkeitA_02283 S Schutzziel-Autorisierung undZugriffskontrolle TIDie Nichtabstreitbarkeit des Sendens und Empfangens von patientenbezogenenInformationen/ Dokumenten muss gewährleistet sein (siehe AS_EP_08).Diese Nichtabstreitbarkeit muss sich sowohl auf den Vorgang der Übertragungwie auch auf das Objekt der Übertragung beziehen. Die Nichtabstreitbarkeitist eine Voraussetzung der RevisionsfähigkeitMedizinische Datenverarbeitungs-systeme müssen es ermöglichen, dass derKreis der Zugriffsberechtigten auf Versichertendaten durch abgestufte Nutzungsrechteexakt bestimmbar und abgrenzbar ist. Durch geeignete Verfahrenist sicherzustellen, dass ein Zugriff auf die Daten des Versicherten nur mitseinem Einverständnis erfolgen kann. Sollte der Versicherte nicht in der Lagesein, diese Rechte wahrnehmen zu können, so ist durch geeignete organisatorischewie auch technische Verfahren sicherzustellen, dass entsprechendden gesetzlichen Vorgaben seine medizinische Versorgung nicht beeinträchtigtwird. Die Erteilung von Zugriffsberechtigungen darf bei den medizinischenPflichtanwendungen nicht zu Diskriminierungen auf Grund der angewandtentechnischen Verfahren führen.Der Versicherte ist der Besitzer seiner Informationsobjekte. Er ist Zugriffsberechtigterfür seine Informationsobjekte welche auf Verlangen der Versichertengelöscht werden müssen (§291a Abs. 4 und Abs. 6). Neben dem Versichertendürfen auf Informationsobjekte des Versicherten ausschließlich die im§291a Abs. 4 genannten Personen (im Folgenden als Leistungserbringer bezeichnet)zugreifen, wenn sie vom Versicherten entsprechend autorisiert wurden(siehe AS_EP_02, AS_EP_04). Nur der Versicherte kann diese Autorisierungdurchführen. Der Versicherte kann erteilte Zugriffsberechtigungen jederzeitzurücknehmen.Kap 4.Kap 4.Das Erzeugen und jede Änderung der Zugriffsinformation eines Informations-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 57 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleobjektes eines Versicherten kann ebenfalls nur auf Basis einer Einwilligungdes Versicherten (Besitzer des Informationsobjektes) erfolgen.Durch technische Vorkehrungen ist zu gewährleisten, dass der Zugriff aufDaten des Versicherten nur durch Autorisierung des Versicherten möglich ist(§291a Abs. 5).Medizinische Datenverarbeitungssysteme müssen es ermöglichen, für jedespatientenbezogene Dokument den Nutzerkreis sowie abgestufte Nutzungsrechtefestzulegen und Nutzungsausschlüsse zu definieren.A_02284 S Schutzziel-Revisionsfähigkeit TIVom Versicherten darf nicht verlangt werden, den Zugriff auf seine Informationsobjekteanderen Personen als den in §291a Abs. 4 genannten Leistungserbringernoder zu anderen Zwecken als der Versorgung des Versicherten zugestatten. Es darf auch nicht vereinbart werden, Derartiges zu gestatten.Die Revisionsfähigkeit der erhobenen, gespeicherten, übermittelten oder verarbeitetenDaten muss gewährleistet sein, damit die Verarbeitungsprozesselückenlos nachvollzogen werden können. Für den Arzt, Apotheke bzw. dasKrankenhaus besteht nach der Berufsordnung die Pflicht zur Dokumentationder Behandlung. Diagnosen und Therapien müssen zwecks Ausschluss vonHaftungen lückenlos nachvollziehbar werden.Die existierenden Systeme der Leistungserbringer und Kostenträger deckendiese Anforderungen der Revisionsfähigkeit ab.A_02285 S Roadmap-Release-1 Es DARF KEINE Online-Verbindung vorhanden und die Versichertenstammdaten,Verordnungen und Notfalldaten werden lokal von der eGK des Versichertenverwendet. Bedrohungen durch die Netzanbindung der Primärsystemesind nicht vorhanden.A_02286 S Roadmap-Release-2 Die Sicherheitsanforderungen und die Restrisiken sind noch stark reduziert,da die eGK und der Versicherte sowohl bei der Prüfung der Aktualität der eGKals auch beim Einstellen, Lesen und Einlösen einer ArzneimittelverordnungKap 4.Kap 4.Kap 4.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 58 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleanwesend ist.Es sind auch nur eingeschränkte Anforderungen an das Zulassungsverfahrenvorhanden, z. B. noch keine vollständige Zertifizierung der Komponenten. Mitden noch nicht zertifizierten Komponenten kann natürlich noch keine qualifizierteSignatur durchgeführt werden, diese ist in Release 2 aber noch nichtverlangt.Die wesentlich abzusichernde Funktion in Release 2 ist die Anbindung derPrimärsysteme und der lokalen Netze bei den Leistungserbringern an die Telematikinfrastruktur.Es ist sicherzustellen, dass durch diese Anbindung keine zusätzlichen Risikenentstehen. Dazu sind nachfolgende Punkte einzuhalten:• Dezentral sind die von der gematik zugelassenen Komponenten für diesenRelease 2 (u. a. Kartenterminal und Konnektor) zu verwenden• Zugangsnetze und zentrale Infrastrukturdienste wie Broker, SDS, NTP, DNSmüssen die Sicherheitsanforderungen im Anhang B erfüllen und entsprechendden Vorgaben der gematik betrieben werden.• Sicherheitsinfrastrukturen wie z. B. PKI erfüllen die Policies der gematik undsind von der gematik zugelassen.• Die Fachdienste VSDM, VODM müssen den Mindestanforderungen bezüglichDatenschutz und Datensicherheit genügen.• Es darf z. B. keine Profilbildung möglich seinA_02287 S Roadmap-Release-3 Sowohl beim Einstellen eines Eintrages in die medizinischen Datensammlungen(z. B. eVerordnung) eines Versicherten durch einen Heilberufler (schreiben)als auch beim Lesen (z. B. Dispensieren eVerordnung) ist die Anwesenheitder eGK nicht mehr erforderlich. Vorausgehen muss das Ausstellen einerZugriffsberechtigung durch den Versicherten unter Nutzung der eGk (Schutzbedarfsehr hoch).Zeitversetzte Zugriffe sind möglich, d. h. der Heilberufler kann nach der Behandlung- z. B. die eVerordnung (Einweisung) - zeitversetzt füllen bzw. voreiner Behandlung lesen. Sicherheitskritische Funktionen, komplexere Verfahrenkommen gegenüber dem Release 2 hinzu und erhöhen die Sicherheitsri-Kap 4.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 59 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellesiken in diesem Release.Neben der Ausarbeitung, Aktualisierung der Sicherheitsstrategie und -architektur sind spezifische Sicherheitskonzepte und Schutzprofile für einzelneDienste und sicherheits-relevante Komponenten entsprechend der Releasesfestzulegen. Parallel zur Einführung der Komponenten und Fachdiensteder Telematikinfrastruktur werden darauf abgestimmt die Sicherheitsorganisationund Sicherheitsprozesse (siehe Kap. 8, 9) in den nachfolgendenSchritten operational:• Festlegung der Verantwortlichkeiten und der Sicherheitsverantwortlichen• Abstimmung der übergreifenden Anforderungen• Identifikation der Risiken und Rahmenbedingungen für Sektoren• Festlegung Risikoklassen, spezifischer Policies und zugehöriger Haftungsregelungen• Bewertung und Optimierung von Sicherheits-Management ProzessenSowohl beim Einstellen eines Eintrages in die medizinischen Datensammlungen(z. B. eVerordnung) eines Versicherten durch einen Heilberufler (schreiben)als auch beim Lesen (z. B. Dispensieren eVerordnung) ist die Anwesenheitder eGK nicht mehr erforderlich. Vorausgehen muss das Ausstellen einerZugriffsberechtigung durch den Versicherten unter Nutzung der eGk (Schutzbedarfsehr hoch).Zeitversetzte Zugriffe sind möglich, d. h. der Heilberufler kann nach der Behandlung- z. B. die eVerordnung (Einweisung) - zeitversetzt füllen bzw. voreiner Behandlung lesen. Sicherheitskritische Funktionen, komplexere Verfahrenkommen gegenüber dem Release 2 hinzu und erhöhen die Sicherheitsrisikenin diesem Release.Neben der Ausarbeitung, Aktualisierung der Sicherheitsstrategie und -architektur sind spezifische Sicherheitskonzepte und Schutzprofile für einzelneDienste und sicherheits-relevante Komponenten entsprechend der Releasesfestzulegen. Parallel zur Einführung der Komponenten und Fachdiensteder Telematikinfrastruktur werden darauf abgestimmt die Sicherheitsorganisationund Sicherheitsprozesse (siehe Kap. 8, 9) in den nachfolgendengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 60 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelle•Schritten operational:• Festlegung der Verantwortlichkeiten und der Sicherheitsverantwortlichen• Abstimmung der übergreifenden Anforderungen• Identifikation der Risiken und Rahmenbedingungen für Sektoren• Festlegung Risikoklassen, spezifischer Policies und zugehöriger Haftungsregelungen• Bewertung und Optimierung von Sicherheits-Management Prozessengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 61 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur5 Sicherheitsaspekte der Fachkonzepte und FacharchitekturenIn diesem Kapitel werden die Sicherheitsaspekte der in Fachkonzepten und Facharchitekturenbeschriebenen Fachdienste behandelt. Es werden die gesetzlich geforderten undin der Telematikinfrastruktur umzusetzenden Anwendungen bzgl. ihrer Sicherheits- undZugriffsbedingungen klassifiziert, der an der Telematikinfrastruktur beteiligte Personenkreisdefiniert und der Schutzbedarf 6 für die in den Anwendungen erhobenen und verarbeitetenInformationen anhand fachlicher Datenklassen festgelegt.Im Einzelnen werden die folgenden Fragen behandelt:• Welche sind die sicherheitsrelevanten Anwendungen bzw. Kategorien vonAnwendungsfällen?• Welcher Personenkreis wird zur Teilnahme an diesen Anwendungsfällen zugelassen?• Welche sind die zu schützenden Informationen in diesen Anwendungsfällen?Die Sicherheitsaspekte der Fachkonzepte sind die Basis für die in folgenden Kapiteln vorgestelltentechnischen Sicherheitsanforderungen, die Sicherheitsarchitektur und die sicherheitstechnischenProzesse.5.1 Sicherheits- und Zugriffsbedingungen der TI-AnwendungenDer §291a Abs. 2 und 3 SGB V definiert die in der Telematikinfrastruktur umzusetzendenAnwendungen. Diese Anwendungen und ihre dazugehörigen Anwendungsfälle lassensich in die in Tabelle 2 beschriebenen Kategorien einteilen.Tabelle 2: Kategorien von AnwendungenKategorieBeschreibungNutzung von PflichtanwendungenVerwaltung freiwilligerAnwendungenNutzung freiwilliger AnwendungenNach §291a beinhaltet diese Kategorie die zwei AnwendungenοοVersichertenstammdatenmanagement zur Nutzungder Versichertenstammdaten (siehe [gemFK_VSDM])undVerordnungsdatenmanagement zur Nutzung elektronischerVerordnungen (siehe [gemFK_VODM]).Diese Kategorie enthält alle Anwendungsfälle zur Verwaltungfreiwilliger Anwendungen. Dazu gehören insbesondere dieAnwendungsfälle für das Einrichten und Beenden von freiwilligenAnwendungen (siehe [gemFK_VFA]).§291a Abs. 3 SGB V definiert Anwendungen, die auf Wunschdes Versicherten freiwillig genutzt werden können. Darunterfallen u. a. das6 Der in diesem Kapitel beschriebene Schutzbedarf fachlicher Datenklassen ist ein Auszug ausAnhang C. In Anhang C ist der Schutzbedarf der Informationsobjekte der gesamten TI festgelegt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 62 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKategorieAnwendungen des VersichertenBeschreibungοNotfalldatenmanagement zur Verwaltung von Datenfür den Notfall (siehe [gemFK_NFDM]) undο Daten zur Arzneimitteltherapiesicherheitsprüfung.Die vollständige Liste der freiwilligen Anwendungen ist in§291a Abs. 3 Satz 1 definiert.Die Kategorie enthält alle Anwendungsfälle, die die Nutzungfreiwilliger Anwendungen betreffen.Diese Kategorie enthält alle Anwendungsfälle, die der Versicherteautark nutzen kann, d. h. in denen er eigenständig diejenigenAuskunfts- und Zugriffsrechte ausübt, für die keineAnwesenheit eines Leistungserbringers erforderlich ist, z. B.die Vergabe von differenzierten Zugriffsberechtigungen (siehe[gemFK_ADV]).Die Kategorien unterscheiden sich bezüglich ihrer Sicherheits- und Zugriffsbedingungen(siehe Tabelle 3 7 ). Die Übergabe der eGK ist eine notwendige Bedingung, um auf die Datendes Versicherten zuzugreifen. Ausnahme sind jene Fälle, in denen der Versicherteunter Nutzung seiner eGK eine Zugriffsberechtigung erstellt hat, die die Anwesenheit dereGK nicht erforderlich macht. Damit die medizinischen Daten eines Versicherten ausschließlichden in §291a Abs. 4 genannten Personenkreisen zugänglich ist, muss ein Heilberufsausweis(HBA) oder eine die Institution eines Leistungserbringers repräsentierendeSMC als zweite Sicherheitsbedingung vorliegen. Für die Nutzung der Pflichtanwendungensind diese beiden Kriterien ausreichend. Für die Nutzung freiwilliger Anwendungen isteine zusätzliche Authentisierung durch den Versicherten notwendig (Ausnahme: das Lesenvon Notfalldaten im Notfall). Die Anwendungsfälle zur Verwaltung freiwilliger Anwendungenführt der Leistungserbringer mit seinem Heilberufsausweis (HBA) für den Versichertenaus (freiwillige Anwendung einrichten bzw. beenden) bzw. werden vom Versichertenin einer eKiosk-Umgebung (eKiosk-SMC) selbstständig durchgeführt (Liste aktiverfreiwilliger Anwendungen anzeigen). Der Leistungserbringer muss hierbei vom Versichertendurch die Übergabe der eGK und durch PIN-Eingabe autorisiert werden. Die Anwendungsfällefür die Anwendungen des Versicherten dürfen nur durch den Versicherten ineiner eKiosk-Umgebung (eKiosk-SMC) ausgelöst werden. Ein Teil der Anwendungsfälleder Anwendungen des Versicherten können vom Versicherten auch in seiner Heimumgebungerfolgen.Tabelle 3 spiegelt das in 4.1.2 beschriebene Zwei-Karten-Prinzip wider, welches für einenZugriff auf die medizinischen Daten eines Versicherten die eGK des Versicherten und denHBA bzw. eine entsprechende SMC fordert.Tabelle 3: Sicherheitsbedingungen der Kategorien7 Die Zugriffsbedingungen für Kartendaten und Anwendungen in einer Kioskumgebung sind in[gemSpec_eGK_P2] näher beschrieben. Die Tabelle zeigt in der letzen Spalte, dass eine Kombinationaus HBA oder SMC notwendig ist. Die Details (wann HBA, wann SMC, wann eine Kombinationetc.) ist in den Facharchitekturen und den Spezifikationen zu den dezentralen Komponenten festgelegt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 63 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnwendungBesitz(eGK)Wissen(PIN.CH eGK)Besitz + Wissen(HBA/SMC + PIN.CHeGK)Nutzung Pflichtanwendung-Nutzung freiwillige AnwendungVerwaltung freiwilliger Anwendungenfreiw. Anw. einrichten/beendenListe freiw. Anw. anzeigen[ ] eKiosk-SMC 8Anwendungen des Versicherten[ ] eKiosk-SMCoder PIN.homeDie (technischen) Mittel zur Nutzung der Anwendungen des Versicherten werden demVersicherten in einer geschützten Einsatzumgebung praktikabel und alltagstauglich zurVerfügung gestellt (siehe hierzu auch Kapitel 7.5.3).5.2 Fachliche AkteureDer §291a Abs. 4 SGB V definiert den Personenkreis, der (nach entsprechender Autorisierung)ausschließlich auf die Daten des Versicherten zugreifen darf. Nach §291a Abs. 8darf vom Versicherten nicht verlangt werden, den Zugriff anderen als dem im Abs. 4 genanntenPersonenkreis zu ermöglichen oder den Zugriff zu anderen Zwecken als dem derVersorgung des Versicherten zu gestatten. Somit sind die außerhalb des durch §291aAbs. 4 SGB V definierten Personenkreise keine Akteure der Telematikinfrastruktur. Einegenaue Beschreibung der im §291a Abs. 4 SGB V definierten fachlichen Akteure ist denjeweiligen Fachkonzepten zu entnehmen (u.a. [gemFK VSDM], [gemFK VODM], [gemFKNFDM]).5.3 Schutzbedarf für Datenklassen fachlicher ObjekteIn den oben erwähnten Anwendungsfällen erfolgt eine Erfassung und Verarbeitung von(sensitiven) Informationen von Versicherten und Leistungserbringern. Der Schutzbedarfder Informationsobjekte, welche diese Informationen enthalten, ist zu definieren, um ausreichendeund angemessene Maßnahmen zu deren Schutz zu realisieren.Der Schutzbedarf für ein Informationsobjekt ergibt sich aus den Folgen (Schäden) dieeintreten könnten, wenn eines oder mehrere Schutzziele nicht erreicht oder verletzt werdenwürden. Die Übersicht über die Schadenskategorien, die der Schutzbedarfsanalysezu Grunde liegen, ist im Anhang C1.3Fachliche Informationsobjekte können so genannten Datenklassen zugeordnet werden(siehe Anhang C), wenn für sie keine eigene Schutzbedarfsfeststellung vorliegt. Für dieseInformationsobjekte gilt dann der Schutzbedarf der Datenklasse. Liegt für ein Informati-8 Die Vorgaben zur Bereitstellung eines eKiosk stammen vom BMG.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 64 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturonsobjekt eine eigene Schutzbedarfsfestellung vor, so gilt diese uneingeschränkt und dieZuordnung zu einer Datenklasse ist nicht nötig. Die Schutzbedarfsfeststellung eines einzelnenInformationsobjekts berücksichtigt die Eigenheiten und Rahmenbedingungen einesInformationsobjekts viel genauer als die mehr pauschale Schutzbedarfsfeststellung einerDatenklasse.Die Schutzbedarfsfeststellung der Datenklassen ist also dazu da, Informationsobjekte fürdie (noch) keine Schutzbedarfsfeststellung vorliegt, schnell zu klassifizieren. Wird danneine Schutzbedarfsfeststellung zu diesem Informationsobjekt erstellt, so wird die Zuordnungzur Datenklasse obsolet.Tabelle 4 beschreibt die fachlichen Datenklassen und definiert deren Schutzbedarf bezüglichder Sicherheitsziele Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität und Nichtabstreitbarkeit.9 Die Klassifizierung des Schutzbedarfs erfolgt nach Niedrig, Mittel, Hochund Sehr Hoch (eine Definition der Schutzbedarfsklassen ist in Anhang C nachzulesen).Eine ausführliche Schutzbedarfsanalyse ist in Anhang C gegeben.Neben den personenbezogenen medizinischen Daten gehören die PINs und PUKs alsvertrauliche persönliche Authentikationsmittel mit sehr hohem Schutzbedarf zu den sicherheitskritischstenfachlichen Daten. PINs und PUKs schützen die Informationen, diezum Zugriff auf die medizinischen Daten von Versicherten notwendig sind (z. B. kryptographischeSchlüssel). Dieser sehr hohe Schutzbedarf für PINs und PUKs erfordertzwingend sicherheitstechnische Maßnahmen, die PINs und PUKs in der Telematikinfrastrukturin jedem Verarbeitungsschritt und zu jedem Zeitpunkt mit einem einheitlichenMindestniveau schützen. Die für PINs und PUKs geforderten Sicherheitsmaßnahmenund Sicherheitsanforderungen sind ausführlich im Anhang E – PIN/PUK-Policy festgelegt.9 Die fehlenden Nummern der Datenklassen sind auf die in diesem Kapitel nicht betrachteten technischenDatenklassen zu erklären. Diese werden in Kapitel 7.3 und in der Schutzbedarfsanalyse inAnhang C beschrieben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 65 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Tabelle 4: Schutzbedarf übergreifender fachlicher Datenklassen in der TelematikinfrastrukturID Bezeichnung BeschreibungSchutzbedarfDk01PersonenbezogeneDatenPersonenbezogene Daten sind Einzelangaben überpersönliche oder sachliche Verhältnisse einer bestimmtenoder bestimmbaren natürlichen Person (Betroffener)(BDSG §3, Abs. 1).Dk02 Sozialdaten Sozialdaten sind Einzelangaben über persönliche odersachliche Verhältnisse einer bestimmten oder bestimmbarennatürlichen Person (Betroffener), die von einer in§ 35 des Ersten Buches SGB genannten Stelle im Hinblickauf ihre Aufgaben nach diesem Gesetzbuch erhoben,verarbeitet oder genutzt werden.Dk03Dk04Personenbezogenemedizinische DatenAnonymisierte medizinischeDatenNicht anonymisierte medizinische Daten. Dies sind personenbezogeneDaten besonderer Art (gem. §3(9)BDSG)Medizinische Daten die in anonymisierter Form vorliegen.Der Anonymisierungs-Mechanismus muss Mechanismenstärke„hoch“ haben.Anonymisieren ist das Verändern personen-bezogenerDaten derart, dass die Einzelangaben über persönlicheoder sachliche Verhältnisse nicht mehr oder nur miteinem unverhältnismäßig großen Aufwand an Zeit, Kostenund Arbeitskraft einer bestimmten oder bestimmbarennatürlichen Person zugeordnet werden können(BDSG §3, Abs. 6).Statische Daten über medizinische Vorgänge, die keinerleiRückschluss auf die Einzel-vorgänge ermöglichen,sind auch anonymisierte medizinische Daten.IntegritätÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVertraulichkeitVerfügbarkeitAuthentizitätNichtabstreitbarkeitmittel hoch niedrig hoch hochmittel hoch niedrig hoch hochsehr hoch sehr hoch hoch sehr hoch sehr hochmittel mittel mittel mittel mittelgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 66 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

ID Bezeichnung BeschreibungDk05Dk07Pseudonymisiertemedizinische DateneinzelnMetadatenaggregiertMedizinische Daten die in pseudonymisierter Form vorliegen.Pseudonymisieren ist das Ersetzen des Namensund anderer Identifikationsmerkmale durch ein Kennzeichenzu dem Zweck, die Bestimmung des Betroffenenauszuschließen oder wesentlich zu erschweren.(BDSG §3, Abs. 6a)Dienen zur Beschreibung der medizinischen Daten:Beispielsweise ist dies das Erzeugungsdatum, Objektklasseoder Format- bzw. Versionsinformationen.SchutzbedarfIntegritätÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVertraulichkeitVerfügbarkeitAuthentizitätNichtabstreitbarkeitmittel mittel mittel mittel mittelmittel mittel mittel mittel mittelhoch mittel mittel mittel mittelDk11dDk12Vertrauliche persönlicheAuthentikationsmittelSignierte und verschlüsseltemedizinischeDatenPINs/PUKs 10 sehr hoch sehr hoch hoch sehr hoch sehr hochMedizinische Daten, die durch ein zugelassenes Verschlüsselungsverfahrenverschlüsselt und durch einequalifizierte elektronische Signatur signiert sind.Eine Wiederherstellung des Klartextes ist nur mit Zustimmungjener Person möglich, dessen informationellenSelbstbestimmungsrecht der Klartext unterliegt.mittel mittel hoch mittel mittel10 Diese Datenklasse enthält nur Daten, die in der Hoheit der gematik liegen. Insbesondere werden hier z. B. keine besonderen Anforderungen an PINs fürqualifizierte Signaturen gestellt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 67 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur5.4 Zusammenstellung der AusgangsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_02288SNutzung Pflichtanwendung:Besitz (eGK) und Wissen+Besitz (HBS/SMC + PIN.CH eGK)Nutzung freiwillige Anwendung:Wissen+Besitz(eGK.PIN.CH) +Besitz (HBS/SMC + PIN.CH eGK)Verwaltung freiwilliger Anwendungen:Wissen+Besitz(eGK.PIN.CH) +Besitz (HBS/SMC + PIN.CH eGK) / eKiosk-SMCKap5.Sicherheits- undZugriffsbedingungenAnwendungen des Versicherten:Wissen+Besitz(eGK.PIN.CH) +Besitz (HBS/SMC + PIN.CH eGK) / eKiosk-SMC oder PIN.home.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 68 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur6 BerechtigungsmodellIn diesem Abschnitt wird das Berechtigungsmodell dargestellt, mit dem die fachlichen Berechtigungenin Berechtigungsrichtlinien umgesetzt werden müssen. Es dient als Grundlagefür die Beschreibung der Berechtigungen in den einzelnen Fachdiensten. Das Berechtigungsmodellbasiert auf dem Schutzprofil Benutzerbestimmbare Informationsflusskontrolle(MU) BSI-PP0008, das die Zulässigkeit von Informationsflüssen in einem IT-System gemäß definierbarer Informationsflussregeln kontrolliert. Dieses Schutzprofil wirdentsprechend der Zugriffsschutzbesonderheiten der Telematikinfrastruktur erweitert. Hierbeifindet insbesondere das ISO10181-3-Framework für Zugriffskontrolle [ISO10181-3]Berücksichtigung.Die normativen Berechtigungsrichtlinien für die Pflichtanwendungen Versichertenstammdatenmanagement(VSDM) und Verordnungsdatenmanagement (VODM) sowie die freiwilligenAnwendungen Notfalldatenmanagement (NFDM) und Arzneimitteltherapie-sicherheitsprüfung(AMTS) sind in Anhang D beschrieben.6.1 Prinzipien des BerechtigungsmodellsDas Berechtigungsmodell muss den im §291a SGB V gestellten Anforderungen an dieAutorisierung von Zugriffen auf Daten des Versicherten genügen. Im Folgenden werdendie auf die Autorisierung des Zugriffes bezogenen Anforderungen des § 291a SGB V kurzzusammengefasst, um daraus Festlegungen für das Berechtigungsmodell abzuleiten. Fürdie genaue Formulierung der Gesetzestexte wird auf die relevanten Absätze des §291aSGB V verwiesen.Die folgende Tabelle zeigt aus dem §291a SGB V abgeleitete Prinzipien. Die erste Spalteenthält die Nummer der in Spalte zwei beschriebenen Festlegung. Die relevante gesetzlicheRahmenbedingung, die die Festlegung motiviert, ist in Spalte drei beschrieben. Spaltevier verweist auf den Abschnitt des Berechtigungsmodells, in welchem die Festlegungumgesetzt wird.BerechtigungsmodellAS-BER-F0Die Verarbeitung von Informationenin der TI darf (nebendem Versichertenselbst) nur autorisiertenLeistungserbringern möglichsein und der Versichertemuss die Informationsflüsseseiner Anwendungen kontrollierenkönnen. Informationsflüssemüssen entsprechendsicherheitstechnischerRahmenbedin-Nach §291 a Abs. 5 ist durchtechnische Vorkehrungen zugewährleisten, dass einZugriff nur durch Autorisierungder Versicherten möglichist. Der Zugriff auf Datendes Versicherten darf nur inVerbindung mit einem elektronischenHeilberufsausweiserfolgen, der jeweils übereine Möglichkeit zur sicherenAuthentifizierung und überTabelle 5 - Prinzipien BerechtigungsmodellNr. Festlegung gesetzliche RahmenbedingungKap. 6.5.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 69 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturgungen geeignet gesteuertwerden können (z. B. Informationsflussnur nach geeigneterAuthentifizierungoder nach dem Signierenvon Daten).eine qualifizierte elektronischeSignatur verfügt. 11Nr. Festlegung gesetzliche RahmenbedingungBerechtigungsmodellAS-BER-F1Die Informationsobjekte vonVersicherten lassen sich inverschiedene Klassen einteilen,z. B. Versichertenstammdaten,medizinischeDaten für Notfallversorgung.§ 291a Abs. 2 und Abs. 3definieren die von der Telematikinfrastrukturzu unterstützendenAnwendungenund die in diesen und auf dereGK auftretenden Daten desVersicherten.Kap. 6.5.6AS-BER-F2Zugriffsregeln definieren dieAutorisierung der Zugriffeauf die Informationsobjektevon Versicherten. Sie regelnauch die Art des Zugriffes.Zusätzliche Bedingungen anZugriffsregeln können diemöglichen autorisiertenZugriffe kontextsensitiv weitereinschränken.Nach §291 a Abs. 5 ist dasErheben, Verarbeiten undNutzen von Daten nur mitdem Einverständnis des Versichertenund nach seinerAutorisierung möglich.Kap. 6.5.2AS-BER-F3Es wird ein rollenbasiertesZugriffsschutzmodell verwendet.Die Ausprägung derRollen ergibt sich aus demGesetz, z. B. Rollen Arzt,Zahnarzt, Versicherter.Jeder Akteur in der Telematikinfrastrukturist zu jedemZeitpunkt genau einer Rollezugeordnet. Die Rolle ist andie vorhandenen Karten(eGK, HBA/SMC) gebunden.Jeder Karte ist dabei genauein Akteur mit einer Rollezugeordnet. Wenn ein Arztsich selbst ein Rezept ausstellt,dann sind für die Telematikzwei unterschiedlicheAkteure mit unterschiedlichenRollen und entsprechendunterschiedlichenKarten vorhanden.§ 291a Abs. 4 regelt denPersonenkreis, der ausschließlichauf Daten desVersicherten zugreifen darf.Kap. 6.5.111 Eine Ausnahme hierzu bildet das Patientenfach, auf das der Versicherte auch ohne elektronischenHeilberufsausweis zugreifen kann. Beim Zugriff auf das Patientenfach ist jedoch der Einsatzeiner eigenen Signaturkarte mit qualifizierter Signatur vorgeschrieben (§291a Abs. 5 SGB V).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 70 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur6.2 Einordnung des BerechtigungsmodellsIn diesem Abschnitt wird das Berechtigungsmodell in den Kontext der fachlichen Festlegungvon Berechtigungen und technischen Zugriffsbedingungen eingeordnet.Das Berechtigungsmodell besitzt die folgenden Bestandteile:Definition einer Beschreibungssprache, mit der Berechtigungen und notwendige sicherheitstechnischeZugriffsbedingungen einheitlich formuliert werden. Die Beschreibungfachlicher Berechtigungen mittels der Beschreibungssprache ergibt eine Berechtigungsrichtlinie.Die Mächtigkeit der Beschreibungssprache sollte den im §291a SGB V erwähntenAnwendungen genügen und muss flexibel erweiterbar sein. Dies erfordert einevon fachlichen Besonderheiten einzelner Fachanwendungen unabhängige Beschreibungssprache,die bzgl. verschiedenster Anwendungen anwendbar ist.Definition der Entscheidungsfunktion, d. h. wie eine Berechtigungsrichtlinie zum Zweckeder Entscheidung auf Zulassung oder Ablehnung eines gewünschten Zugriffes realisiertwird.Der Nutzen eines anwendungsübergreifenden Berechtigungsmodells mit einer einheitlichenBeschreibungssprache ist• eine transparente und nachvollziehbare Darstellung der fachlichen Zugriffsberechtigungenunabhängig von den technischen Realisierungen,• eine bessere Verständlichkeit für Fachanwender (auch unterschiedlicherFachanwendungen),• eine einfachere und konsistentere Implementierung, die auch schneller an(gesetzliche und fachliche) Änderungen anpassbar ist,• ein konsistenteres und höheres Sicherheitsniveau, durch eine verbessertePrüfbarkeit.6.2.1 Berechtigungsmodell als AbstraktionsschichtEin Berechtigungskonzept beschreibt Berechtigungen von Akteuren für fachlicheZugriffsarten auf Informationsobjekte. Entsprechend der Anwendung variieren sowohl dieMenge der auftretenden Akteure, die möglichen fachlichen Zugriffsarten als auch die Berechtigungen.Für jede fachliche Anwendung ergibt sich ein spezifisches Berechtigungskonzept(siehe auch Abbildung 9).Das Berechtigungsmodell abstrahiert von fachlichen Anwendungen und bildet ein einheitlichesModell zur Beschreibung von Berechtigungen. Das Berechtigungsmodell führtein flexibles Rollenkonzept ein, um auf spezielle fachliche Akteure in den Anwendungenreagieren zu können und definiert eine feste Menge von Zugriffsoperationen, mit denendie fachlichen Berechtigungen formuliert werden müssen. Die Menge der Zugriffsoperationenkann zukünftig bei Bedarf erweitert werden. Es muss bei einer Erweiterung jedochsichergestellt sein, dass durch die Aufnahme neuer Operationen keine Sicherheitslückenentstehen können und die Rechteverwaltung für den Versicherten verwaltbar bleibt. DasBerechtigungsmodell schafft eine Struktur, in der die im §291a SGB V genannten Anforderungenumgesetzt werden können (siehe auch die Festlegungen AS-BER-F0 bis AS-BER-F3).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 71 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie unterschiedlichen fachlichen Berechtigungen der Berechtigungskonzepte spiegelnsich in spezifischen Berechtigungsrichtlinien (Access Control Policy) wider. Eine Berechtigungsrichtliniespezifiziert die fachlichen Berechtigungen in der durch das Berechtigungsmodellvorgegebenen einheitlichen Sprache mit fest definierten Sprachelementen.Berechtigungsrichtlinien müssen von den technischen Komponenten mittels der in dentechnischen Komponenten vorhandenen Sicherheitsmechanismen umgesetzt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 72 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 9: Überblick über die Berechtigungsbehandlunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 73 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur6.3 TI-adaptierte benutzerbestimmbare InformationsflusskontrolleNach Schutzprofil BSI-PP0008 [BSI-PP-0008] wird unter einem Informationsfluss die Ein-/Ausgabe einer IT-Komponente von/zu einem beliebigen Datenort verstanden. Ein Informationsflussentsteht als Folge einer durch ein Subjekt ausgelösten Operation. Informationsflussregelnschränken die Verarbeitung von Informationen auf bestimmte Subjekteein. Damit kann die Zweckbindung der Informationsverarbeitung in Übereinstimmung mitDatenschutzbestimmungen unterstützt werden.Auf Basis von in Berechtigungsrichtlinien (Access Control Policies) spezifizierten Informationsflussregelnwird in der Zugriffsschutz-Entscheidungsfunktion entschieden, ob ein angeforderterInformationsfluss zu erlauben bzw. zu verweigern ist. Informationsflussregelnlegen fest, welche Subjekte Informationen in bzw. aus Objekten übermitteln bzw. erlangenkönnen. Außerdem legen sie fest, unter welchen Umständen und auf welche Art und Weisemit Daten zu verfahren ist (z. B. verschlüsselte Speicherung oder Übertragung, signierteÜbertragung, Protokollierung).Die Telematik-Sicherheitsarchitektur implementiert ein hybrides Rechtekonzept (siehe[gemGesArch]):1. Stufe Rollenspezifische Autorisierung:Die Autorisierung erfolgt anhand der Rollen des zugreifenden Subjekts. RollenbasierteZugriffsregeln sind versicherten- und objektübergreifend gültig undkönnen nicht durch einen Versicherten geändert werden. Diese Zugriffsregelnsind statisch. Eine Änderung bedarf einer gesetzlichen Regelung.2. Stufe Identitätsspezifische Autorisierung:Die Autorisierung erfolgt entweder durch die Identität des Versicherten oder anhandder Identität einer Person oder Institution, die durch den Versicherten füreine bestimmte Nutzung berechtigt wurde. Identitätsspezifische Zugriffsregelnbilden im Ermessen der Versicherten liegende Zugriffsregeln ab. IdentitätsspezifischeFestlegungen durch einen Versicherten müssen sich in dem durch rollenbasierteRegeln vorgegebenen rechtlichen Rahmen bewegen. IdentitätsspezifischeZugriffsregeln sind versicherten- und objekt- bzw. anwendungsspezifisch.In der Gesamtarchitektur [gemGesArch] ist diese Zweistufigkeit der Autorisierung durcheine Trennung in Datenbearbeitung und Datenautorisierung für die Durchsetzungsfunktion,Entscheidungsfunktion und Berechtigungsrichtlinie (Access Control Policy) repräsentiert.Der Teil der Datenbearbeitung implementiert die rollenspezifische Autorisierung, derTeil der Datenautorität die identitätsspezifische Autorisierung. Beide Autorisierungenmüssen für das Erheben, Verarbeiten und Nutzen von Daten in allen Anwendungsfällenerfolgreich sein und beide müssen durchgesetzt werden.In Abschnitt 6.5 wird die Beschreibungssprache für Berechtigungsrichtlinien für die rollenspezifischeAutorisierung beschrieben. 1212 Die identitätsspezifische Autorisierung wird im Zusammenhang mit der Wahrnehmung der Versichertenrechtein einer Folgeversion des Sicherheitskonzeptes behandelt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 74 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur6.4 Datenorte und ihre SystemgrenzenEin Datenort ist eine Stelle, in der medizinische Objekte aufbewahrt werden. Es werdendie Datenorte unterschieden:• Primärsystem (PS),• elektronische Gesundheitskarte (eGK) und• Fachdienst.Abbildung 10 zeigt die Datenorte und Informationsflussrichtungen. Die Datenorte definierendie Systemgrenzen. Jeder Informationsfluss über diese Grenzen hinaus muss durchInformationsflussregeln kontrolliert werden. Information kann vom Primärsystem zur eGK(und umgekehrt von der eGK zum Primärsystem), vom Primärsystem zum Fachdienst(und umgekehrt) und von der eGK zum Fachdienst (und umgekehrt) fließen. Der Informationsflusszwischen Primärsystem und Fachdienst bzw. eGK und Fachdienst durchläuftden Broker, welcher Informationen ggf. anonymisiert oder pseudonymisiert und die Übergabevon Informationen auditiert.Abbildung 10: Datenorte und ihre SystemgrenzenDer Heilberufsausweis (HBA/SMC) ist für die meisten Zugriffe auf die Daten des Versichertennotwendig und dient zur Autorisierung gegenüber der Funktion, die die Informationsflüssekontrolliert. In Abbildung 10 sind die Stellen durch einen roten Kreis dargestellt,an denen der HBA für einen Informationsfluss notwendig ist. In gleicher Weise kann gegebenenfallsdie Anwesenheit einer SMC den Informationsfluss ermöglichen. Im Fachdiensterfolgt eine Prüfung der Informationsflussregeln entsprechend Abschnitt 6.5.2. DieInformationsflussregeln einer Berechtigungsrichtlinie für eine TI-Anwendung müssen bzgl.der Datenorte eGK und Fachdienst formuliert werden. Dies ist für den Datenort Primärsystemnicht gefordert, da das Primärsystem außerhalb der Telematikinfrastruktur liegt. DieDatenorte können bei Bedarf verfeinert werden (z. B. um die Betrachtung des Audit-Servers – auf dem Auditdaten, jedoch keine medizinischen Daten gespeichert werden –,des Konnektors oder der Informationsflüsse zwischen dem Fachdienst VSDD und CAMSzur eGK).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 75 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur6.5 Beschreibungssprache für BerechtigungsrichtlinienIn diesem Abschnitt wird die Beschreibungssprache definiert, in der Berechtigungsrichtlinienformuliert werden.6.5.1 BerechtigungsrichtlinieEine Berechtigungsrichtlinie muss aus einer nichtleeren Menge von Informationsflussregelnbestehen.6.5.2 InformationsflussregelnDer Aufbau von Informationsflussregeln adaptiert das Schutzprofil BSI-PP0008 an die Telematikinfrastruktur.Eine Informationsflussregel muss aus folgenden Angaben bestehen:• einer Zugriffsoperation• einer Menge von Benutzeridentitäten oder einer Menge von (abstrakten) Rollen,• einer Menge von Datenklassen,• einer Menge von Datenorten,• einer Menge von Constraints,• einer Menge von Informationsflussvorschriften (IV).6.5.3 ZugriffsoperationEine Zugriffsoperation spezifiziert eine Möglichkeit, auf ein Informationsobjekt zuzugreifen.Es werden die folgenden Zugriffsoperationen unterschieden:• Create: Informationen fließen zum Datenort und werden dort in einem neuenInformationsobjekt gespeichert.• Read: Informationen fließen von einem im Datenort gespeicherten Informationsobjektnach außen (d. h. sind nach Ausführung der Zugriffsoperation außerhalbdes Datenortes verfügbar). Das Informationsobjekt im Datenort bleibtunverändert.• Update: Informationen fließen zum Datenort und ändern dort ein existierendesInformationsobjekt. Optional können durch die Zugriffsoperation auch Informationenvon dem geänderten Informationsobjekt nach außen fließen.• Delete: Ein Informationsobjekt wird im Datenort gelöscht. Die im Informationsobjektenthaltenen Informationen sind nach Ausführung der Zugriffsoperationnicht mehr verfügbar.• Hide/Unhide: Nach Ausführung der Zugriffsoperation Hide auf einem Informationsobjektkönnen Informationen weder zum noch vom Informationsobjektgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 76 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturfließen (damit ist dieses Informationsobjekts nicht mehr sichtbar). Die ZugriffoperationUnhide lässt den Informationsfluss wieder zu.Die Menge der Zugriffsoperationen ist für die derzeitigen Fachkonzepte ausreichend. BeiBedarf kann diese Menge der Zugriffsoperationen zukünftig erweitert werden. Es mussbei einer Erweiterung jedoch sichergestellt sein, dass durch die Aufnahme neuer Zugriffsoperationenkeine Sicherheitslücken durch die zusätzlichen Kombinationen von Operationenentstehen können und die Rechteverwaltung für den Versicherten verwaltbar bleibt.6.5.4 Subjekt (Benutzer und Rolle)Ein Subjekt ist entweder ein Benutzer oder eine Rolle. Ein Benutzer kann eine natürlicheoder juristische Person bzw. ein technischer Prozess sein, der im Auftrag einer Personabläuft. Beispiele sind die natürliche Person Dr. Müller, die juristische Person ArztpraxisSchulze oder der Prozess zum Schreiben einer eVerordnung auf die eGK.Nach der Norm [ANSI INCITS 359-2004] für Role-based Access Control ist eine Rolle wiefolgt definiert:“A role is a job function within the context of an organization with some associated semanticsregarding the authority and responsibility conferred on the user assigned to the role”.Beispiele für Rollen wären Arzt, Versicherter etc. Die mit Rollen assoziierten Berechtigungenwerden durch Informationsflussregeln modelliert.Rollen können hierarchisch in einer Spezialisierungsrelation angeordnet werden, wobeieine Rolle höchstens die Spezialisierung genau einer Rolle sein darf, es jedoch beliebigviele Spezialisierungen einer Rolle geben kann. Eine spezialisierte Rolle S(A) einer RolleA hat alle Eigenschaften der Rolle A (Berechtigungen, Constraints, etc.). Die spezialisierteRolle S(A) kann die von Rolle A erworbenen Eigenschaften jedoch um Eigenschaften erweitern,die Rolle A nicht besitzt (z. B. zusätzliche Berechtigungen).Jeder Benutzer in der Telematikinfrastruktur ist zu jedem Zeitpunkt immer genau einerRolle zugeordnet. Diese Rolle bestimmt die Berechtigungen des Subjektes und somit dieerlaubten Zugriffoperationen. Mehrere Subjekte können dieselbe Rolle besitzen, wennnicht durch ein Constraint anders festgelegt (siehe 6.5.5).Eine abstrakte Rolle dient einer einfacheren und handhabbareren Verwaltung der Berechtigungen,sie dient jedoch nicht der Modellierung von fachlichen Akteuren. An abstrakteRollen können (genauso wie an nicht abstrakte Rollen) Berechtigungen geknüpftwerden, die sie an Rollen vererben. Im Unterschied zu nicht-abstrakten Rollen, dürfenSubjekte abstrakten Rollen nicht zugeordnet werden. Subjekte müssen immer nicht-abstraktenRollen zugeordnet sein.6.5.5 ConstraintConstraints schränken die erlaubten Informationsflüsse einer Informationsflussregel ein.Beispielsweise darf die Rolle Versicherter medizinische Daten von der eGK nur lesen(d. h. Informationen von der eGK zum Versicherten fließen), wenn es sich um seine eigeneKarte handelt.Es gibt folgende Vorgaben an die Formulierung von Constraints:• Constraints dürfen die erteilten Berechtigungen nur einschränken, niemals erweitern.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 77 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Constraints müssen sich auf eine Operation beziehen und dürfen nicht denAufruf anderer Operationen fordern.6.5.6 Datenklasse und InformationsobjektEine Datenklasse repräsentiert eine Menge von Informationsobjekten mit gleichartigenEigenschaften, die in Bezug auf Zugriffsberechtigungen gleich behandelt werden. JedesInformationsobjekt ist genau einer Datenklasse zugeordnet. Datenklassen können hierarchischin einer Verfeinerungsrelation angeordnet werden, wobei eine Datenklasse Verfeinerunghöchstens einer Datenklasse sein darf; eine Datenklasse kann jedoch zu beliebigvielen Datenklassen verfeinert werden.6.5.7 InformationsflussvorschriftenInformationsflussvorschriften können Bedingungen an die Informationsflüsse stellen. Esmüssen mindestens die folgenden Bedingungen angegeben werden:• ob Informationen zu ver- bzw. entschlüsseln sind,• ob Informationen zu signieren bzw. Signaturen geprüft werden müssen,• ob die Tatsache eines Informationsflusses protokolliert werden muss,• ob Informationen anonymisiert werden müssen,• ob Informationen pseudonymisiert werden müssen.Hierbei muss in den Informationsflussvorschriften einer konkreten Berechtigungsrichtlinieangegeben werden, wer bzw. mit welchem Schlüssel signiert/geprüft oder ver-/entschlüsselt wird.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 78 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur6.6 Zusammenstellung der AusgangsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02289AS_BER_F0SZugriff_AutorisierungDie Verarbeitung von Informationen in der TI darf (neben dem Versichertenselbst) nur autorisierten Leistungserbringern möglich sein und derVersicherte MUSS die Informationsflüsse seiner Anwendungen kontrollierenkönnen. Informationsflüsse MÜSSEN entsprechend sicherheitstechnischerRahmenbedingungen geeignet gesteuert werden können (z.B. Informationsfluss nur nach geeigneter Authentifizierung oder nachdem Signieren von Daten).Kap. 6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 79 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7 SicherheitsarchitekturDas vorliegende Kapitel beschreibt Architekturaspekte der Telematikinfrastruktur aus Sicherheitssicht.In der Telematikinfrastruktur existieren prinzipiell zwei Ebenen, in denen Sicherheitsdiensteeingesetzt werden. Einerseits werden Dienste auf der Netzebene angewendet,andererseits auf der Anwendungsebene. Beide Ebenen sind unabhängig voneinander undverfolgen unterschiedliche Ziele.7.1 Überblick Sicherheitsdienste der NetzebeneDie Netzwerk- und Transportschichten (OSI Layer 3-4) implementieren Authentifizierungund Autorisierung von maschinellen Kommunikationsendpunkten, sowie den Schutz derVertraulichkeit und Integritätsschutz der übertragenden Daten. Die Nichtabstreitbarkeitund weitere Sicherheitsanforderungen werden ausschließlich durch die Applikationsschichtsichergestellt [gemGesArch].Unabhängig von der Sicherung der Integrität und Vertraulichkeit der übertragenen Datenauf Netzwerk- bzw. Transportschicht, müssen bei bestimmten Daten (z. B. medizinische,personenbezogene Daten) Maßnahmen getroffen werden, um die Integrität/Vertraulichkeitder Daten/Nachrichten auf höheren Ebenen sicherzustellen.Aus Sicherheitssicht findet auf der Netzebene folgender Ablauf statt:Die Integrität und Vertraulichkeit von Datenpaketen wird zwischen Konnektor und VPN-Konzentrator durch die Verwendung von IPSec gewährleistet. Vor dem Aufbau der VPNVerbindung durch den Konnektor (nur dieser darf Verbindungen initiieren) werden die beidenKommunikationsendpunkte authentisiert. Der VPN-Konzentrator überprüft durch Kontrolledes SM-NK Zertifikats, ob der Konnektor zugelassen ist. Der Konnektor überprüftdas Zertifikat des VPN-Konzentrators ebenfalls.Wenn die VPN Verbindung Konnektor zu VPN-Konzentrator aufgebaut ist, kann einZugriff auf die Telematikinfrastruktur stattfinden, der Konnektor kann sich z.B. mit demBroker verbinden.Vor dem Vollzugriff auf die Telematikinfrastruktur muss noch die SMC-B geprüft werden,damit sichergestellt ist, dass nur eine zugelassene Institution voll auf die Telematikinfrastrukturzugreifen kann.Auf Transportschicht – sowohl im Frontend VPN als auch im Backend VPN – wird mitHilfe von Transport Layer Security/Secure Socket Layer (TLS/SSL) [RFC2246] die Integritätund Vertraulichkeit von direkten Verbindungen miteinander kommunizierender Telematik-Servicessichergestellt. Die Nachrichten selbst sind auf höheren OSI Protokoll-Ebenennach der Übertragung nicht mehr automatisch weiter geschützt. Deshalb müssen dieNachrichten zusätzlich auch auf der Anwendungsebene separat geschützt werden. Zudemfindet eine Authentisierung und Autorisierung von Services auf Verbindungsebenestatt. [gemGesArch]gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 80 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.2 Überblick Sicherheitsdienste der AnwendungsebeneIn Abbildung 11 sind die Sicherheitsdienste auf Anwendungsebene dargestellt. Zusätzlichwird die Kommunikation zwischen den einzelnen Komponenten noch auf den darunterliegenden Protokollschichten, insbesondere der Netz- und der Transportschicht (SSL/TLSsiehe die Architekturentscheidung AE 6.3 [gemGesArch]), zusätzlich geschützt. Diesesind jedoch unabhängige und rein zusätzliche Funktionen zur Authentifizierung, Autorisierungvon Kommunikationsendpunkten sowie der Vertraulichkeit und des Integritätsschutzesder übertragenen Daten.Primärsysteme•PVS, AVS, KISaktive Patiententerm.PC-Term., SB-Term.•Versicherter@homeAnwendungsKonnektor•Nutzung•Anw. des Vers.•Rechte-Mgmt.Anwendungsgateway•Audit für Nicht-AbstreitbarkeitAnonymisierung,•Anwendungsverwaltung•§291a Fachdienste (Pflicht &Freiwillig)• VSDM, VODM, Notfalldaten, AMTS,• Patientenfach, Patientenquittung• Arztbrief, ePatientenakteMehrwertdiensteSicherheitsdienste (fachdienstbezogen)• Authentisierung, Autorisierung• RechteverwaltungPrimärsystemAnwendungs-KonnektorBrokerFachdienstListeAnwendungListeElementReq./Res.SOAP Req./Res.CRUDLSmed.DateneGKHBAAudit,SAK,ver/entschlüsselnKryptofunktionenSchlüsselAudit,TSSVS, SCS, SAKKryptofunktionenSchlüsselAuth., Autor.SAK, …..KryptofunktionenSchlüsselIdentitätenRechte,TicketsAbbildung 11: Verwendung der Sicherheitsdienste und Sicherheitsfunktionen auf AnwendungsebeneAus Sicherheitssicht findet auf der Anwendungsebene folgender Ablauf statt:• Das Primärsystem initiiert die fachlichen Geschäftsvorfälle zur Nutzung dermedizinischen Daten und Anwendungen des Versicherten.• Im Konnektor wird die entsprechende Ablauflogik abgearbeitet. Dazu werdendie nachfolgenden Sicherheitsdienste benötigt (siehe u. a. AF2.1 - AF2.6 in[gemGesArch]) und von der Konnektoranwendung aufgerufen:ooQualifizierte Signatur durch den Leistungserbringer mit seinem HBA bei derÜbergabe von medizinischen Daten aus dem Primärsystem.Verschlüsselung der medizinischen Daten mit der eGK des Versichertenbei der Übernahme von Daten in der Anfrage bzw. Entschlüsselung vonDaten bei der Übergabe von medizinischen Daten in der Antwort an denLeistungserbringer.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 81 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturooSignatur der SOAP-Requests durch HBA/SMC des Leistungserbringersund der eGK des Versicherten zum Nachweis der Authentizität der Anfrage(siehe AE 4.6 [gemGesArch]).Ein Audit-Record zu Datenschutzzwecken wird auf die eGK geschriebenDie entsprechenden Sicherheitsfunktionen werden über eine Kryptolibrary incl.Signaturanwendungskomponente (SAK) von den Karten der Leistungserbringer(HBA/SMC) und der Versicherten (eGK) erbracht.• Im Broker werden die Nachrichten geprüft und an den entsprechenden Fachdienstweitergeleitet. Dazu werden folgende Sicherheitsdienste und Funktionenbenötigt:ooAnonymisierung: Für festgelegte Fachdienste (z. B. Online Anfrage derVersichertenstammdaten) wird vom Broker der Leistungserbringerbezugüber den Trusted Service anonymisiert. Dazu wird die Nachrichtensignaturund die Rolle des Leistungserbringers geprüft (Security Validation Service(SVS)) und durch eine Signatur des Brokers (Security Confirmation Service(SCS)) in der Nachricht bestätigt.Versichertenzentriertes Audit (siehe AuditS [gemGesArch]) wird geschrieben.• Der Fachdienst muss die SOAP-Anfrage authentisieren und den Zugriff aufdie medizinischen Daten des Versicherten prüfen (siehe Access Control DecisionFunction in [gemGesArch]) und autorisieren.ooDie Authentizität der Nachrichtensignaturen des Versicherten (eGK), desLeistungserbringers (HBA/SMC) bzw. bei Anonymisierung des Brokerswerden geprüft.Die Autorisierungen des Zugriffs auf medizinische Daten sind fachdienstspezifisch(siehe dazu die Berechtigungsrichtlinien in Anhang D).• Die Verwaltung der sicherheitsrelevanten Attribute eines Dienstes oder einzelnerObjekte wie Identitäten der Benutzer, Objekt-Schlüssel oder Zugriffsrechteerfolgt durch die konsistente und einheitliche Verwendung von Service- undObjekt-Tickets (siehe Abschnitt 7.5).7.2.1 Offline- und Online-Modus der TelematikinfrastrukturLaut [gemSpec_Kon#3.4.4] ist der Offline Modus der Telematikinfrastruktur der Modus, indem beim Konnektor „keine Verbindung (VPN) zur zentralen Telematikinfrastruktur zurVerfügung . Viele Funktionen (z.B. das Lesen von Karteninhalten) können jedochuneingeschränkt genutzt werden. Andere Funktionen wie z.B. das Prüfen der Gültigkeitvon Sperrinformationen oder der Transport von Daten von und zur Telematikinfrastruktursind nicht möglich, sie erfordern zwingend eine Netzverbindung. Bestimmte Funktionenkönnen im Offline-Fall nur eingeschränkt oder nicht genutzt werden. Ist ein Konnektor„offline“, den Primärsystemen als Antwort auf Funktionsaufrufe mitgeteilt nicht oder nur eingeschränkt durchgeführt werden können. DerOnline-Modus ist der Normalfall. Der Offline-Modus ermöglicht, dass in Fällen, in denenkeine VPN Verbindung aufgebaut werden kann, wichtige Funktionen trotzdem genutztwerden können.“gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 82 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDer Offline-Modus ist bei Beginn des Aufbaus der Telematikinfrastruktur bis zu einemdefinierten Zeitpunkt der Standardfall in der Telematikinfrastruktur. Auch später muss derOffline-Modus in der Telematikinfrastruktur als Backup-Fall, bei dem die Sicherheit ebenfallsgegeben sein muss, zwingend berücksichtigt werden.Im Offline-Modus sind viele Funktionen, die im Online-Modus die Sicherheit garantieren,nicht verfügbar. So kann z. B. nicht aktuell geprüft werden, ob Zertifikate, die in den verschiedenenPKIs verwendet werden, gültig sind. Diese Überprüfung kann dann beispielsweisenur mit einer lokal vorgehaltenen Kopie erfolgen. Des Weiteren ist auch die Protokollierungdurch den Auditdienst nicht unmittelbar möglich. Aus diesem Grund ist dieseFunktionalität unter Verwendung des Konnektors direkt auf der eGK vorgesehen.Es gelten daher für den Offline-Fall besondere Anforderungen. Die für den Offline-Fallvorgesehenen Sicherheitsanforderungen MÜSSEN mittels Card-2-Card (C2C) Sicherheitsfunktionensichergestellt werden. Dies umfasst u. a. die Offline Protokollierung vonZugriffen auf der eGK, die C2C Authentifizierung mittels CV-Zertifikaten und die Autorisierungüber rollenbasierte, verbindliche Access Control Policies für einen Datenbearbeiter.Die Autorisierung für den Offline-Zugriff durch die Versicherten erfolgt durch die Herausgabeder eGK. [gemGesArch]7.2.1.1 Migrations- und ReleaseplanungDie Telematikinfrastruktur ist zu Beginn nur im Offline-Modus verfügbar. Einige Anwendungenwerden ebenfalls im Offline-Modus verfügbar sein und in einem späteren Releaseoder Funktionsabschnitt in den Online-Modus überführt. Diese Migration erfordert einesicherheitstechnische Analyse und Vorbereitung.So werden in den Testvorhaben die freiwilligen Anwendungen Notfalldaten und Arzneimitteltherapiesicherheitvordringlich realisiert. Das Patientenfach hingegen wird erst ineinem weiteren Schritt ausgeführt. Trotzdem muss z. B. auch das Patientenfach bereits ineinem frühen Stadium der Architektur aus Sicherheitssicht betrachtet werden, denn eineneue technische Umgebung für die Heimumgebung des Versicherten muss für diese Anwendungfestgelegt werden und über geeignete Komponenten (Versicherten-Portal) andie Telematikinfrastruktur angebunden werden. Im Falle des Patientenfaches könnenVersicherte beispielsweise auch mittels einer eigenen Signaturkarte zugreifen, die übereine qualifizierte Signatur verfügt. Damit ergeben sich durch die Anwendung Patientenfachwesentliche zusätzliche Anforderungen an die Rechteverwaltung (u. a. Delegation anSignaturkarte des Versicherten) und Funktionalität der Service- und Objekttickets (u. a.Entschlüsselung, Umschlüsselung auf dem Versicherten-Portal), die als Erweiterungsstufenin der Gesamtarchitektur berücksichtigt sein müssen.Teilweise werden auch (zumindest für eine Übergangszeit) gleichzeitig unterschiedlicheVersionsstände von Software (z. B. Verschlüsselungsalgorithmen) und/oder Hardware(z. B. eGK) im Einsatz sein. Dieser Umstand muss entsprechend beachtet werden.7.3 Schutzbedarf für Datenklassen technischer ObjekteEbenso wie fachliche Informationsobjekte ohne eigene Schutzbedarfsfeststellung Datenklassenzugeordnet werden (siehe Abschnitt 5.3), werden auch für technische Informationsobjekteohne eigene Schutzbedarfsfeststellung Datenklassen definiert und derenSchutzbedarf bestimmt. Eine Schutzbedarfsanalyse einzelner technischer Informationsobjekteist im Anhang C gegeben. An dieser Stelle werden die technischen Datenklassenund deren Schutzbedarf präsentiert.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 83 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 84 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Tabelle 6: Schutzbedarf übergreifender technischer Datenklassen in der TelematikinfrastrukturID Bezeichnung BeschreibungSchutzbedarfDk08 Systemdaten 13 Daten, die zur Funktion eines Systemsbenötigt werden oder zur Beschreibungeines Systemzustandesdienen (z. B. Auslastung eines IT-Systems, Status einer Transaktion).Dk09Öffentliche SicherheitsobjekteDk10 Temporäre Sicherheitsobjekteund kryptographischeDatenDk11a Kryptographische Sicherheitsobjekteunterpersönlicher KontrolleDaten, die zur Anwendung asymmetrischerkryptographischer Funktionen imRahmen von Prüfprozessen oder gerichtetervertraulicher Kommunikation (öffentlicherSchlüssel bei asymmetrischer Verschlüsselungoder Zertifikate) benötigtwerden.Daten, die zur Anwendung von Sicherheitsdienstenund insbesondere kryptographischerFunktionen dienen (z. B.kryptographische Session-Schlüssel), fürdie ein Mechanismus zur Beschränkungder Lebensdauer auf einen Zeitraum (24hin Ausnahmenfällen 72 Stunden) existiert.Daten, die zur Anwendung von Sicherheitsdienstenund insbesondere kryptographischerFunktionen dienen, wieprivate kryptographische Schlüssel fürÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVertraulichkeitIntegritätVerfügbarkeit Authentizität Nichtabstreitbarkeitmittel mittel – mittel mittelmittel sehr hoch hoch sehr hoch sehr hochhoch mittel irrelevant irrelevant irrelevantsehr hoch sehr hoch sehr hoch sehr hoch sehr hoch13 Falls Systemdaten personenbezogene Daten enthalten, MUSS der Schutzbedarf für personenbezogene Daten berücksichtigt werden. Der hier angegebeneSchutzbedarf ist dann nicht ausreichend.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 85 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturIDBezeichnungBeschreibungSchutzbedarfqualifizierte Signaturen und deren Benutzungder persönlichen Kontrolle durcheine PIN (o. ä.) unterliegen.VertraulichkeitIntegritätVerfügbarkeit Authentizität NichtabstreitbarkeitDk11b Personen- bzw. RollenbezogeneSicherheitsobjekteund kryptographischeDatenDk11c Statische Sicherheitsobjekteundpseudonyme kryptographischeDatenDaten, die zur Anwendung von Sicherheitsdienstenund insbesondere kryptographischerFunktionen zur Darstellungvon Identitäten und Rollen dienen wieprivate kryptographische Schlüssel.Daten, die zur Anwendung von Sicherheitsdienstenund insbesondere kryptographischerFunktionen dienen (z. B.geheime und private kryptographischeSchlüssel in Maschinenzertifikaten). DasSchlüsselmaterial lässt keinen (direkten)Rückschluss auf Identitäten zu.hoch sehr hoch sehr hoch sehr hoch sehr hochhoch hoch mittel hoch hochgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 86 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4 Zonenkonzept7.4.1 Tiers, Sicherheitszonen und SicherheitsbereicheDie Komponenten der Telematikinfrastruktur unterscheiden sich in ihrem Schutz, den siebereits dadurch erhalten, dass sie in einem logisch und physikalisch gesicherten Umfeldbetrieben werden. Insbesondere ist der Zugriff und Zugang zu diesem Umfeld individuelleingeschränkt.Das logische Umfeld wird als Sicherheitszone (oder kurz Zone) bezeichnet, das physikalischeUmfeld hingegen als Sicherheitsbereich.Das Zonenkonzept unterscheidet verschiedene Sicherheitszonen mit unterschiedlichenSicherheitseigenschaften. Es gibt sechs Zonen auf der obersten Ebene. Jede dieserZonen (Top-Level-Zonen) ist noch weiter in hierarchisch untergeordnete Zonen(Subzonen) unterteilt:Das in diesem Dokument vorgestellte Zonenkonzept setzt auf der Strukturierung der Gesamtarchitekturin einzelne Tiers auf.Abbildung 12 zeigt die Tiers der Gesamtarchitektur:Abbildung 12: Architektur-Tiers und SystemgrenzenZum Vergleich zeigt die nachfolgende Abbildung rein schematisch die Zuordnung vonKomponenten zu Zonen (farbig am linken Rand gekennzeichnet):gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 87 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 13: Exemplarische Zuordnung von Komponenten zu ZonenJede physisch in der Telematikinfrastruktur eingesetzte Komponente (außer Firewalls)befindet sich in genau einer Zone des Zonenkonzepts.Eine Sicherheitszone stellt für die verarbeitende Komponente eine Umgebung mitdefinierten Sicherheitseigenschaften bezüglich des Schutzes der Kommunikationsbeziehungenzu anderen Zonen dar.Die Kombination des Schutzbedarfes des Informationsobjektes mit denSicherheitseigenschaften der Umgebung einer Komponente bestimmt die von derKomponente ggf. zusätzlich zu erfüllenden Sicherheitseigenschaften. Diese werden alsAnforderungen an die jeweilige Komponente (z. B. im Rahmen eines Protection Profiles)formuliert und sind nicht Teil des Zonenkonzepts.Jede Komponente des Komponentenmodells ist einer Sicherheitszone zugeordnet. Kanneine Komponente in verschiedenen Sicherheitszonen platziert werden, können je nachZone auch unterschiedliche Sicherheitsanforderungen an diese Komponente formuliertsein. Die Festlegung der unterschiedlichen Anforderungsmengen in Abhängigkeit von dergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 88 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturEinsatzumgebung erfolgt beispielsweise im entsprechenden Schutzprofil derKomponente.Sicherheitszonen unterscheiden sich durch:• den Eigentümer der Prozesse und Daten,• die Klassifikation und den Schutzbedarf der zu verarbeitendenInformationsobjekte,• die Benutzergruppen und Komponenten, die auf diese Informationsobjektezugreifen dürfen,• die Bedrohungen und die umgesetzten Sicherheitsmaßnahmen.Die Sicherheitsarchitektur beschreibt für die einzelnen Sicherheitszonen dieAnforderungen an die notwendigen Sicherheitsdienste und deren Schnittstellen.Die verschiedenen Zonen der Telematikinfrastruktur sind grob nach folgendem Schemaden Tiers zugeordnet 14 :Tabelle 7: Bildung von Zonentypen durch Kombination von Topologie-EigenschaftenTierZoneService Consumer TierConsumer AdapterZone 1Telematik Tier dezentral Zone 2Telematik Tier zentral Zone 3Provider AdapterService Provider TierZone 4Legacy and Existing Application Tier Zone 5Allerdings bestimmen letztlich der Schutzbedarf der von einer Komponente verarbeitetenDaten sowie die aus funktionalen Anforderungen 15 resultierenden Bedrohungen dieNotwendigkeit der Zuordnung der Komponente zu einer Zone mit bestimmtenEigenschaften.In den meisten Fällen resultiert die Zuordnung von Komponenten zu Zonen aus dem inTabelle 7 dargestellten Schema.Aus dem Blickwinkel des Sicherheitskonzeptes sind Tiers und Sicherheitszonenzueinander orthogonale Betrachtungen. Konzeptionell werden Komponenten bei einerzweidimensionalen Anordnung mit den Tiers auf der einen und den Zonen auf deranderen Achse an den Schnittpunkt dieser beiden Ordnungsmerkmale, d. h. sowohl einerTier als auch einer Zone zugeordnet. Dieser Zusammenhang ist in Abbildung 14 grafischdargestellt.14 Die Mehrwertdienste und somit Zone 6 sind hier nicht dargestellt, da es keine direkte Entsprechungzu den Tiers der Gesamtarchitektur gibt.15 z. B. öffentliche DNS-Server müssen von vertrauenswürdigen Quellen erreichbar sein, der Konnektorwird in der Umgebung des Leistungserbringers (Zone 1) betrieben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 89 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTierExplizite Zuordnung einerKomponenten zu einer Tier undeiner ZoneTier NTier bestimmtfunktionale /softwaretechnischeEigenschaftenTier 2Tier 1ZoneZone bestimmtSicherheitseigenschaftenAbbildung 14: Zusammenhang von Schichten/Tiers und Zonen7.4.2 Klassifizierung der Zonen7.4.2.1 Top-Level-ZonenDas Zonenkonzept stellt eine von einer physischen und logischen Netzwerktopologieabstrahierte Darstellung der Telematikinfrastruktur dar. Es folgt zunächst dem Schemavon „aus Sicht der gematik nicht ausreichend vertrauenswürdigen Netzen in Zone 1“ zu„aus Sicht der gematik vertrauenswürdigeren Netzen in den Zonen 2, 3 und 4“.Folgende Zonen kommen noch hinzu:Dezentrales Backend extern (Zone 5). Zone 5 ist die Zone in der die originärenDatenbestände (z. B. Kostenträger-Infrastrukturen) positioniert sind. Die Komponentender dort vorhandenen Infrastrukturen unterliegen (wie bereits heute) den lokalenSicherheitsanforderungen und werden auch in Zukunft nicht von der gematik direktgeregelt / geprüft. Aus der Sicht der Telematikinfrastruktur sind dieseKomponenten/Infrastrukturen daher weniger vertrauenswürdig.Mehrwertdienste (Zone 6). Mehrwertdienste sind über Standarddienste (Freiwillige- undPflichtanwendungen nach §291a SGB V) hinausgehende Dienste, welche sich auf derBasis von Marktmechanismen herausbilden sollen. Die Ausgestaltung dieser Dienste istnoch weitgehend offen. Neben der mitbenutzten Telematikinfrastruktur, die in den Zonen1-5 positioniert ist, wird es noch weitere Mehrwertdienst-Infrastruktur geben, für die dieZone 6 angelegt wurde.Das Zonenkonzept formuliert das Sicherheitsniveau von Einsatzumgebungen, welchesdurch eine konkrete Netzwerk-, Anwendungs- und Sicherheitsarchitektur realisiert werdenmuss. Beispielsweise darf die Architektur nur zonenübergreifendeKommunikationsverbindungen im Rahmen der erlaubten Zonenübergänge vorsehen. DieAufstellung der erlaubten Kommunikationsverbindungen des Zonenkonzepts gibt abernoch keine konkrete Auskunft über die tatsächlich stattfindendenKommunikationsverbindungen (es können weniger Kommunikationsverbindungenumgesetzt werden, d. h. der erlaubte Rahmen wird nicht vollständig ausgeschöpft).Detailinformationen über die tatsächlichen Kommunikationsverbindungen sind in dengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 90 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturjeweiligen Konzepten (Netzwerk-/Infrastruktur, Facharchitektur oder Betriebsdokumentation)dargestellt.7.4.2.2 ZonentypenZonentypen werden aus einer Kombination der Topologie-Eigenschaften zentral/dezentralund intern/extern gebildet, wobei eine Zone nur jeweils entweder zentral oder dezentralbzw. intern oder extern sein kann. Für jede Zone erfolgt die Festlegung der Zugehörigkeitzu einem Zonentyp.Folgende Topologie-Eigenschaften werden unterschieden:Tabelle 8: Topologie-EigenschaftenBezeichnung BeschreibungexterninterndezentralzentralEine Zone wird als extern bezeichnet,οwenn sie sich außerhalb der administrativen Hoheit eines von dergematik zum Betrieb von Komponenten der Telematikinfrastrukturautorisierten Betreibers befindet oderο wenn sie direkt (unabhängig von der OSI-Schicht) mit einerderartigen Komponente in Kontakt steht.In einer externen Zone können sich unidentifizierte Benutzer befinden.Aufgrund fehlender Kontrollmöglichkeiten und unbekannter Übergängeaus anderen Netzwerken sind Netzwerkzugänge auf das minimalefunktional benötigte Maß zu reduzieren.Eine Zone wird als intern bezeichnet, wenn sie sich innerhalb deradministrativen Hoheit eines von der gematik zum Betrieb vonKomponenten der Telematikinfrastruktur autorisierten Betreibersbefindet.Eine Zone wird als dezentral bezeichnet, wenn sie sich außerhalb desexternen Zugangsrouters (Border-Gateway) gegenüber dem Internet(z. B. Primärsysteme) oder außerhalb des internen Zugangsrouterszum Backbone der Telematikinfrastruktur befindet (z. B. Backend-Systeme von Leistungsträgern mit den originären Patientendaten).Eine Zone wird als zentral bezeichnet, wenn sie sich innerhalb desexternen Zugangsrouters (Border-Gateway) gegenüber dem Internetund innerhalb des internen Zugangsrouters zum Backbone derTelematikinfrastruktur befindet.In der nachfolgenden Tabelle sind die möglichen Zonentypen als Kombinationen vonTopologie-Eigenschaften zusammengefasst:Tabelle 9: Bildung von Zonentypen durch Kombination von Topologie-Eigenschaftendezentral zentralintern x xextern x xFür Zonentypen sind Sicherheitsanforderungen definiert, welche für die zugeordnetenTop-Level Zonen als auch für alle deren Subzonen gelten (etwaige Ausnahmen sind beider jeweiligen Zone entsprechend formuliert).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 91 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4.2.3 AnwendertypenNeben den Zonentypen werden auch zwei Anwendertypen, die Zugriff auf Komponentenhaben, unterschieden:Tabelle 10: AnwendertypenBezeichnung BeschreibungExterner AnwenderInterner AnwenderEin externer Anwender ist keiner Organisationseinheit zugeordnet,die für den Betrieb von Telematikinfrastruktur Komponentenvon der gematik autorisiert wurde.Ein interner Anwender ist einer Organisationseinheit zugeordnet,die für den Betrieb von Telematikinfrastruktur Komponenten vonder gematik direkt oder indirekt (Delegation) autorisiert wurde.7.4.2.4 Typen des DatenflussesDie Form des Datenaustausches von Komponenten wird ebenfalls typisiert:Tabelle 11: Typen des DatenflussesBezeichnung BeschreibungInformationsflussKontrollflussFluss von Daten, die zum Anwendungskontext einer Komponentegehören und alle Informationen, die auf Personen wie Versicherteoder Leistungserbringer rückführbar sind.Fluss von Daten, die allein der Steuerung eines Ablaufes dienen(Verbindungsaufbau, Systeminformationen,Konfigurationsinformationen etc.) und die insbesondere nicht aufPersonen, wie Versicherte oder Leistungserbringer, sondern aufSysteme rückführbar sind.7.4.2.5 Schutzstufen für ZonenübergängeZum Schutz von Zonenübergängen werden folgende Schutzstufen definiert:Tabelle 12: Schutzstufen für ZonenübergängeBezeichnung BeschreibungStufe 1Stufe 2Stufe 3Stufe 4Es MUSS mindestens eine Filterung auf Basis von statischenFiltern von Netzwerkpaketen (Static Packetfiltering) stattfinden.Es MUSS mindestens eine Filterung auf Basis der Analyse derjeweiligen Verbindung (Stateful Inspection) stattfinden. Die Anforderungvon Stufe 1 MUSS erfüllt werden.Die Authentizität des Senders jedes Netzwerkpakets MUSS gegebensein. Die Anforderungen von Stufe 1 und 2 MÜSSEN erfülltwerden.Es MUSS eine Filterung/Prüfung auf der Ebene des Applikationsprotokollsauf die Zulässigkeit der übertragenen Inhalte erfolgen(„Application Level Firewall“ bzw. „Content-Inspection“).Die Anforderungen von Stufe 1 und 2 MÜSSEN erfüllt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 92 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4.2.6 Gesamtliste der vorgegebenen Zonen und SubzonenIn der folgenden Tabelle sind alle innerhalb des Sicherheitszonenkonzeptes festgelegtenSubzonen aufgeführt. Ein Dienstbetreiber muss gegebenenfalls weitere Subzonenfestlegen, um den vorgegebenen Sicherheitsanforderungen Rechnung zu tragen.Die Subzonen werden einheitlich nummeriert und bezeichnet, ggf. ist in einer Top-Level-Zone nur eine Untermenge der möglichen Subzonen vorhanden. Alle Komponentenmussen Subzonen zugeordnet werden, Komponenten auf Top-Level-Ebene gibt es nicht.Tabelle 13: Nummerierung und Bezeichnung der SubzonenNummerBezeichnung1 Anwendungsdienste2 Öffentliche Dienste3 Eingeschränkte Dienstesteigende Einschränkungdes Zugangs4 Benutzerindividuelle Dienste5 Infrastrukturdienste6 Sicherheitsdienste7 Administrationsdienste8 Monitoring Dienste9 (Zugangs)-netzwerkgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 93 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 15: Zonenkonzept7.4.3 Beschreibung der ZonenDie Beispiele sind nicht normativ.7.4.3.1 Zone 1 - Dezentral ExternDie Zone 1 ist die Zone, in der der Leistungserbringer die mit der Telematikinfrastrukturverbundenen Primärsysteme betreibt. Es handelt es sich um dezentrale Systeme mitgespeicherten Datenbeständen in der Verantwortung der Leistungserbringer. DieseDatenbestände und Systeme existieren zum überwiegenden Teil bereits heute undunterliegen entsprechenden gesetzlichen Regelungen.Die sektorspezifischen Regelungen werden an dieser Stelle referenziert werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 94 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

An der Verantwortung für den Schutz dieser Datenbestände bzw. der entsprechendenSysteme tritt durch die Einführung der Telematikinfrastruktur keine Veränderung ein. DieZone grenzt an die Telematikinfrastruktur. Die gematik hat keine administrative Gewaltüber Geräte, die sich in dieser Zone befinden.Um die unterschiedlichen Einsatzbedingungen in den Sektoren zu berücksichtigen,werden in dieser Zone öffentlich zugängliche, überwachte und zutrittsbeschränkteSicherheitsbereiche unterschieden. Der Betreiber ist für die Einhaltung derEinsatzbedingungen der Komponenten der Telematikinfrastruktur (z. B. Kartenterminals,Trusted Viewer, eKiosk-Umgebungen) verantwortlich, die in diesen Bereichen aufgestelltund betrieben werden. Schnittstellen zu der Zone 1 werden durch Firewalls realisiert, dieeine kontinuierliche Abgrenzung zwischen den Zonen gewährleisten.Auch das Internet mit seinen angeschlossenen Knoten (Wide Area Network {WAN-}Router, Zugangsrouter) als Transportnetz zwischen Konnektor und VPN-Konzentrator istder Zone 1 zugeordnet.Tabelle 14: Zone 1 - Dezentral ExternÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturSicherheitszoneBezeichnung Beschreibung Beispiel1 DezentralFrontend externDie Sicherheit dieser Zone unterliegtnicht der Regelungshoheit der gematik,sondern ist in der Verantwortung derLeistungserbringer.Durch wohldefinierte Sicherheitsmaßnahmengegenüber den zuerwartenden Bedrohungen aus Zone 1wird die von der gematik betriebeneTelematikinfrastruktur abgegrenzt undin soweit bzgl. ihrerSicherheitseigenschaften normiert.1.1 Dienste Anwendungssysteme inkl. Betriebssystemund Systemumgebung (z. B.Praxissysteme).1.2 öffentlich öffentlich zugängliche Umgebung z. B.beim Leistungserbringer mit unkontrolliertemPublikumsverkehr.1.3 überwacht überwachte Umgebung z. B. beimLeistungserbringer1.4 zutrittsbeschränktzutrittsbeschränkte Umgebung z. B.Rechenzentrum, separates Arbeitszimmereines LeistungserbringerPVS, KonnektorSelbstbedienungs-Terminal imEingangsbereicheines Krankenhausesoder Filialeeines Kostenträgers.Primärsysteme:PVS, AVS, KISKartenterminals,Trusted ViewerKIS imRechenzentrumKartenterminals,Primärsysteme,Trusted Viewergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 95 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturSicherheitszoneBezeichnung Beschreibung Beispiel1.9 Netzwerk Aktive oder passive Netzwerkkomponenten(z. B. Switches inPrimärnetzen, öffentlicheTelekommunikationsinfrastruktur).LAN der Leistungserbringer7.4.3.2 Zone 2 - Zentral ExternAlle Geräte, die in der Zone 2 angeordnet sind, müssen die Telematikinfrastruktur-Sicherheitsrichtlinienund -standards erfüllen. Teilnehmer, die sich in der Zone 2 einloggen, sindautorisiert und bekommen hier zudem eine Zuordnung zu den verschiedenen Systemenund Prozessen innerhalb des Telematikinfrastrukturbereiches, für die sie akkreditiert sind.Tabelle 15: Zone 2 - Zentral ExternSicherheitszoneBezeichnung Beschreibung Beispiel2 Zentral extern Kontrollierte Bereiche mit allenKomponenten, die für eine direkteKommunikation mit Komponenten inden externen Zonen benötigt werden.Sonstige Systeme undschützenswerte Daten müssen ausdiesen Zonen in eine dahinterliegende, stärker gesicherte Zonezurückgezogen werden.2.9 Zugangsnetzwerk Aktive oder passive Netzwerkkomponenten,über die eineVerbindung zu Zone 1 besteht.2.2 Öffentliche Dienste Dienste, die über Zone 1 erreichbarsein müssen, ohne dass eineAuthentifikation erforderlich istVPN-Gateway2.3 EingeschränkteDienste2.4 BenutzerindividuelleDiensteDienste, die über Zone 1 erreichbarsein müssen, für die aber zumindesteine Authentifikation einer in Zone 1platzierten Komponente erfolgtDienste, für die eine eindeutigeZuordnung zu einer Person möglichsein muss.internes DNS,internes NTP2.4.1 Externe Dienste Dienste, die aus Zone 1 erreichbarsein müssen und für die daher zusätzlicheine Authentifikation einer inZone 1 platzierten Komponenteerfolgen muss.Broker Service2.4.2 Interne Dienste Dienste, auf die nicht aus Zone 1zugegriffen werden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 96 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

7.4.3.3 Zone 3 - Zentral InternDie Zone 3 befindet sich innerhalb der Telematikinfrastruktur. Nur über Zone 2 autorisierteBenutzer, erhalten Zugang in die Zone 3. Es ist nicht möglich, direkt aus Zone 1 in Zone 3zu gelangen.Tabelle 16: Zone 3 - Zentral InternÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturSicherheitszoneBezeichnung Beschreibung Beispiel3 Zentral intern Gesicherte Bereiche für interneAufgaben. In dieser Zone befindensich Infrastrukturdienste, interne Server,Administratoren. Alle Übergängein und aus den internen Zonen stellenhohe Anforderungen an Sicherheitund Kontrolle. Die Zone 3 ist durchFirewalls sowohl vom internenNetzwerk, als auch von Zone 4getrennt und ein direkter Zugriff vonBenutzern auf diese Systeme undNetze ist nicht möglich.3.1 Anwendungsdienste3.5 InfrastrukturdiensteDiese Zone beherbergt Anwendungs-Server.Diese Zone steht für Dienstleistungenzur Verfügung, die von anderenKomponenten genutzt werdenmüssen.ADV, VfADNS, NTP, SDS3.6 SicherheitsdiensteIn dieser Zone befinden sichKomponenten die sicherheitsrelevantefachliche Protokollierungs- undAutorisierungsservices realisieren.OCSP, TSL,Trusted Service3.7 Administration In dieser Zone befinden sichKomponenten, mit denen dieTelematikinfrastruktur administriertwird. Dazu gehören Management-Server,sowie Systeme mit speziellenAnwendungen zur Administration derSysteme und -Anwendungen. DieseZone ist daher gegen unberechtigtenZugriff noch gesondert zu schützen.3.8 Monitoring In dieser Zone befinden sichKomponenten, mit denen dieTelematikinfrastruktur in Zone 2 und 3überwacht wird. Die Komponenten inZone 3.8, die Daten aufzeichnen,SOLLEN von den Komponenten, diein die Zone 2 und 3 hinein wirken(Probe Generatoren) innerhalb derZone 3.8 getrennt werden. Dies kanndurch Einführung zusätzlicherSoftwareverteilungundAdministrationskomponentengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 97 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Bezeichnung Beschreibung BeispielSubzonen (3.8.1 und 3.8.2)geschehen.7.4.3.4 Zone 4 - Zentral Backend InternDie Zone 4 befindet sich ebenfalls innerhalb der Telematikinfrastruktur. Nur autorisierteBenutzer, die von bestimmten Zonen ausgehen, erhalten Zugang in die Zone 4. Es istnicht zulässig, direkt aus Zone 1 in Zone 4 zu gelangen, aber es ist zulässig, aus Zone 2und Zone 3 in Zone 4 zu gelangen. Wenn die Zonen geographisch von einander getrenntsind, muss dieser Zugriff über ein gesichertes und transparentes Netz erfolgen.Tabelle 17: Zone 4 - Zentral Backend InternÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturSicherheitszoneSicherheitszoneBezeichnung Beschreibung Beispiel4 Zentral BackendIntern4.1 Anwendungsdienste4.5 Infrastrukturdienste4.6 Sicherheitsdienste4.7 AdministrationsdiensteGesicherte Bereiche für interneAufgaben. In dieser Zone befindensich Backendsysteme mit kritischenDaten, interne Server,Administratoren. Alle Übergänge inund aus den internen Zonen stellenhohe Anforderungen an Sicherheitund Kontrolle. Die Zone ist vonZone 1 nur über den Broker alsApplication Gateway erreichbar.Sie liegt innerhalb des internenZugangsrouters zum Backbone derTelematikinfrastruktur gegenüberSystemen von Kostenträgern.Diese Zone beherbergtAnwendungsserver.Diese Zone stelltsicherheitsrelevanteDienstleistungen undDatenspeicher zur Verfügung.In dieser Zone befinden sichKomponenten diesicherheitsrelevante interneProtokollierungs- und Autorisierungsservicesrealisieren.In dieser Zone sindAdministrationsdienste mitbesonders hohem Schutzbedarfplatziert.UFS, CAMS, AMDOK,NFDM, VODM, VSDMNTPAuthentisierung,ServiceTicket,ObjektTicket,Datenerhalt,UmschlüsselnZentrale Support-Dienste für Belangeder Telematikinfrastruktur.DieserSupport ist vom 1st-Level Support fürVersicherte oderLeistungserbringer zugematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 98 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturSicherheitszoneBezeichnung Beschreibung Beispielunterscheiden. Ausderen Sicht wäre der1st-Level Support derTelematikinfrastrukturein 2nd- oder 3rd-Level-Support.4.8 MonitoringDiensteIn dieser Zone befinden sichKomponenten, mit denen dieTelematikinfrastruktur in Zone 4überwacht wird. Die Komponentenin Zone 4.8, die Daten aufzeichnen,SOLLEN von den Komponenten,die in die Zone 4 hinein wirken(Probe Generatoren) innerhalb derZone 4.8 getrennt werden. Dieskann durch Einführung zusätzlicherSubzonen (4.8.1 und 4.8.2)geschehen.7.4.3.5 Zone 5 - Dezentral Backend ExternBei Zone 5 handelt es sich um dezentrale Systeme mit gespeicherten Datenbeständen inder Verantwortung von Institutionen (z. B. Kostenträger). Diese Datenbestände undSysteme existieren zum überwiegenden Teil bereits heute, und unterliegen einerentsprechenden gesetzlichen Regelung. An der Verantwortung für den Schutz dieserDatenbestände bzw. der entsprechenden System tritt durch die Einführung der Telematikinfrastrukturkeine Veränderung ein. Die Zone 5 befindet sich außerhalb der von dergematik verantworteten Telematikinfrastruktur. Mehrwertdienste können aus Zone 6 aufZone 5 zugreifen. Ein Informationsfluss von Zone 4 nach Zone 5 ist nicht zulässig. Wenndie Zonen geographisch von einander getrennt sind, muss dieser Zugriff durch durch eingesichertes und transparentes Netz realisiert werden.Tabelle 18: Zone 5 - Dezentral Backend ExternSicherheitszoneBezeichnung Beschreibung Beispiel5 DezentralBackend ExternSysteme, die sich außerhalb desinternen Zugangsrouters zum Backboneder Telematikinfrastrukturbefinden (z. B. Backend-Systeme vonLeistungsträgern mit den originärenPatientendaten). Anforderungen andezentrale Backendsysteme werdenvon der gematik nur rudimentär formuliert.Primär liegen diese Systemeim Verantwortungsbereich des jeweiligenUnternehmens (z. B.Kostenträger).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 99 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

7.4.3.6 Zone 6 - MehrwertdiensteDie Zone 6 ist über eine Firewall und eventuelles Netzwerk mit der Telematikinfrastrukturverbunden. Sie befindet sich nicht innerhalb der von der gematik verantwortetenTelematikinfrastruktur. Die Zone 6 hat damit keine Kommunikationsmöglichkeit mit denZonen 3 und 4.Tabelle 19: Zone 6 - MehrwertdiensteÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturSicherheitszoneBezeichnungBeschreibung6 Mehrwertdienste In dieser Zone befinden sich alle jene Komponenten, dieüber Standarddienste (Freiwillige- und Pflichtanwendungennach §291a) hinausgehen.6.x.16.x.2ExterneMehrwertdiensteInterneMehrwertdiensteMehrwertdienste, die direkt aus der Zone 1 (DezentralFrontend Extern) erreichbar sein müssen.Mehrwertdienste, die nur über die Zone 2 (Zentral Extern)erreichbar sind.7.4.4 Sicherheitsanforderungen an ZonenNachfolgend werden die Eigenschaften der Zonen sowie die Sicherheitsanforderungen andiese Zonen formuliert.Allgemein gilt, dass alle Anforderungen der hierarchisch übergeordneten Zone uneingeschränktauch für alle Subzonen gelten, wenn keine modifizierenden (einschränkenden,ausweitenden oder ergänzenden) Anforderungen formuliert sind.7.4.4.1 NummerierungDie Nummerierung der Sicherheitsanforderungen folgt dem Schema derAnforderungsnummerierung des Sicherheitskonzeptes (ID-RE-nnnn) mit folgendenErgänzungen:RE wird im Zonenkonzept nach folgendem Schema gebildet:ZTxwobei der Buchstabe „Z“ das „Zonenkonzept“ repräsentiert, der Buchstabe „T“ das Wort„Topologie-Eigenschaft“ und der Buchstabe x entweder „e“ (für extern), „i“ (für intern), „z“(für zentral) und „d“ (für dezentral)Znnnnwobei der Buchstabe „Z“ das Wort „Zonenkonzept“ repräsentiert und „nnnn“ dieZonennummer. Die Stelle in der Zonennummer repräsentiert die Hierarchiestufebeginnend mit der höchsten Hierarchiestufe in der Leserichtung von links nach rechts.Existieren für eine Zone keine Subzonen wird an der entsprechenden Stelle als Nummerdie Ziffer „0“ verwendet (z. B. für Zone 1 ist die Zonennummer Z1000, für die Zone 3.2Z3200).Zuvvvvnnnnwobei der Buchstabe „Z“ das Wort „Zonenkonzept“ repräsentiert, der Buchstabe „u“ dasWort „Übergang“ (Anm: zur Vermeidung von Sonderzeichen in Identifikatoren wurde „u“gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 100 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturstatt „ü“ verwendet) und „vvvv“ die Zonennummer der Quellzone und „nnnn“ dieZonennummer der Zielzone. (z. B. für Zonenübergang 1 auf Zone 2 ist die NummerierungZu10002000)Beispiele für vollständige Identifikatoren von Sicherheitsanforderungen im Zonenkonzeptsind:AS-ZTe-0001 - Eine allgemeine Sicherheitsanforderung für den Zonentyp „extern“AS-Z1000-0001 - Eine allgemeine Sicherheitsanforderung für Zone 1TAS-Z1400-0001 - Eine technische Sicherheitsanforderung für Zone 1.47.4.4.2 Allgemeine Sicherheitsanforderungen an Topologie-EigenschaftenFür die Topologie-Eigenschaften von Zonentypen gelten nachfolgende beschriebene,allgemeine Sicherheitsvorschriften.7.4.4.2.1 Topologie-Eigenschaft – ExternAS-ZTe-0001Protection Profiles für Komponenten zur Verarbeitung vonunverschlüsselten personenbezogener DatenUnverschlüsselte personenbezogene Daten MÜSSEN von Komponentenverarbeitet werden, deren Vertrauenswürdigkeit mittels einer auf einemgültigen Protection Profile basierenden Zertifizierung dokumentiert wurde,wenn die Komponente in die Regelungshoheit der gematik fällt.Davon kann nur abgewichen werden, wenn die Daten durch dieKomponente und die spezifische Einsatz- und Betriebsumgebung (Siehez.B. Anhang G bezüglich der Mindestanforderungen) geschützt werdenund der Dienstbetreiber die Verantwortung für den adäquaten Schutz unddie verbleibenden Restrisiken trägt.AS-ZTe-0002Protection Profiles für Komponenten zur Verarbeitung vonInformationsobjekten mit sehr hohem SchutzbedarfInformationsobjekte mit sehr hohem Schutzbedarf MÜSSEN vonKomponenten verarbeitet werden, deren Vertrauenswürdigkeit mittelseiner auf einem gültigen Protection Profile basierenden Zertifizierungdokumentiert wurde, wenn die Komponente in die Regelungshoheit dergematik fällt.Davon kann nur abgewichen werden, wenn die Daten durch dieKomponente und die spezifische Einsatz- und Betriebsumgebung (Siehez.B. Anhang G bezüglich der Mindestanforderungen) geschützt werdenund der Dienstbetreiber die Verantwortung für den adäquaten Schutz unddie verbleibenden Restrisiken trägt.AS-ZTe-0003Eigenverantwortlichkeit externer Kommunikationspartnergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 101 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturJeder externe Teilnehmer an der Telematikinfrastruktur ist für den Schutzvor sicherheitsrelevanten Zugriffen aus der Telematikinfrastruktur auf dievon ihm verantworteten Komponenten verantwortlich.Dies bedeutet, dass für den Schutz vor technisch schädlichen Inhalten,deren Ursprung in anderen externen Systemen liegt (auch wenn dieseInhalte über die Telematikinfrastruktur transportiert wurden) eindeutig derfür externe Komponenten Zuständige entsprechende Maßnahmen treffenMUSS.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 102 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4.4.2.2 Topologie-Eigenschaft – InternAS-ZTi-0001Protection Profiles für Komponenten zur Verarbeitung vonunverschlüsselten personenbezogenen DatenUnverschlüsselte personenbezogene Daten mit einem Schutzbedarf derVertraulichkeit von hoch und sehr hoch MÜSSEN von einer Komponenteverarbeitet werden, deren Vertrauenswürdigkeit mittels einer auf einemgültigen Protection Profile basierenden Zertifizierung dokumentiert wurde.Davon kann nur abgewichen werden, wenn die Daten durch die Komponenteund die spezifische Einsatz- und Betriebsumgebung (Siehe z.B. Anhang Gbezüglich der Mindestanforderungen) geschützt werden und derDienstbetreiber die Verantwortung für den adäquaten Schutz und dieverbleibenden Restrisiken trägt.AS-ZTi-0002Direkter Zugriff durch AnwenderDie Möglichkeit eines direkten Zugriffs auf ein internes System MUSS aufinterne Anwender beschränkt werden.AS-ZTi-0003Indirekter Zugriff durch Anwender über dokumentiertvertrauenswürdige KomponentenDie Möglichkeit eines indirekten Zugriffs auf ein internes System KANNeinem externen Anwender gegeben werden, wenn er über Komponentenerfolgt, deren Vertrauenswürdigkeit mittels einer auf einem gültigen ProtectionProfile basierenden Zertifizierung dokumentiert wurde.7.4.4.2.3 Topologie-Eigenschaft – DezentralFür diese Topologie-Eigenschaft existieren aus Sicht der gematik keine besonderenSicherheitsanforderungen.7.4.4.2.4 Topologie-Eigenschaft – ZentralAS-ZTz-0001Sehr hohe VerfügbarkeitZentrale Komponenten SOLLEN generell einen Schutzbedarf von SEHRHOCH hinsichtlich ihrer Verfügbarkeit erfüllen.AS-ZTz-0002Keine unverschlüsselte Speicherung und Übertragung vonpersonenbezogener Datengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 103 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPersonenbezogene Daten mit einem Schutzbedarf der Vertraulichkeit vonhoch und sehr hoch DÜRFEN in einer zentralen Zone NICHT unverschlüsseltgespeichert oder übertragen werden.7.4.4.3 Detaillierte Sicherheitsanforderungen an ZonenFür jede Zone gelten spezifische Sicherheitsanforderungen, welche die sicherheitstechnischeQualität („Vertrauenswürdigkeit“) der jeweiligen Zone definieren.Diese Sicherheitsanforderungen sind für jede Zone zusammengefasst.7.4.4.3.1 Zone 1 – Dezentral Frontend ExternTelematik-Komponenten in dieser Zone sind insbesondere: Konnektor, Kartenterminal,HBA / eGK / SMC-B, SM-NK und SM-AK, sowie die Systeme des Leistungserbringers wiePVS, KIS und AVS.AS-Z1000-0001Verantwortung für Vertrauenswürdigkeit von Komponenten zurVerarbeitung unverschlüsselter personenbezogener DatenAufgrund des allgemein nicht garantierbaren Sicherheitsniveaus in dieserZone MUSS die Verantwortung für die Vertrauenswürdigkeit von Komponenten,die unverschlüsselte personenbezogene Daten verarbeiten, eindeutiggeregelt werden.AS-Z1000-0002Erkennbarkeit von Manipulationen an Telematik-KomponentenKomponenten, deren vertrauenswürdige Ausgestaltung in der Verantwortungder gematik liegt, MÜSSEN derart gestaltet sein, dass Manipulationenerkennbar sind.AS-Z1000-0003Manipulationssicherheit von Telematik-KomponentenTelematik-Komponenten SOLLEN derart gestaltet sein, dass Manipulationenzur Abschaltung der Komponente führen.AS-Z1000-0004Nachweis der Vertrauenswürdigkeit von Telematik-KomponentenDie Vertrauenswürdigkeit einer Telematik-Komponente MUSS nachgewiesenwerden. Der Nachweis SOLL auf einer Zertifizierung nach einem ProtectionProfile basieren.AS-Z1000-0005Schutz der Kommunikation zwischen Telematik-KomponentenDie Kommunikation zwischen Telematik-Komponenten MUSS einen demSchutzbedarf der übertragenen Informationsobjekte angemessenen Schutzvor Integritäts- und Vertraulichkeitsverletzungen bieten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 104 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAS-Z1000-0006Prüfung der auf Telematik-Komponenten ausgeführten DiensteDie Authentizität und Integrität eines Dienstes, der auf einer Telematik-Komponente ausgeführt wird und unverschlüsselte personenbezogene Datenverarbeitet MÜSSEN vor dessen Ausführung geprüft werden.AS-Z1000-0007Schutz vor Angriffen über das NetzwerkAlle Telematik-Komponenten MÜSSEN vor Angriffen über ein Netzwerkentsprechend dem Schutzbedarf der von der Komponenten verarbeitetenDatenobjekte geschützt werden.AS-Z1000-0008Überprüfung der Authentizität anderer Telematik-KomponentenAlle Telematik-Komponenten SOLLEN nur Kommunikationsbeziehungen zuanderen Telematik-Komponenten unterhalten, deren Authentizität beimKommunikationsaufbau kryptografisch beweisbar ist.7.4.4.3.2 Zone 1.1 DiensteAS-Z1100-0001Prüfung der Dienste auf Authentizität und IntegritätAlle Telematik assoziierten Dienste SOLLEN vor der Ausführung auf derenAuthentizität und Integrität überprüft werden.7.4.4.3.3 Zone 1.9 NetzwerkAS-Z1900-0001Verbindungen von Telematik assoziierte Netzen zu anderen NetzenTelematik assoziierte Netze SOLLEN keine direkten Verbindungen insInternet oder zu anderen nicht mit der Telematik assoziierten Netzenbesitzen. Davon ausgenommen ist die Verbindung des Netzkonnektors überdas Internet zum Telematikzugangsprovider.7.4.4.3.4 Zone 2 Zentral extern („Service Zone“)AS-Z2000-0001Platzierung aller Komponenten in einem Bereich mit ausreichendemphysischen SchutzAlle Komponenten MÜSSEN in einem Bereich („Sicherheitsbereich“) platziertsein, der einen ausreichenden physischen Schutz vor böswilliger und zufälligerManipulation/Betriebsstörung bietet.AS-Z2000-0002Schutz der Komponenten vor Angriffen über Netzwerkegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 105 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAlle Komponenten SOLLEN sich selbst („Host based Firewalls“) vor Angriffenüber das Netzwerk (intern oder extern) schützen, oder adäquat gehärtet sein.7.4.4.3.5 Zone 2.3 Eingeschränkte DiensteAS-Z2300-0001Rückführbarkeit des Zugriffs auf Komponenten dieser Zone aus Zone 1Jeder Zugriff auf Komponenten dieser Zone aus Zone 1 MUSS auf einejuristische Person rückführbar sein.7.4.4.3.6 Zone 2.4 Benutzerindividuelle DiensteAS-Z2400-0001Rückführbarkeit des Zugriffs auf Komponenten dieser Zone aus Zone 1auf nat. PersonenJeder Zugriff auf Komponenten dieser Zone aus Zone 1 SOLL auf einenatürliche Person rückführbar sein.AS-Z2400-0002Rückführbarkeit des Zugriffs auf Komponenten dieser Zone aus Zone 1auf jur. PersonenJeder Zugriff auf Komponenten dieser Zone aus Zone 1 MUSS auf einejuristische Person (z. B. registrierter Besitzer eines Konnektors) rückführbarsein.AS-Z2400-0003Trennung der AdministrationDie Komponenten MÜSSEN von anderen Personen administriert werden, alsdie Komponenten in den Zonen 2.2 und 2.97.4.4.3.7 Zone 2.4.1 Externe DiensteAS-Z2410-0001Rückführbarkeit des Zugriffs auf Komponenten dieser Zone aus Zone 1auf nat. PersonenJeder Zugriff auf Komponenten dieser Zone aus Zone 1 SOLL auf einenatürliche Person rückführbar sein.7.4.4.3.8 Zone 2.4.2 Interne DiensteAS-Z2420-0001Rückführbarkeit des Zugriffs auf Komponenten dieser Zone aus Zone 1auf nat. PersonenJeder Zugriff auf Komponenten dieser Zone MUSS auf eine natürlichePerson rückführbar sein.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 106 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4.4.3.9 Zone 3 Zentral intern („Support Zone“)Keine besonderen Anforderungen.7.4.4.3.10 Zone 3.6 SicherheitsdiensteAS-Z3600-0001Trennung der AdministrationDie Komponenten MÜSSEN von anderen Personen administriert werden, alsdie Komponenten in den Zonen 2 und 3.7.4.4.3.11 Zone 3.7 AdministrationsdiensteAS-Z3700-0001Trennung der AdministrationDie Komponenten MÜSSEN von anderen Personen administriert werden, alsdie Komponenten in den Zonen 2 und 3.7.4.4.3.12 Zone 3.8 Monitoring DiensteAS-Z3800-0001Trennung der AdministrationDie Komponenten MÜSSEN von anderen Personen administriert werden, alsdie Komponenten in den Zonen 2 und 3.7.4.4.3.13 Zone 4 Zentral Backend internKeine besonderen Anforderungen.7.4.4.3.14 Zone 4.7 AdministrationsdiensteAS-Z4700-0001Trennung der AdministrationDie Komponenten MÜSSEN von anderen Personen administriert werden, alsdie Komponenten in der Zone 4.7.4.4.3.15 Zone 4.6 SicherheitsdiensteAS-Z4500-0001Trennung der AdministrationDie Komponenten MÜSSEN von anderen Personen administriert werden, alsdie Komponenten in der Zone 47.4.4.3.16 Zone 5 Dezentral Backend externAS-Z5000-0001Trennung der AdministrationDie Komponenten MÜSSEN von anderen Personen administriert werden, alsdie Komponenten in den Zonen 2, 3 und 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 107 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4.4.3.17 Zone 6 MehrwertdiensteKeine besonderen Anforderungen.7.4.4.4 Erlaubte und verbotene ZonenübergängeIm Rahmen des definierten Zonenkonzepts sind Verbindungen zwischen Komponentenverschiedener Zonen nur unter Erfüllung hier definierter Voraussetzungen zulässig.Darüber hinaus sind einige Zonenübergänge gar nicht zulässig.Allgemein erfolgt die Formulierung der Zonenübergänge in zwei Teilen:• Zunächst werden die erlaubten Zonenübergänge dargestellt• dann werden die Sicherheitsanforderungen an die erlaubten Zonenübergängeaufgelistet.Nachfolgend sind die generell möglichen Zonenübergänge der Top-Level Zonen durchPfeile gekennzeichnet. Die Pfeile bezeichnen die Richtung, in die ein Informationsflussstatthaft ist. Ein Kontrollfluss (z.B. Verbindungsaufbau) ist grundsätzlich auch gegen dieRichtung des zugelassenen Informationsflusses zulässig. Im Folgenden werden dieseÜbergänge dann teilweise noch weiter eingeschränkt, indem dieKommunikationsbeziehungen zu Subzonen betrachtet werden.Abbildung 16: Erlaubte Übergänge zwischen Top-Level Zonen7.4.4.5 Sicherheitsanforderungen ZonenübergängeFür folgende Top-Level Zonenübergänge sind aus Sicht der Telematikinfrastruktur keineabschließenden Sicherheitsanforderungen definiert:Tabelle 20: Top-Level Zonenübergänge ohne SicherheitsanforderungenZonenübergangBeschreibungZonenübergängeauf Zone 5Bei Zone 5 handelt es sich um dezentrale Systeme mit gespeichertenDatenbeständen in der Verantwortung von Institutionen(z. B. Kostenträger). Diese Datenbestände undSysteme existieren zum überwiegenden Teil bereits heute, undunterliegen einer entsprechenden gesetzlichen Regelung. An derVerantwortung für den Schutz dieser Datenbestände bzw. derentsprechenden System tritt durch die Einführung der Telematik-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 108 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZonenübergangBeschreibunginfrastruktur keine Veränderung ein.Hinweis: Der Informationsfluss von Zone 4 nach Zone 5 unterliegtinsbesondere den Regelungen des SGB V. Um die Erfüllung derdiesbezüglichen gesetzlichen Vorgaben sicher zu stellen müssendie Datentypen, die aus Zone 4 nach Zone 5 übertragen werden,gelistet und erläutert werden.Im Sicherheitskonzept des Betreibers der Fachdienste MUSS dieWirksamkeit der Maßnahmen gezeigt werden, mit denensichergestellt wird, dass die Daten der Fachdienste nur imRahmen der Zweckbestimmung des §291a verwendet und nichtüber den Zonenübergang in Zone 5 in die existierenden IT-Systemen übertragen und weiterverarbeitet werden können.Zonenübergängeauf Zone 6Zone 6 beinhaltet Mehrwertdienste, die von unabhängigen Anbieternkonzipiert und auch entsprechend extern betriebenwerden. Auch wenn für Mehrwertdienste im konkreten Fallgesetzliche Regelungen für den Umgang mit Gesundheitsdatenrelevanten Inhalten existieren, erfolgt deren Umsetzung nicht imRahmen der von der gematik verantwortetenTelematikinfrastruktur. Die Verantwortung für Schutzmaßnahmenliegt ausschließlich beim Anbieter des Mehrwertdienstes.Die nachfolgende Tabelle zeigt die Anforderungen an alle Zonenübergänge einschließlichder Subzonen:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 109 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 21: Anforderungen an die Zonenübergängezu1.xZone 1Zone 2Zone 31.92.92.22.33.13.53.6vonZone 1 1.x 2M,RM,PeM,PvS 2M,RM,PeM,PvS 3M,4S,RM,PeM,PvS 3M,4S,RM,PeM,PvS1.9 2M,RM,PeM,PvS 2M,RM,PeM,PvS 3M,4S,RM,PeM,PvS 3M,4S,RM,PeM,PvSZone 2 2.9 1M,2S 1M,2S 1M,2S 1M,2S 2M,PeS,PvM 2M,PeS,PvM 2M,PeS,PvM2.2 1M,2S 1M,2S 1M,2S 1M,2S 2M,PeS,PvM 2M,PeS,PvM 2M,PeS,PvM2.3 1M,2S 1M,2S 1M,2S 1M,2S 2M,PeS,PvM 2M,PeS,PvM 2M,PeS,PvM2.4.1 1M,2S 1M,2S 1M,2S 1M,2S 2M,PeS,PvM 2M,PeS,PvM 2M,PeS,PvM2.4.2 1M,2S 1M,2S 1M,2S 1M,2S 2M,PeS,PvM 2M,PeS,PvM 2M,PeS,PvMZone 3 3.1 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S3.5 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S3.6 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S,PeM,PvM 1M,2S,PeM,PvM3.7 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM3.8 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvMZone 4 4.1 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S4.5 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S4.6 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S 1M,2S4.7 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM4.8Zone 5 1M,2S 1M,2S 1M,2S 1M,2S 1M,2SZone 6 6.1 1M,2S,RM 1M,2S,RM 1M,2S,RM 1M,2S,RM 1M,2S,RM6.2 1M,2S,RM 1M,2S,RM 1M,2S,RM 1M,2S,RM 1M,2S,RM2.4.12.4.2Übergang erlaubtVerantwortung liegt beim Betreiber, keine abschließenden expliziten Vorgaben durch die gematikÜbergang verbotennSRMPeMPvMNetzwerkschutz Stufe n SOLL umgesetzt werden (S = Soll, M = MUSS)Regelsatz (siehe [gematik_Inf_Netzerksicherheit]) MUSS der gematik gemeldet werden (R = Regelsatz)Erlaubte Verbindungsaufbauten MÜSSEN mit Start- und Zieladresse protokolliert werden (P = Protokollieren, e = erlaubt))Der Versuch verbotener Verbindungsaufbaus MUSS mit Start- und Zieladresse protokolliert werden (v = verboten)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 110 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturFortsetzung der Tabelle:zuZone 4Zone 5Zone 63.73.84.14.5vonZone 1 1.x1.9Zone 2 2.9 2M,PeS,PvM 2M,4S 2M,4S2.2 2M,PeS,PvM 2M,3S,PeM,PvM 2M,3S,PeM,PvM 2M,PeM,PvM 2M,PeM,PvM 2M,4S2.3 2M,3S,PeS,PvM 2M,3S,PeM,PvM 2M,3S,PeM,PvM 2M,PeM,PvM 2M,PeM,PvM 2M,4S2.4.1 2M,PeS,PvM 2M,3S,PeM,PvM 2M,3S,PeM,PvM 2M,PeM,PvM 2M,PeM,PvM 2M,4S2.4.2 2M,PeS,PvM 2M,3S,PeM,PvM 2M,3S,PeM,PvM 3M,PeM,PvM 2M,PeM,PvM 2M,4SZone 3 3.1 1M,2S 2M,PeM,PvM 2M,PeM,PvM 2M,PeM,PvM 2M,PeM,PvM3.5 1M,2S 2M,PeM,PvM 2M,PeM,PvM 2M,PeM,PvM 2M,PeM,PvM3.6 1M,2S 3M,PeM,PvM 2M,PeM,PvM 3M,PeM,PvM 2M,PeM,PvM3.7 1M,2S,PeM,PvM3.8 1M,2S,PeM,PvM 2M,PeM,PvMZone 4 4.1 1M,2S 1M,2S 1M,2S 1M,2S4.5 1M,2S 1M,2S 1M,2S 1M,2S4.6 1M,2S 1M,2S 1M,2S 1M,2S4.7 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM4.8 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvM 1M,2S,PeM,PvMZone 5 2M,3S,PeM,PvM 2M,4SZone 6 6.1 1M,2S6.24.64.74.86.16.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 111 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie nachfolgenden Anforderungen gelten für alle Zonenübergänge.AS-Zu-0001Trennung der Administration von Zonen und ZonenübergängenDie Administration eines Zonenüberganges SOLL von einer anderenRolle administriert werden als die Komponenten innerhalb der Quell-/Zielzonen. Im Rahmen einer „Separation of Duties“ - Strategie sollenKomponenten zur Kontrolle von Zonenübergängen von anderen Rollenadministriert werden, als die Komponenten in den Quell-/Zielzonen.AS-Zu-0002Verwendung minimaler RegelsätzeDie Regelsätze (für Firewalls etc.) MÜSSEN derart gestaltet sein,dass ausschließlich die unbedingt zur Diensterbringung benötigtenVerbindungen möglich sind. Diese umfassen auch Verbindungen derAdministrationsdienste und Monitoring-Dienste.AS-Zu-0003Protokollierung von AngriffenAlle erkannten Angriffe MÜSSEN protokolliert werden.AS-Zu-0004Protokollierung ohne Überlastung der Kernaufgabe einerKomponenteDie Protokollierung MUSS so umgesetzt sein, dass der Service-Levelder Kernaufgabe einer Komponente (z. B. Annahme von VPN-Verbindungen)trotz der zu protokollierender Datenpakete/Verbindungsinformationen eingehalten werden kann.AS-Zu-0005Festlegung von verhindernden Maßnahmen für alle im Rahmendes Zonenkonzepts nicht erlaubten ÜbergängeFür alle im Rahmen des Zonenkonzepts nicht erlaubten ÜbergängeMÜSSEN physische, organisatorische oder technische Maßnahmenfestgelegt werden, die diesen Übergang nicht möglich machen. Bestehtz. B. physisch keine Verbindung zwischen zwei Zonen, so sindorganisatorische Maßnahmen festzulegen, die diesen Zustand überdie Lebenszeit des Systems aufrechterhalten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 112 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.4.4.6 Zuordnung von Komponenten der Gesamtarchitektur zu ZonenDie im Komponentenmodell der Gesamtarchitektur modellierten Detailkomponenten obigerKomponenten-/Servicetypen werden wie folgt den Sicherheitszonen und Sicherheitsbereichenzugeordnet.In der nachfolgenden Abbildung 17 sind die logischen Komponenten derGesamtarchitektur (siehe Kapitel 5) den in diesem Kapitel definierten Sicherheitszonenenzugeordnet.ServiceConsumerTierTelematik TierdezentralTelematik TierzentralService ProviderTierHBA1.4 ZutrittbeschränkteGKKTeKioskZone 1:Dezentral externeGKKT1.3 überwachtAVSPVSKISTrustedViewereGK HBAKT1.9 LAN1.1 DiensteVPN-Gateway1.1.1:AnwendungsDiensteConnectorServiceIBrokerService1.1.4: SicherheitsDiensteTVSSAKKTS1.1.3 BasisdiensteKTeKioskeGKVPN-GatewayTicket-ServiceSMC-B1.1.9:WANAuthentisierungDNSexternZone 2.9 Zone 2.2:ZugangsnetzwerkÖffentlicheDiensteZone 6.1: Externe MehrwertdiensteZone 2.3: ÉingeschränkteDiensteNTPStratum 2DNSinternBrokerAppl. ProxyOCSP,CRLProxyMehrwertdiensteZone 3.7: AdministrationZone 3.5: InfrastrukturdiensteDNS NTP SDSroot Stratum 1Zone 2.4: BenutzerindividuelleDienste2.4.2 Interne Dienste2.4.1 Externe DiensteBrokerServiceTrustedSVSServiceSCSAuditSInfrastrukturPKI ServicesOCSP, CRL, TSLZone 3.6: Sicherheitsdienste IZone 6.2: Interne Mehrwertdienste3.1 AnwendungsdiensteMPLS BackboneZone 3.8:Monitoring4.7: Administration4.5: InfrastrukturdiensteNTPStratum 24.1: AnwendungsdiensteUFSUFS-Ser.CAMSCAMS-Ser.AMTSAMTS-Ser.NFDMNFDM-ServVODMVODM-ServVSDMVSDM-Ser.eGKPKI-DiensteOCSPldapAutor.Service-,Objekt-TicketDatenerhaltUmschlüsseln4.6: SicherheitsdiensteZone 4.8MonitoringZone 5. Legacy und existing application TierAbbildung 17: Zuordnung der Komponenten zu Sicherheitszonen.In der nachfolgenden Tabelle bedeutet eine in der Spalte „Komponenten“ angeführte Detailkomponenteentweder• eine physische Entität im Sinne von „Server der den Dienst anbietet“ (z. B. derBroker), wenn dieser Zusammenhang eindeutig herstellbar ist oder• einen „Datenspeicher eines Service“.(z. B. zentrale Datenablage des LoggingundTracing-Service), wenn dieser Service zwar über verschiedene Tiers dezentralisiertist, aber die Ergebnisdaten des Service tendenziell zentralisiert ineiner Datenbank gespeichert werden oder• als Oberbegriff für alle Services eines Themenkomplexes, falls eine höhereGranularität in Bezug auf Sicherheitsanforderungen im Rahmen eines eigenenKonzeptes abgedeckt wird (z. B. CMS).Tabelle 22: Normative Zuordnung der Komponenten zu Sicherheitszonengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 113 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZoneKomponenteDezentral extern1. dezentral extern: IT-Systeme des Leistungserbringerso Primärsysteme: PVS, AVS, KISo Kartenterminals, Trusted Viewer,o eKiosk UmgebungenHinweis: Diese Zone ist in der Hoheit der Leistungserbringer und es gibt keineRegelungen der gematik für diesen Bereich. Entsprechend den Umgebungsanforderungenfür die von der gematik zuzulassenden dezentralen Komponenten –z. B. für die Kartenterminals – ist diese Zone in die nachfolgenden Zonen 1.nunterteilt.1.2 öffentlich zugängliche Umgebung beim Leistungserbringero eKiosk Umgebung (z. B. Selbstbedienungs-Terminal)1.3 überwachte Umgebung beim Leistungserbringero Primärsysteme: PVS, AVS, KISo Kartenterminals, Trusted Viewero eKiosk-Umgebung (z. B. PC-Terminal)1.4 zutrittsbeschränkte Umgebung beim Leistungserbringero Primärsysteme: PVS, AVS, KISo Kartenterminals, Primärsysteme, Trusted Viewer1.9 Netzwerko LAN des Leistungserbringers1.1 Dienste der Telematikinfrastruktur:o KonnektorHinweis: entsprechend den Umgebungsbedingungen ist der Konnektor in dienachfolgenden Zonen 1.1.n unterteilt.1.1.1 Anwendungsdiensteo Connectorservice, Brokerservice1.1.3 Basisdiensteo KTS, Kartenterminalservice1.1.4 Sicherheitsdiensteo Trusted Viewer Service (TVS), SAK, Ticketservice1.1.9 Netzwerk (WAN)o WANZentral extern2.9 Zugangsnetzwerko Netzwerkkomponenten2.2 Öffentliche Diensteo Externes DNS, VPN Gatewayo VPN Gateway für Mehrwertdienste2.3 Eingeschränkte Dienstegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 114 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZoneKomponenteo Broker Appl. Proxyo OCSP Respondero CRL Validation, CRL Provider Proxy und CRL Provider Basisdiensto internes DNS, NTP2.4 Benutzerindividuelle Dienste2.4.1 Externe Diensteo Broker Server2.4.2 Interne DiensteZentral intern3.1 Anwendungsdiensteo ADV, VfA3.5 Infrastrukturdiensteo DNS (root), NTP (Stratum 1), SDS3.6 Sicherheitsdiensteo Trusted Service, SVS, SCSo AuditSo OCSP, TSL, TCL3.7 Administrationo Broker Administration3.8 Monitoringo Systemmonitoringo Service Monitoring (Broker, Audit, DNS etc.)4 Zentral Backend intern4.1 Anwendungsdiensteo UFS, CAMS,o VODM,VSDMo AMTS, NFDM,4.5 Infrastrukturdiensteo NTP4.6 Sicherheitsdiensteo Authentisierungsserviceo Autorisierungsservice mit Ticketserviceo Datenerhalt - Umschlüsseln4.7 Administrationsdiensteo Administrationskomponenteno Treuhänder für Datenerhaltgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 115 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZoneKomponente4.8 Monitoring Diensteo Monitoring Komponenten der Fachdienste, CAMS5 Dezentral Backend intern5 Existierende Stammdatensysteme der Kostenträger6 Mehrwertdienste6.1 - bisher keine Mehrwertdienste definiert -6.2 - bisher keine Mehrwertdienste definiert -Die Anforderungen der §291a-Anwendungen an die Gesamtarchitektur können durch Request/Response-Musterabgedeckt werden. Die in [gemGesArch] beschriebenen Diensteunterstützen deshalb gemäß Annahme AnN-GA-0010 zunächst Request/Response-Kommunikationsmuster. Zur Veranschaulichung der erlaubten Zonenübergänge (sieheKap. 7.4.4.4) sind in der nachfolgenden Abbildung für diese Interaktionsmuster die Informations-und Nachrichtenflüsse dargestellt.ServiceConsumerTierTelematik TierdezentralTelematik TierzentralService ProviderTierHBA1.4 ZutrittbeschränkteGKKTeKioskZone 1:Dezentral externeGKKT1.3 überwachtAVSPVSKISTrustedViewereGK HBAKT1.9 LAN1.1 DiensteVPN-Gateway1.1.1:AnwendungsDiensteConnectorServiceTVSSAKKTSIBrokerService1.1.4: SicherheitsDienste1.1.3 BasisdiensteKTeKioskeGKVPN-GatewayTicket-ServiceSMC-B1.1.9:WANAuthentisierungDNSexternZone 2.9 Zone 2.2:ZugangsnetzwerkÖffentlicheDiensteZone 6.1: Externe MehrwertdiensteZone 2.3: ÉingeschränkteDiensteNTPStratum 2DNSinternBrokerAppl. ProxyOCSP,CRLProxyMehrwertdiensteZone 3.7: AdministrationZone 3.5: InfrastrukturdiensteDNS NTP SDSroot Stratum 1Zone 2.4: BenutzerindividuelleDienste2.4.2 Interne Dienste2.4.1 Externe DiensteBrokerServiceTrustedSVSServiceSCSAuditSInfrastrukturPKI ServicesOCSP, CRL, TSLZone 3.6: Sicherheitsdienste IZone 6.2: Interne Mehrwertdienste3.1 AnwendungsdiensteMPLS BackboneZone 3.8:Monitoring4.7: Administration4.5: InfrastrukturdiensteNTPStratum 24.1: AnwendungsdiensteUFSUFS-Ser.CAMSCAMS-Ser.AMTSAMTS-Ser.NFDMNFDM-ServVODMVODM-ServVSDMVSDM-Ser.eGKPKI-DiensteOCSPldapAutor.Service-,Objekt-TicketDatenerhaltUmschlüsseln4.6: SicherheitsdiensteZone 4.8MonitoringZone 5. Legacy und existing application TierInformationsflussNachrichtenflussfür Request/Response KommunikationsmusterInformationsflussNachrichtenflussVerbindungsaufbaufür sekundäre Nutzung von DienstenAbbildung 18: Erlaubte Informations- und Nachrichtenflüsse für das Request/Response-Interaktionsmuster.Neben beispielhaften primären Informations- und Nachrichtenflüssen auf Anwendungsebene,ist noch der damit verbundene sekundäre Kontrollfluss über entsprechende Diens-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 116 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturte der Telematikinfrastruktur dargestellt. Insbesondere werden von den Sicherheitsdienstenfolgende Funktionen unterstützt• Konnektor: Zone 1.1.1 Anwendungsdienste Ł 1.1.4 SicherheitsdiensteErstellen und prüfen Signatur (sign, verify) des medizinischen Dokumentesbzw. der Nachricht, bzw. Verschlüsseln und Entschlüsseln (encrypt, decrypt)eines medizinischen Dokumentes. Dazu ist ein Zugriff auf die Schlüssel in denKarten (eGK, HBA/SMC) bzw. auf die OCSP Dienste zur Prüfung der Zertifikatsgültigkeitnotwendig.• BrokerService: Zone 2.4.1 externe Dienste Ł 3.4 SicherheitsdienstePrüfen und erstellen einer Nachrichtensignatur (verify, sign) zur Anonymisierungdes Leistungserbringerbezugs in der übertragenen Nachricht beim Zugriffauf bestimmte Dienste (z. B. VSDD, UFS). Dazu ist ein Zugriff auf die Schlüsselim SCS bzw. auf die OCSP Dienste zur Prüfung der Zertifikatsgültigkeitnotwendig.• Fachdienste: Zone 4.1 Anwendungsdienste Ł 4.4 SicherheitsdienstePrüfen der Nachrichtensignaturen (verify) zur Authentisierung des Leistungserbringersund des Versicherten zur Autorisierung (grant/deny) des Zugriffsauf den Fachdienst. Erstellen (sign) einer Nachrichtensignatur zur Authentisierungder Antwortnachricht. Dazu ist ein Zugriff auf die Schlüssel des Fachdienstesbzw. auf die OCSP Dienste zur Feststellung des Zertifikatsstatusnotwendig.7.5 BerechtigungsverwaltungTickets sind die technische Umsetzung und Lösung in der Telematikinfrastruktur zur Verwaltungvon Berechtigungen für Zugriffe von Leistungserbringern auf Daten des Versicherten.Es werden zwei Arten von Tickets unterschieden (siehe auch [gemGesArch]):• ServiceTicket: Ein ServiceTicket realisiert die Autorisierung eines Versichertenfür genau einen Leistungserbringer oder einen Vertreter zum Zugriff aufdie medizinischen Daten des Versicherten in genau einem Fachdienst.• ObjektTicket: Jedem medizinischen Objekt innerhalb eines Fachdienstes istgenau ein Objekt-Ticket zugeordnet. ObjektTickets enthalten die Entschlüsslungsinformationzum Zugriff auf die verschlüsselten medizinischen Daten unddie Rechte für berechtigte Leistungserbringer zum Zugriff auf das Objekt. Dievom Versicherten ausgestellten Rechte in ServiceTickets werden im ObjektTicketberücksichtigt und übernommen.Da eine gezielte Manipulation der in Tickets vergebenen Rechte einen unautorisiertenZugriff auf medizinische Patientendaten ermöglicht, unterliegen Tickets hohen Sicherheitsanforderungen.Tickets müssen wirksam vor unautorisierter Modifikation geschütztwerden, um die im §291a Abs. 5 SGB V geforderte Autorisierung durch den Versichertenfür jeden Zugriff zu gewährleisten.Im Einzelnen werden in diesem Abschnitt die folgenden Aspekte der Berechtigungsverwaltungnäher beschrieben:• Service- und ObjektTickets: Gibt eine kurze Einführung in diese Tickets.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 117 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Sicherheitsanforderungen und Schutzbedarf: Geben den Schutzbedarf vonTickets an und beschreiben die an Tickets gestellten Sicherheitsanforderungen.• Umgebungen des Versicherten: Beschreibt die Umgebungen und Schnittstellen,in bzw. mit denen Versicherte Zugriffsberechtigungen für ihre Daten(bzw. Tickets) verwalten können.• Strategie zur schrittweisen Einführung der Ticketverwaltung: Betrachteteine aus Sicherheitssicht motivierte schrittweise Einführung der für einen Versichertenbereitgestellten Möglichkeiten zur Berechtigungsverwaltung. Damitwird die Komplexität der Rechtevergabe für die Versicherten auf ein handhabbaresMaß reduziert und mögliche Restrisiken werden begrenzt.7.5.1 Service- und ObjektTickets zur Verwaltung von BerechtigungenDie medizinischen Informationen von Versicherten sind in der Telematikinfrastruktur inverschlüsselter Form in Datenobjekten enthalten. Hierzu wird für jedes medizinische Objektein eigener symmetrischer Schlüssel verwendet. Für jeden Zugriffsberechtigten wirddieser symmetrische Schlüssel mit dem öffentlichen Schlüssel des Zugriffsberechtigtenverschlüsselt. Danach kann ein Zugriffsberechtigter mit seinem privaten Schlüssel densymmetrischen Schlüssel des Datenobjekts ermitteln, um so an die medizinischen Informationenzu gelangen. Der mit einem öffentlichen Schlüssel verschlüsselte symmetrischeObjektschlüssel wird als Hybridschlüssel bezeichnet.Jedem Datenobjekt ist genau ein ObjektTicket zugeordnet, welches die Hybridschlüsselfür jeden Zugriffsberechtigten enthält und welches die Zugriffsberechtigungen der Berechtigtenauf das Objekt definiert.Mit ServiceTickets lässt sich ausdrücken, dass berechtigte Leistungserbringer für dieAusführung medizinischer Fachanwendungen zugelassen sind. In einem ServiceTicket füreinen Leistungserbringer werden dessen Zugriffsrechte für eine Fachanwendung definiert.ServiceTickets können pro Kombination aus Fachanwendung, Versichertem und berechtigtemLeistungserbringer angelegt werden. Das bedeutet, im Gegensatz zu ObjektTickets,bei denen ein ObjektTicket alle berechtigten Leistungserbringer eines Objektesenthält, muss der Versicherte für jede Fachanwendung und jeden berechtigten Leistungserbringerein separates ServiceTicket anlegen.Die Zuweisung der Zugriffsrechte eines berechtigten Leistungserbringers zu einem medizinischenDatenobjekt erfolgt durch Anwendung des ServiceTickets im ObjektTicket. ImObjektTicket werden die Informationen aus einem bestehenden ServiceTicket übernommenund so der berechtigte Leistungserbringer im Rahmen seiner definierten Zugriffsrechtefür das konkrete Datenobjekt autorisiert.Es werden zwei grundlegende Typen der Ticketverwendung unterschieden:• Zugriffsrechte- und Schlüsselverwaltung bezeichnet die aktive Veränderungvon Tickets durch den Versicherten oder einen Treuhänder zur Verwaltungder Zugriffsrechte oder Objektschlüssel (im Gegensatz zu Zugriffen aufmedizinische Datenobjekte). Hierzu zählen z. B. die in [gemGesArch] beschriebenenKommunikationsmuster „Berechtigungen für ein medizinischesObjekt anzeigen“ und „Berechtigungen für ein medizinisches Objekt anlegen“.Es handelt sich hierbei um alle Zugriffe, die ausschließlich der Anpassungvon Rechten oder Schlüsseln dienen und die bewusst aus einer Rechte- undSchlüsselverwaltungsanwendung initiiert werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 118 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Nutzung zur Zugriffskontrolle bezeichnet die Verwendung von Tickets zurAutorisierung von Zugriffen auf medizinische Daten und Fachdienste (im Gegensatzzu Zugriffen zur oben erwähnten Verwaltung von Tickets) oder dietransparente Vererbung von bereits in ServiceTickets definierten Rechten aufneu erstellte Objekte. Es handelt sich also hierbei um Zugriffe, deren primärerZweck sich auf das medizinische Objekt und nicht auf ein Ticket bezieht. Hierzuzählen z. B. die in [gemGesArch] beschriebenen Kommunikationsmuster„Lesender Zugriff auf ein medizinisches Datenobjekt“ und „Löschen eines e-xistierenden medizinischen Datenobjekts“.Der genaue Aufbau und die Verwendung von Objekt- und ServiceTickets sind in[gemSpec_Ticket] beschrieben.7.5.1.1 Benutzerbestimmte Informationsflusskontrolle auf dem FachdienstIn der Telematikinfrastruktur erfolgt die Autorisierung für den Zugriff auf einen Fachdienstzweistufig. In der ersten Stufe geschieht dies anhand der Rollen des zugreifenden Subjekts,wobei rollenbasierte Zugriffsregeln die rechtlich vorgeschriebenen Regeln abbilden.In der zweiten Stufe erfolgt eine identitätsspezifische Autorisierung, in der die Autorisierungbasierend auf den in Tickets definierten Berechtigungen anhand der Identität deszugreifenden Subjekts erfolgt. Dies kann entweder die Identität des Versicherten selbstoder die Identität einer durch ihn in einem ServiceTicket berechtigten Leistungserbringersbzw. einer natürlichen Person sein.Durch das Ausstellen von ServiceTickets kontrollieren Versicherte somit die Informationsflüssezum und vom Fachdienst, von denen es, grob betrachtet, zwei gibt: zum einen dasEinstellen von medizinischen Daten des Versicherten in den Fachdienst, zum anderendas Entnehmen von medizinischen Daten vom Fachdienst. ServiceTickets definieren füreinen Fachdienst, zu welchen Leistungserbringern medizinische Daten des Versichertenfließen dürfen bzw. von welchen Leistungserbringern Informationen über den Versichertenzum Fachdienst fließen dürfen (immer unter der Voraussetzung, dass die rollenspezifischeAutorisierung des Leistungserbringers erfolgreich ist). Diese Zugriffsinformationenwerden von den ServiceTickets in die ObjektTickets übernommen. Auf Basis der Zugriffsinformationenim Objekt-Ticket wird ein Informationsfluss zum/vom Fachdienst erlaubtbzw. abgelehnt.7.5.2 Schutzbedarf und Sicherheitsanforderungen für TicketsDer Schutzbedarf von Service- und ObjektTickets ist inTabelle 23 dargestellt (siehe Anhang C für die ausführliche Schutzbedarfsfeststellung derTickets). Im Gegensatz zu einem ServiceTicket, welches den Versicherten mit nur einemLeistungserbringer verknüpft, verknüpft ein ObjektTicket den Versicherten mit einer Listevon Leistungserbringern. Diese aggregierte Information kann zur Profilbildung missbrauchtwerden, da sie es erlaubt, nachzuvollziehen, bei welchen Leistungserbringern derVersicherte in Behandlung ist bzw. war. Daher wird der Schutzbedarf für die Vertraulichkeitdes ObjektTickets (im Gegensatz zum ServiceTicket) mit hoch bewertet. Auch durcheine Liste von ServiceTickets kann eine Profilbildung erfolgen. Daher ist der Schutzbedarffür eine Liste von ServiceTickets aufgrund der Möglichkeit der Profilbildung ebenfallshoch.Tabelle 23: Schutzbedarf Service- und ObjektTicketBezeichnung Schutzbedarfgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 119 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Service Ticket (unsigniert)Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVertraulichkeitmittelIntegrität Verfügbarkeit Authentizität Nichtabstreitbarkeitsehrhochhoch sehr hoch sehr hochServiceTicket mittel mittel hoch mittel mittelListe von Service-Ticketshoch mittel hoch mittel mittelObjekt Ticket (unsigniert)hochsehrhochhoch sehr hoch sehr hochObjektTicket hoch mittel hoch mittel mittelIm Folgenden werden Sicherheitsanforderungen an Tickets, Ticketverwaltung und –nutzungformuliert 16 .Durch das Signieren des Service- bzw. Objekt-Tickets mit der Signatur des Versichertenergibt sich ein Schutzbedarf von mittel anstelle des ansonsten sehr hohen Schutzbedarfsfür Integrität, Authentizität und Nichtabstreitbarkeit eines Tickets. Es ist daher entscheidend,dass diese Signatur vom Versicherten freiwillig, bewusst, nur von ihm und ingeschützter Umgebung erfolgt. Dies heißt im Einzelnen:• Nur der Versicherte darf ein Ticket mit Berechtigungen für Leistungserbringerzum Zugriff auf seine Versichertendaten vergeben. Zur Rechtevergabe dürfenkeine anderen Beteiligten notwendig sein bzw. zugelassen werden.• Dem Versicherten muss unmissverständlich bewusst sein, dass er durch dasAusstellen und Signieren des Tickets Berechtigungen an berechtigte Leistungserbringervergibt. Er muss sich darüber hinaus auch sicher sein können,dass durch das Signieren keine andere Aktion als die Rechtevergabe realisiertwird.• Das Ausstellen von Tickets muss vom Versicherten in gesicherten Umgebungenstattfinden, in denen er unbeobachtet und freiwillig Tickets für berechtigteLeistungserbringer ausstellen bzw. auch wieder löschen kann.Diese Überlegungen werden in den folgenden Sicherheitsanforderungen zusammengefasst.Tabelle 24: Sicherheitsanforderungen an TicketsAnforderungsnr. BeschreibungAS-TK-01BerechtigungsverwaltungDie Berechtigungsverwaltung MUSS vom Versicherten autark in einerzugelassenen Umgebung zur Wahrnehmung der Rechte des Versichertendurchgeführt werden können.16 Anhang B beschreibt weitere Sicherheitsanforderungen an die Telematikinfrastruktur.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 120 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnforderungsnr. BeschreibungKonsequenzen• Versicherte DÜRFEN die Verwaltung von BerechtigungenNICHT an andere Personen delegieren.• Versicherten MUSS eine handhabbare Fachdienstübergreifende,logisch einheitliche Schnittstelle zur Verwaltungvon Berechtigungen mit einer allgemein verständlichenOberflächengestaltung zur Verfügung gestellt werden.• Die Trennung der Ticketverwaltung von der Ticketnutzungdurch die Leistungserbringer MUSS für den Versichertendeutlich erkennbar sein.AS-TK-02Durchgängige transparente Trennung von Rechteverwaltung undRechtenutzungDie Verwaltung von im Ermessen des Versicherten stehenden RechtenMUSS informationstechnisch durchgängig von der Nutzung der§291a Anwendungen durch die Leistungserbringer getrennt sein.Konsequenzen• Im Konnektor und in Fachdiensten MUSS die Rechteverwaltungs-und Kerndienst-Schnittstelle getrennt werden.AS-TK-03ServiceTicketsServiceTickets MÜSSEN vom Versicherten jederzeit gelöscht werdenkönnen. Die mit dem ServiceTicket verbundenen BerechtigungenMÜSSEN dann dem Berechtigten sofort entzogen werden.7.5.3 Umgebungen und Schnittstellen für die Rechteverwaltung durch denVersichertenDas Fachkonzept Anwendungen des Versicherten (AdV) [gemFA_ADV] legt die Anwendungsfälledes Versicherten fest, die in der Umgebung zur Wahrnehmung der Rechte desVersicherten ablaufen müssen. Dazu gehört bspw. auch die Verwaltung der Zugriffsberechtigungenfür freiwillige Anwendungen. Versicherten muss dazu eine einheitliche undverständliche Schnittstelle mit handhabbarer Benutzeroberfläche zur Rechtverwaltungbereitgestellt werden (siehe Sicherheitsanforderung AS-TK-01). Die zur Nutzung der AdV-Anwendungsfälle erforderlichen Geräte oder Einrichtungen müssen dem Versicherten inangemessenem Umfang zum unentgeltlichen Gebrauch zur Verfügung gestellt werden.Im Folgenden werden• die Umgebungen zur Wahrnehmung der Versichertenrechte und• die einheitliche Schnittstelle zur Rechteverwaltungkurz beschrieben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 121 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.5.3.1 Umgebungen zur Wahrnehmung der VersichertenrechteZur Durchführung der im Fachkonzept AdV [gemFA_ADV] beschriebenen Anwendungsfällestehen dem Versicherten die folgenden alternativen Umgebungen zur Wahrnehmungseiner Rechte zur Verfügung:• AdV-Terminal: Das AdV-Terminal bietet dem Versicherten die Möglichkeit,die Anwendungsfälle des Fachkonzeptes AdV unbeobachtet und eigenständigin einer öffentlich zugänglichen, aber kontrollierten Umgebung beim Leistungserbringerauszuüben. Es ist technisch sichergestellt, dass ein Zugriff aufdie Daten der eGK nach §291a Abs. 2 Satz 1 Nr. 1 als auch nach Abs. 3 Satz1 in Verbindung mit einem elektronischen Heilberufsausweis erfolgt. DerZugriff auf Daten nach Abs. 2 Satz 1 Nr. 1 kann auch erfolgen, wenn die Versichertenden jeweiligen Zugriff durch ein geeignetes technisches Verfahrenautorisiert haben. Eine SMC mit dem speziellen Profil eKiosk muss vorhandensein.Das AdV-Terminal hat keine Schnittstelle zum Primärsystem, es ist direkt mitder AdV-Schnittstelle des Anwendungskonnektors des Leistungserbringersverbunden.• AdV-Automat (SB-Terminal): Die AdV-Automat-Umgebung ist ein öffentlichzugänglicher, aber (im Gegensatz zum AdV-Terminal) nicht überwachter Bereich.Die Umgebung ist öffentlich und bietet nur eingeschränkt Schutz vorVandalismus und Manipulation. Eine SMC mit dem speziellen Profil eKioskmuss vorhanden sein.Der AdV-Automat ist mit der Telematikinfrastruktur über einen Konnektor verbundenund zwar, wie beim AdV-Terminal, nur über die AdV-Schnittstelle desAnwendungskonnektors.• Versicherter@home 17 : Entsprechend technisch ausgestattete Versichertekönnen in ihrer Heim-PC Umgebung ungestört ihre Rechte wahrnehmen. Dieseempfohlene Umgebung (Kartenterminal, Softwareumgebung) ist in derVerantwortung des Versicherten.Unabhängig von der Alternative muss die Praktikabilität und Alltagstauglichkeit der Umgebungengewährleistet sein. Eine Verzögerung der Nutzung bzw. ein zusätzlicher Aufwandund Wege sind einem Versicherten nicht zuzumuten.7.5.3.2 Schnittstelle zur RechteverwaltungAbbildung 19 zeigt die Einbindung der einheitlichen Schnittstelle zur Rechteverwaltung indie Telematikinfrastruktur.17 Im Rahmen der Konzeption der Anwendungen des Versicherten muss noch genauer diskutiertwerden, inwieweit dieses Szenario ausgestaltet werden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 122 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Primärsysteme•PVS, AVS, KISaktive Patiententerm.PC-Term., SB-Term.•Versicherter@homeAnwendungsKonnektor•Nutzung•Anw. des Vers.•Rechte-Mgmt.Anwendungsgateway•Audit für Nicht-AbstreitbarkeitAnonymisierung,•Anwendungsverwaltung•§291a Fachdienste (Pflicht &Freiwillig)• VSDM, VODM, Notfalldaten, AMTS,• Patientenfach, Patientenquittung• Arztbrief, ePatientenakteMehrwertdiensteSicherheitsdienste (fachdienstbezogen)• Authentisierung, Autorisierung• RechteverwaltungAdV UmgebungPC-Term., SB-Term.Versicherter@homeeGKHBAAnwendungs-KonnektorAdVAudit,SAK,ver/entschlüsselnKryptofunktionenSchlüsselSOAP Req./Res.Übergreifendes Sicherheitskonzept der TelematikinfrastrukturRechteverwaltungAudit,SVS, SCS, SAKKryptofunktionenSchlüsselG, Rev, HFachdienstFachdienstAuth., Autor.Auth., Autor.SAK, Auth., ….. Autor.SAK, …..SAK, …..KryptofunktionenKryptofunktionenKryptofunktionenSchlüsselKryptofunktionenSchlüsselKryptofunktionenSchlüsselSchlüsselSchlüsselmed.DatenIdentitätenRechte,TicketsAbbildung 19: RechteverwaltungDer Versicherte nutzt zur Ticketverwaltung die ihm zur Verfügung gestellten Umgebungenzur Wahrnehmung der Versichertenrechte, die direkt mit der AdV-Schnittstelle eines Anwendungskonnektorsverbunden sind. Die AdV-Schnittstelle stellt die Funktionalitäten zurTicketverwaltung (Erzeugung, Modifikation und Löschen) bereit und ist von den anderenSchnittstellen des Konnektors getrennt. Insbesondere kann die AdV-Schnittstelle nichtsimultan mit anderen Schnittstellen des Konnektors genutzt werden.Die AdV-Schnittstelle des Konnektors nutzt die einheitliche Schnittstelle der Rechteverwaltung,welche ihrerseits die Kommunikation mit den Fachdiensten übernimmt, auf denendie vom Versicherten ausgestellten Tickets gespeichert werden. Von den Fachdienstenmuss dazu ebenfalls eine separate Schnittstelle angeboten werden, die von den anderenSchnittstellen des Fachdienstes (z. B. Schnittstelle zur Nutzung des Dienstes) getrenntist.Es gibt somit eine durchgehende Trennung der Schnittstellen zur Ticketverwaltung vonden Schnittstellen zur Nutzung der medizinischen Anwendungen in allen Komponentender Telematikinfrastruktur (vom Konnektor bis zum Fachdienst).7.5.4 Strategie für die schrittweise Einführung der TicketverwaltungEntsprechend der Eckpunkte der Sicherheitsstrategie müssen Maßnahmen zur Begrenzungder Restrisiken getroffen werden. Aus sicherheitstechnischer Sicht wird daher eineschrittweise Erweiterung der Funktionalität der Rechteverwaltung für den Versichertenempfohlen.• Im ersten Schritt können Versicherte lediglich anwendungsspezifische Berechtigungenvergeben. Berechtigte Leistungserbringer werden für die gesamtemedizinische Anwendung, d. h. für alle medizinischen Objekte diesergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 123 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnwendung, berechtigt. Es erfolgt keine Differenzierung der Rechte für medizinischeObjekte innerhalb der Anwendung. 18• Im zweiten Schritt können Versicherte neben anwendungsspezifischen auchobjektspezifische Berechtigungen vergeben. Mittels objektspezifischer Berechtigungenwerden Leistungserbringer vom Versicherten für einzelne medizinischeObjekte berechtigt.Diese schrittweise Einführung reduziert anfänglich die Komplexität für die Versicherten.Organisatorische und technische Sicherheitsmaßnahmen sowie proaktive Prozesse zurschnellen Reaktion auf Schwachstellen und Kompromittierungen können so schrittweiseoptimiert werden und ein akzeptables Niveau der Restrisiken in den Testvorhaben erprobtund erreicht werden.7.6 ProtokollierungskonzeptDas Protokollierungskonzept umfasst aus sicherheitstechnischer Sicht folgende sicherheitsrelevanteAspekte:• Welche Ereignisse protokolliert werden müssen.• Wo diese Ereignisse protokolliert werden müssen.• Wie lange die Protokolleinträge aufbewahrt werden müssen (soweit dies nochnicht durch fachliche Vorgaben geregelt wurde).In den fachlichen Protokollen MUSS mindestens protokolliert werden „WER“, „WANN“,„WAS“ ausgeführt hat. Medizinische Daten DÜRFEN in den Protokollen NICHT – auchnicht verschlüsselt – gespeichert werden.Die Dauer der Speicherung der Protokollierungen richtet sich nach den relevanten gesetzlichenVorgaben. Es MUSS hierbei sichergestellt sein, dass auf der eGK mindestens dieletzten 50 Zugriffe gespeichert sind.Grundsätzlich MUSS die Protokollierung dem Prinzip der Datensparsamkeit genügen. EsMUSS sichergestellt sein, dass nur die unbedingt notwendigen Daten protokolliert werden.Weiterhin MÜSSEN grundsätzlich gesetzliche Anforderungen erfüllt werden, das inkludiertu.a. auch die Anforderungen aus dem Bundesdatenschutzgesetz.7.6.1 BegriffsbestimmungInnerhalb der Telematikinfrastruktur existieren mehrere Arten der Protokollierung. Es lässtsich einerseits unterscheiden zwischen• Dezentraler Protokollierung und• Zentraler Protokollierungund andererseits zwischen18 Als Ausnahme wird für die Einlösung eines Rezeptes durch Fernübermiitlung die objektspezifischeFunktionalität für die eVerordnung in Release 3 eingeführt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 124 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Fachlicher Protokollierung und• Technischer Protokollierung.Unter „Protokollierung“ versteht man sowohl das fachliche als auch das technische Protokollierenvon Daten. Mit „Audit“ ist das fachliche Protokollieren durch den AuditS gemeint.Mit „Logging“ hingegen wird die technische Protokollierung bezeichnet.Als „dezentrale Protokollierung“ wird nach aktuellem Stand nur die Protokollierung auf dereGK bezeichnet. Unter „zentraler Protokollierung“ versteht man die fachliche Protokollierung,die versichertenzentrierte Protokollierung durch den Audit Dienst und die technischeProtokollierung bei den einzelnen Betreibern.Die „fachliche Protokollierung“ ist die Protokollierung von Zugriffen auf personenbezogeneDaten. Sie dient ausschließlich Datenschutzzwecken. Die „Technische Protokollierung“ istdie Protokollierung von technischen Daten, z. B. des Systemstatus eines Servers.7.6.2 Dezentrale ProtokollierungDie dezentrale Protokollierung hat die Aufgabe, dass auch Protokolle geschrieben werdenkönnen, wenn z. B. der Auditdienst nicht erreichbar ist, da z. B. ein Leistungserbringeroffline ist. Die Umsetzung der dezentralen Protokollierung erfolgt durch die Protokollierungauf der eGK.7.6.2.1 Protokollierung auf eGKDie Protokollierung auf der eGK ist eine dezentrale, fachliche Protokollierung.Zur Datenschutzkontrolle MÜSSEN auf der eGK mindestens die letzten 50 Zugriffe derdem informationellen Selbstbestimmungsrecht des Versicherten unterliegenden Datenprotokolliert werden.Die Protokollierungseinträge werden vom Konnektor erstellt. Die Voraussetzung für dasSchreiben eines Records ist eine erfolgreiche C2C-Authentifikation mit einer SMC odereinem HBA.Über die für die Versicherten unentgeltlich zur Verfügung zu stellenden eKioske MUSSdie Einsicht auf die Protokolleinträge auf der eGK verständlich und übersichtlich möglichsein.7.6.3 Zentrale ProtokollierungNeben der dezentralen Protokollierung existiert auch eine zentrale Protokollierung.7.6.3.1 Versichertenzentrierter Audit (AuditS)Der Auditdienst stellt eine fachliche Protokollierung dar. Er MUSS die Einträge versichertenzentriertspeichern und versichertenindividuell verschlüsseln.Die notwendigen Auditdaten MÜSSEN in der Telematikinfrastruktur grundsätzlich so übertragenbzw. gespeichert werden, dass eine Zusammenführung von Ereignissen unterschiedlicherVersicherter bzw. Profilbildung nicht möglich ist (Generelle Grundlage BDSG§9 und Anhang B).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 125 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturGrundlage für die Protokollierung ist §291a, Absatz 6, Satz 2. Die protokollierten Zugriffefür Datenschutzzwecke werden dem Versicherten unabhängig vom Speicherort in einerallgemein verständlichen, übersichtlichen Form angezeigt. Dabei gilt:• Es MÜSSEN die versichertenzentrierten Auditinformationen verschiedenerFachdienste für einen Versicherten zusammengeführt werden.• Es MÜSSEN die zu unterschiedlichen Anwendungen erhobenenAuditinformationen getrennt verarbeitet und ggf. dargestellt werden können.Dem Versicherten MÜSSEN Möglichkeiten zur unbeobachteten Einsichtnahme in dasZugriffsprotokoll angeboten werden.Die Zweckbindung der Daten (Anlage zu §9, Satz 1, Nummer 8, BDSG) ist auch bei derZusammenführung der Auditdaten für einen Versicherten insoweit zu beachten, dasszumindest eine getrennte Anzeige nach den unterschiedlichen Anwendungen ermöglichtwird.7.6.3.2 Technische ProtokollierungBetreiber MÜSSEN jeweils lokal eine technische Protokollierung (Logging) durchführen.Diese Protokollierung hat das Ziel im Fehlerfall Fehler erkennen und beheben zu können.Diese technische Protokollierung umfasst einerseits das Systemprotokoll, in dem Logmeldungendes Gesamtsystems protokolliert werden und andererseits spezielle Logs einzelnerApplikationen, z. B. Logs der Firewall oder des VPN-Konzentrators7.6.4 Alarme bei SicherheitsverletzungenTreten Sicherheitsverletzungen auf, die aus den Protokollierungen erkennbar sind, MUSSdarauf entsprechend reagiert werden. Je nach Sicherheitsverletzung müssen z. B. automatisiertAlarmierungen verschickt werden. Genauere Vorgaben finden sich in Anhang G.Die einzelnen Maßnahmen wie auf Sicherheitsverletzungen reagiert wird, MÜSSEN spezifiziertwerden.Das Kapitel wird in einer späteren Version des Dokumentes ergänzt.7.7 Zeitdienste und ZeitstempelIn der Telematikinfrastruktur sind für die verschiedenen Anwendungsfälle mit zeitlichemBezug Dienste zur Zeitsynchronisation vorzusehen, auf die im Folgenden näher eingegangenwird.7.7.1 BegriffsbestimmungenEine „Zeitangabe“ bezeichnet digitale Daten, die einen bestimmten Zeitpunkt repräsentieren.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 126 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturEin „Zeitstempel“ 19 bezeichnet eine Zeitangabe, die anderen Daten beigefügt oder mitihnen logisch verknüpft wird.Eine Zeitangabe oder ein Zeitstempel wird – in der Regel auf Wunsch eines „Anfragers“(Requestor) - durch einen „Aussteller“ (Issuer) erzeugt und von einem auf die Korrektheitderselben vertrauenden Partei - dem so genannten „Nutzer“ (Relying Party) - genutzt. Inbestimmten Anwendungsfällen können diese Rollen (Anfrager, Aussteller und Nutzer) ineiner einzigen Komponente realisiert sein.Ein „beweiskräftiger Zeitstempel“ bezeichnet einen Zeitstempel, mit dem die Existenz bestimmterDaten vor einem bestimmten Zeitpunkt bewiesen werden kann (vgl. [ISO18014]).Die „Beweiskraft“ (oder der „Beweiswert“) eines Zeitstempels ist proportional zur Schwierigkeit,einen Augenscheinsbeweis gemäß §§ 371 ff ZPO zu erschüttern oder gar zu widerlegen– je schwieriger es für die Gegenpartei ist, den Beweis zu erschüttern oder zuwiderlegen, desto höher ist die Beweiskraft (oder der Beweiswert).7.7.2 Zeitangaben/Zeitdienst in der TelematikinfrastrukturDas wesentliche Merkmal der Sicht auf Zeit im Gesamtsystem ist eine ausreichend genaueSicht auf die temporale Ordnung der innerhalb des Gesamtsystems auftretendenEreignisse 20 , d. h. von zwei innerhalb des Systems aufgetretenen Ereignissen e1 und e2kann mit ausreichender Genauigkeit bestimmt werden obe1 vor e2 odere2 vor e1 aufgetreten ist odere1 und e2 im Rahmen der zu Grunde gelegten Präzision gleichzeitig aufgetreten sind.Weniger kritisch als die temporale Ordnung ist der absolute Zeitpunkt zu dem diese Ereignisseaufgetreten sind.Aufgrund der besonderen Anforderungen an die Vertrauenswürdigkeit des Gesamtsystemsund der – besonders aus juristischer Sicht – großen Bedeutung der temporalenOrdnung von Ereignissen gelten für die Zeitsynchronisation im Gesamtsystem folgendeSicherheitsanforderungen:• Synchronisation innerhalb der Telematikinfrastruktur / interne Synchronisation.Systemkomponenten MÜSSEN ihre Uhrzeit regelmäßig prüfen und gegebenenfallsaktualisieren.• Fehler-Toleranz – „False Ticker“. Ein „False Ticker“ ist eine Uhr (NTP-Server)die konsistent eine falsche Uhrzeit liefert (z. B. um 1h verschoben). Bei nurzwei verfügbaren NTP-Servern ist es einem Client nicht möglich zu identifizieren,welcher Server eine falsche Uhrzeit liefert. Um robust gegenüber diesemFehler zu sein, MÜSSEN mindestens 3 Stratum-2-Server eingesetzt werden.Die Stratum-1 Server können einfach ausgelegt sein, da die Stratum-2 Serveruntereinander als Peers fungieren.19 Ein solcher Zeitstempel muss nicht zwingend kryptographisch gesichert oder von einer vertrauenswürdigenPartei ausgestellt sein. Insofern ist der Begriff des Zeitstempels hier weiter gefasst,als in [ISO18014], da Zeitstempel im Sinne dieses Dokumentes nicht zwingend Beweiskraft entfaltenmüssen. Ein Zeitstempel im Sinne von [ISO18014] wird hier als „beweiskräftiger Zeitstempel“bezeichnet.20 Ein Ereignis findet zu einem bestimmten Zeitpunkt statt und hat keine Dauer.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 127 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Fehler-Toleranz – „False Speaker“. Um das Gesamtsystem robust gegenüberUhren zu machen, die nicht nur eine falsche Zeit liefern, sondern auch jedemanfragenden System eine andere falsche Zeit nennen („byzantinischer Fehler“)sind mindestens 3n+1 Zeitserver notwendig, wobei n die Anzahl der Uhrenmit diesem Fehlertyp ist, die erkannt werden sollen. Es wird gefordert,dass genau ein „False Speaker“ erkannt werden muss. Deshalb MÜSSEN –da Konnektoren nur auf Stratum-2 Zeitserver zugreifen können – mindestens4 Stratum-2 Zeitserver eingesetzt werden.• Standortredundanz. Im Falle redundanter RZ-Standorte MUSS an jedemStandort eine minimale Anzahl von 3 Stratum-2 Zeitservern verfügbar sein(d. h. „False Ticker“ MÜSSEN beim Ausfall eines Standortes oder der Verbindungzwischen diesen Standorten von nach gelagerten Systemen noch identifizierbarbleiben).• Konnektor-RTC – Max. Korrekturzeit. Außer beim initialen Setup DARF die imRahmen der Synchronisation empfangene Zeit NICHT um mehr als ±5 Minutenvon der aktuellen Zeit im aktiven Konnektor abweichen.7.7.3 ZeitstempelZurzeit ergeben sich aus den Fachkonzepten keine Anforderungen, die einen Einsatz vonbeweiskräftigen, qualifizierten Zeitstempeln zwingend erfordern.Sollte sich diese Ausgangslage ändern und ein Einsatz von qualifizierten Zeitstempelnerforderlich werden, müssen diese neuen Anforderungen geprüft werden.7.8 Kryptographiekonzepte für die TelematikinfrastrukturDie Sicherheit aller § 291a Anwendungen beruht auf der Verwendung der korrekten kryptographischenMethoden und der dabei eingesetzten Schlüssel. Aufgrund dieser zentralenFunktion erfordert das Keymanagement mindestens den Schutzbedarf der sensitivstenAnwendung. Dies beinhaltet den Schutz vor Fehlbedienung, Innentätern und unberechtigtemEindringen oder Ausspähen des Keymanagement Systems und damit des verwendetenSchlüsselmaterials. Daher MÜSSEN die kryptographischen Anforderungen und festgelegtenAlgorithmen der gematik vom Keymanagement der verwendeten Schlüssel injeder Phase des Lebenszyklus der Schlüssel mindestens eingehalten oder sogar übertroffenwerden. Das Kryptographiekonzept legt normativ für einzelne Anwendungsbereichedie zu verwendenden Algorithmen unter Verwendung [BSI TR-03116]) sowie mindestenseinzuhaltende Vorgaben für wesentliche Eigenschaften des Schlüsselmaterials und derEinsatzumgebung fest. Für die verwendeten Schlüsseltypen werden in folgenden Punktennormative Mindeststandards festgelegt:• Die Angabe der für die jeweilige Anwendung zugelassenen kryptographischenVerfahren (i. d. R. Auswahl aus [BSI TR-03116]) sowie Festlegung wesentlicherEigenschaften des Schlüsselmaterials und der Einsatzumgebung.• Für die verwendeten Schlüsseltypen werden in folgenden Punkten normativeeinheitliche Mindeststandards festgelegt:oBeschreibung der Rahmenbedingungen und Mindestanforderungen zurEinsatzumgebunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 128 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturoooBeschreibung der einzuhaltenden Mindestanforderungen während des Lebenszyklusdes eingesetzten SchlüsselmaterialsAnforderung an Notfallmaßnahmen und Vorgaben zur AlarmierungBeschreibung des eingesetzten SchlüsselmaterialsDie Technische Richtlinie 03116 [BSI TR-03116] bildet die Grundlage für die Auswahl derkryptographischen Algorithmen des Kryptographiekonzepts der gematik. Ziel der BSI TR-03116 zu Sicherheitsvorgaben für den Einsatz kryptographischer Verfahren der elektronischenGesundheitskarte, des Heilberufsausweises und technischer Komponenten derTelematikinfrastruktur des Gesundheitswesens ist: „Das Bundesamt für Sicherheit in derInformationstechnik (BSI) gibt mit dieser Technischen Richtlinie eine Bewertung der Sicherheitund eine langfristige Orientierung für den Einsatz kryptographischer Verfahrender elektronischen Gesundheitskarte, des Heilberufsausweises, der technischen Komponentenund der Dienste der Telematikinfrastruktur des Gesundheitswesens". Die in dieserTechnischen Richtlinie betrachteten kryptographischen Verfahren wurden unter Berücksichtigungihrer Sicherheit und Vertrauenswürdigkeit und des gegenwärtigen Standes derSpezifikationen ausgewählt.Das Kryptographiekonzept als Teil des Sicherheitskonzepts der gematik stellt Anforderungen,schreibt aber in der Regel keine konkreten Maßnahmen vor, um die Realisierungennicht mehr als notwendig einzuschränken. In den Fachkonzepten und Spezifikationender gematik werden, wo es nötig ist, unter Berücksichtigung des Kryptographiekonzepts,konkret die einzusetzenden Verfahren festgelegt.7.8.1 Grundlegende AnforderungenDie nachfolgenden Anforderungen stellen die Mindestanforderungen für alle Einsatzgebietekryptographischer Algorithmen innerhalb der Telematikinfrastruktur dar. Wird bei einemkonkreten Einsatzgebiet die Nutzung eines anderen Algorithmus gefordert, dann müssendie hier formulierten Mindestanforderungen erfüllt werden.Die grundlegenden Anforderungen an die in der Telematikinfrastruktur eingesetzten kryptographischenAlgorithmen sind in der folgenden Tabelle zusammengetragen:Tabelle 25: Grundlegende AnforderungenKennung BeschreibungAS-Krypt-01AS-Krypt-02AS-Krypt-03AS-Krypt-04Für kryptographische Operationen in der Telematikinfrastruktur MÜSSENstets nach dem Stand der Wissenschaft und Technik geeignete Algorithmenund Parameter entsprechend der Technischen Richtlinie des BSI [BSITR-03116] eingesetzt werden.Die Liste der in der Telematikinfrastruktur verwendbaren AlgorithmenMUSS von der gematik mindestens einmal jährlich und bei Bedarf (z. B. beineuen wissenschaftlichen Erkenntnissen bzw. bei Änderungen in [BSI TR-03116]) überprüft und ggf. angepasst werden.Die Hard- und Softwarearchitektur MUSS den Austausch kryptographischerAlgorithmen und Parameter erlauben und eine Migrationsfähigkeitzur Anpassungen, u. a. bei Änderungen von [BSI TR-03116], vorsehen.Die Kommunikations-Protokolle bzw. Sicherheitskomponenten MÜSSENso gestaltet sein, dass ein Erzwingen des Einsatzes von Algorithmen oderParametern, deren Sicherheitseignung nicht mehr gegeben ist, nicht mög-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 129 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturlich ist.AS-Krypt-05AS-Krypt-06AS-Krypt-07AS-Krypt-08Während einer im Anlassfall zu definierenden Übergangsphase MÜSSENsowohl neue als auch alte Algorithmen und Parameter verarbeitet werdenkönnen.Hinweis: Eine Anpassung der Schlüssellänge/Tausch des Algorithmus jedeseingesetzten Verfahrens sollte innerhalb von 6 Monaten 21 für alle imEinsatz befindlichen Schlüssel/Verfahren möglich sein. Während dieserÜbergangsphase müssen sowohl neue als auch alte Schlüssel/Verfahrenverarbeitet werden können.Übersteigt die Lebensdauer kryptographisch behandelter Daten die Dauerder Sicherheitseignung der eingesetzten Algorithmen und Parameter soMÜSSEN die Daten vor dem Ablauf der Sicherheitseignung durch eine erneuteVerschlüsselung bzw. Nachsignatur entsprechend geschützt werden.Alle Sicherheitskomponenten SOLLEN für jedes kryptographische Primitivdie notwendige Migrationsfähigkeit von Algorithmen unterstützen. NähereVorgaben SOLLEN in den jeweiligen Einsatzumgebungen der einzelnenAnwendungsbereiche festgelegt werden.Für jeden Schlüssel MÜSSEN die relevanten Abläufe während des komplettenLebenszyklus festgelegt werden. Der Lebenszyklus eines Schlüsselsumfasst nach ISO 11770 Erzeugung (Generation), Aktivierung (Activation)mit Installation jeweils optional Zertifikatserzeugung, Schlüsselableitung,Schlüsselverteilung, Registrierung des Schlüssels/Zertifikats,Speicherung des Schlüssels, sowie Deaktivierung (Deactivation), Reaktivierung(Reactivation) und Zerstörung des Schlüssels (Destruction).7.8.2 Langfristige Perspektive für eingesetzte AlgorithmenDie Technische Richtlinie TR-03116 wird weiter Voraussagen nur für 6 Jahre machen undvom BSI jährlich angepasst werden. Die gematik muss und wird aber in längeren Zeiträumenplanen. Dabei wird sie vom BSI unterstützt, das signalisiert, bei welchen Verfahrendas BSI zum Zeitpunkt der Planung in den über 6 Jahres-Horizont hinausgehendenZeiträumen keine Schwierigkeiten erwartet.Das BSI stuft 1024 Bit RSA und 2TDES (Triple-DES mit 112 Bit langem Schlüssel) nichtmehr als sicher genug ein, um im Wirkbetrieb mit großen Mengen von Patientendateneingesetzt zu werden. Für die verschiedenen räumlich und zeitlich begrenzten Tests werdendiese Verfahren aber noch als sicher genug angesehen. Daher ist bis zum Ende deszweiten Quartals 2008 auf RSA in der Größenordnung von 2048 Bit und symmetrischeVerschlüsselung auf 3TDES (Triple-DES mit 168 Bit langem Schlüssel) zu migrieren.Laufzeiten der eGKs von derzeit maximal 5 Jahren sind zu berücksichtigen. Durch dieseErhöhung der Schlüssellängen Mitte 2008 werden die eGK der Generation 1 bis Anfang2016 im Wirkbetrieb verwendet werden. Diese Algorithmen werden vom BSI bis 2013 alssicher angesehen – das BSI sieht zurzeit jedoch keine Hemmnisse, dass diese Algorithmennicht bis Anfang 2016 eingesetzt werden könnten.21 Welche Vorlaufzeit tatsächlich benötigt wird, kann im Einzelfall bewertet und entschieden werden.Die technische Lösung muss aber eine Anpassung innerhalb dieses Zeitraums ermöglichen.Die Laufzeiten von ggf. zu tauschenden Karten sind in diesen 6 Monaten nicht enthalten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 130 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTest-, eGK-Generation 1SpezifikationeGK Generation 2HBA/SMC Generation 2Bereiche20072008Q2 Q1Q3 Q2Q3 Q4 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1Q2 Q3 Q4XML DokumenteSignatur (qual., fortgeschritten) RSA-1024 RSA-1280 RSA-1536 RSA-1728 RSA-1976//2048Verschlüsselung (Dokumente) AES-256AES-256Verschlüsselung (Schlüssel) RSA-1024 RSA-2048 ECC-256 .PKI(CAs, TSL) RSA-1024 RSA-2048 ECC-256 .20092010201120122013XML NachrichtenAuthentisierungRSA-1024 RSA-2048 ECC-256 .C2C AuthentisierungIdentität (CV-Schlüssel)PKI(CV-Zertifikate)CVC root (Root, ….)C2S AuthentisierungIdentitätenVerschlüsselung (TC)RSA-1024 RSA-2048 ECC-256 .RSA-1024 RSA-2048 ECC-256 .RSA-1024 RSA-2048 ECC-256 .2TDES 3TDES AES-1282TDES 3TDES AES-128Abbildung 20: Kryptographische Algorithmen in der TelematikinfrastrukturDamit sind, wie inAbbildung 20 undAbbildung 21 dargestellt, drei Generationen von eGK derzeit langfristig für den Einsatz bis2020 vorgesehen:• GenerationTestkarten– eGK Version 1.2 für die Testvorhaben• eGK Generation 1 – eGK Version 2.X für den Beginn des Rollouts und ErstePhase Wirkbetrieb• eGK Generation 2 Migration auf Elliptische Kurven ECC im Wirkbetrieb.In der Migrationsplanung muss der notwendige Vorlauf der HBA/SMC vor der Einführungder eGK der Generation 2 in 2011 vorgesehen und von Kartenherausgebern und Trustcenternumsetzbar sein. Der Übergang auf Verfahren mit elliptischen Kurven ist daherfrühestens für den Jahreswechsel 2010/2011 geplant. Details (u. A. die Kurvengröße,geplant sind 256 Bit) müssen dazu noch festgelegt werden. Weitere Kartengenerationen(2+) sind dann durch eine Vergrößerung der Schlüssellänge innerhalb eines Kryptoalgorithmuszu späteren Zeitpunkten (eGK ab 2016) möglich.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 131 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKartengenerationen undAlgorithmenGesundheitskarten• eGK – Generation 1• eGK – Generation 2• eGK – Generation 2+Heilberufsausweise (HBA/SMC)• HBA Gen.1 interop. eGK Gen1• HBA Gen.2 interop. eGK G1&G2, SMC G1• HBA Gen.2+Algorithmen für Authentisierung• RSA 1024/2048, SHA-1 für C2C; 2/3TDESfür C2S; CVC-root RSA-1024/2048,• ECC 256 für C2C, CVCmit CVC –Root ECC• ECC xxx für C2C, CVCmit CVC –Root ECC xxxNotfall und Ersatzverfahren• Krypto-AlgorithmenHash-Verfahren.Generation 1 Generation 22007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019SpezifikationZulassungEnde AusgabeEnde AusgabeErstausgabeErstausgabeEnde LaufzeitSpezifikationErstausgabeZulassungRSA 1024/2048SHA-2562/3TDESEnde LaufzeitEnde AusgabeSpezifikationErstausgabeZulassungEnde AusgabeECC-256SHA-256Ende LaufzeitKeine Ersatzverfahren vorgesehenErsatzverfahren ist festzulegenGeneration 2+ECC-xxxSHA-xxx2020Ende LaufzeitEnde LaufzeitEnde AusgabeAbbildung 21: Migrationsplanung der Kartengenerationen und der zugehörigen Algorithmen.Weitere Informationen stehen im Anhang F3.3.7.9 Anonymisierung und PseudonymisierungSowohl das BDSG (§3a BDSG) als auch die Richtlinie 95/46/EG fordern, dass ein Personenbezugvermieden oder durch Anonymisierung oder Pseudonymisierung beseitigt odererschwert werden muss, soweit für Zwecke der Datenverarbeitung ein Personenbezugnicht erforderlich ist. In der [Grundsatzentscheidung] wird speziell die Anonymisierung desArztbezugs für bestimmte Anwendungen gefordert, um die Erstellung von Bewegungsprofilenbei der Online-Nutzung zu verhindern. Die Telematikinfrastruktur ist daher so zu gestalten,dass sie möglichst keinen Personenbezug und auch keine Personenbeziehbarkeitaufweist (A_02456). Von den Möglichkeiten der Anonymisierung und Pseudonymisierungist Gebrauch zu machen, soweit dies möglich ist und der Aufwand in einem angemessenenVerhältnis zu dem angestrebten Schutzzweck steht.In der Telematikinfrastruktur sind die Daten der Versicherten in versichertenzentriertenFachdiensten in der Datenhoheit des Versicherten gespeichert. Jeder Zugriff muss Benutzerbezogen autorisiert werden und die Zugriffe sind nachprüfbar und revisionsfähig zuspeichern.• Versichertenzentrierte Speicherung: Von der Datenschutzgruppe gemäßArtikel 29 der Richtlinie 95/46/EG wird in [Dat07] gefordert, dass "Patientenabsolut zweifelsfrei identifizierbar sein müssen. Würden aufgrund von Fehlernbei der Patientenidentifikation irrtümlicherweise Daten einer anderen Personverwendet, hätte dies in vielen Fällen fatale Folgen." Die Daten in den VersichertenzentriertenFachdiensten in der Telematikinfrastruktur sind eindeutigeinem Versicherten zugeordnet. Allgemein MUSS die Zuordnung der Dateneines Versicherten in der Telematikinfrastruktur zu der Identität des Versichertensichergestellt werden. Dies wird durch die Verknüpfung der Zugangsauto-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 132 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturrisierung und der Verschlüsselung der Daten durch die kartenindividuellenSchlüssel auf der eGK des Versicherten erreicht. Auch bei dem Wechsel derkryptographischen Identität (Kartenwechsel) MUSS dieser Bezug erhaltenbleiben und es dürfen keine medizinischen Daten des Versicherten verlorengehen.• Benutzerbezogene Autorisierung und Nachweisbarkeit der Zugriffe: DerZugriff auf Daten mittels der elektronischen Gesundheitskarte darf nach §291aSGB V nur in Verbindung mit einem elektronischen Heilberufsausweis mittelseiner sicheren Authentifizierung erfolgen. Zugriffsberechtigte Personen wieberufsmäßige Gehilfen können ohne elektronischen Heilberufsausweis oderentsprechenden Berufsausweis zugreifen, wenn nachprüfbar elektronisch protokolliertwird, wer auf die Daten zugegriffen hat und von welcher Person diezugreifende Person autorisiert wurde. Dabei ist zu gewährleisten dass die Berechtigtenausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Datenzugreifen können. Es MUSS nachträglich überprüft und festgestellt werden,ob und von wem personenbezogene Daten eingegeben, verändert oderentfernt worden sind (Eingabekontrolle nach Anlage zu § 9 Satz 1 BDSG).Durch diese Anforderungen zur Identifizierung der Versicherten und Authentisierung derZugriffe werden die Möglichkeiten der Anonymisierung und Pseudonymisierung eingeschränkt.Die Gestaltung der Telematikinfrastruktur muss jedoch den Schutz der Daten inder TI vor missbräuchlicher Verwendung (A_02465) berücksichtigen. Es dürfen durch dieVerwendung der TI keine zusätzlichen Informationen und Profilbildungen über Versicherteund Leistungserbringer entstehen und verwendet werden. Zu diesem Zweck werden folgendeMaßnahmen realisiert:• Pseudonymisierung der Datenhaltung und des Datenzugriffs bei den Pflichtanwendungen,• Der Zugriff und die Ablage der Daten in den freiwilligen Anwendungen erfolgtunter dem lebenslang eindeutigen Teil der Krankenversicherungsnummer,• Anonymisierung des Leistungserbringerbezugs im Broker beim Zugriff auf dieFachdienste insbesondere des VSDD.7.9.1 Pseudonymisierung bei PflichtanwendungenJeder Versicherte bekommt bei der Produktion seiner eGK ein Pseudonym. Das Pseudonym(siehe [gemX.509PolVers]) wird aus dem Nachnamen des Karteninhabers, dem unveränderbarenTeil der KVNR und einer vom Herausgeber (Kostenträger) verwendetenZusatzinformation (herausgeberspezifischer Zufallswert) mit einer geeigneten kryptographischenHash-Funktion (SHA-256) gebildet. Nach Erzeugung des PseudonymsMUSS geprüft werden, ob dieses Pseudonym vom Kartenherausgeber bereits vergebenwurde. Ist dies der Fall, DARF dieses Pseudonym NICHT verwendet werden. Die Pseudonymebei einem Kartenherausgeber MÜSSEN eindeutig sein und es DARF NICHT zuKollisionen gegen aktuell verwendete Pseudonyme in der Telematikinfrastruktur kommen.Dem Versicherten MUSS daher auch bei einem Kartenwechsel ein neues Pseudonymzugewiesen werden. Die maximale Lebensdauer eines Pseudonyms entspricht damit derLaufzeit der Karte bzw. wenn die letzten einem Pseudonym zugeordneten Daten in der TIgelöscht worden sind.Jeder Versicherte hat auf seiner eGK zur Authentifizierung ein pseudonymes Zertifikat(AUT.N-Zertifikat) mit zugehörigem privaten Schlüssel als auch zur Verschlüsselung einpseudonymes Zertifikat (ENC.V-Zertifikat) mit zugehörigem privaten Schlüssel. Bei pseu-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 133 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturdonymen Zertifikaten beinhaltet der Common Name des Zertifikats lediglich das Pseudonymdes Versicherten. Die Schlüssel sind ohne PIN-Eingabe des Versicherten bei einemLeistungserbringer nach der CVC-Authentisierung mit HBA/SMC verwendbar.Das Pseudonym eines Versicherten wird für die Signatur von Nachrichten des Versichertenund für die Auditierung im Audit-Service verwendet. Die Auditierung erfolgt pseudonymso, dass die am Auditdienst abgelegten Daten nicht ohne weitere Informationen demVersicherten zugeordnet werden können. Das Pseudonym wird als Ordnungsmerkmal (inForm der Seriennummer und eines Kennzeichens des Herausgebers) verwendet. EineDepseudonymisierung ist bei den Pflichtanwendungen nicht erforderlich und DARF daherNICHT erfolgen. Daher sind folgende Mindestanforderungen für die folgenden Diensteeinzuhalten:• VSDD: Zugriffskriterium ist das Pseudonym. Die Daten im VSDD sind so zuverschlüsseln, dass eine Zuordnung KVNR zu Pseudonym in diesem Dienstnicht möglich ist. Der Kartenherausgeber muss sicherstellen, dass die Auflösungdes Pseudonyms nur von ausgewählten Personen mit Einbeziehung desDatenschutzbeauftragten der Kasse möglich ist. Damit wird eine Profilbildungweitgehend mit organisatorischen Maßnahmen ausgeschlossen.• VODD: Die eVerordnungen, die einer Karte zugeordnet sind, gehen bei Kartenverlustbzw. Kartenwechsel verloren.o Die Versicherten MÜSSEN – insbesondere bei regulären Kartenwechseln -darauf hingewiesen werden, dass noch vorhandene Verordnungen eingelöstwerden sollten.oDer VODD muss ungültige und nicht mehr verwendbare Verordnungenselbständig löschen (siehe [BDSG] und Grundsatz der Datenqualität in[Dat07]).• UFS: Eine Online-Verfolgung und Profilbildung der Aktivitäten der VersichertenDARF bei UFS-Anfragen NICHT erfolgen. Die Daten im UFS MÜSSEN sogeschützt werden, dass eine Zuordnung der KVNR zum Pseudonym nichtmöglich ist und die Kasse MUSS sicherstellen, dass die Auflösung des Pseudonymsnur von ausgewählten Personen mit Einbeziehung des Datenschutzbeauftragtenmöglich ist. Damit wird eine Profilbildung weitgehend mit organisatorischenMaßnahmen ausgeschlossen.• OCSP: Eine Online-Verfolgung und Profilbildung der Aktivitäten der VersichertenDARF bei Gültigkeitsabfragen von pseudonymen VersichertenzertifikatenNICHT erfolgen. Die Daten MÜSSEN so gespeichert und verarbeitet werden,dass eine Zuordnung KVNR zu Pseudonym nicht möglich ist. Dabei sind auchzeitliche Korrelationen zwischen pseudonymen und personenbezogenen Anfrageneines Leistungserbringers zu berücksichtigen.Die Wirksamkeit der getroffenen Maßnahmen MUSS im spezifischen Sicherheitskonzeptdieser Dienste gezeigt werden.Der versichertenzentrierte Audit ist die einzige Komponente in der TI, in der eine Verknüpfungder verschiedenen Pseudonyme bzw. eine Depseudonymisierung erfolgen muss.Diese Daten sind in diesem Dienst daher so zu schützen, dass ein Zugriff nur im Rahmender Zweckbindung möglich ist. Die Wirksamkeit der getroffenen Maßnahmen MUSS imspezifischen Sicherheitskonzept dieses Dienstes gezeigt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 134 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.9.2 Freiwillige Anwendungen mit Personenbezug (KVNR)Freiwillige Anwendungen verwenden als Ordnungskriterium und als Authentifizierungsmerkmalfür den Versicherten immer den unveränderlichen Teil der KVNR. Eine Pseudonymisierungkann nicht verwendet werden. Jeder Versicherte hat auf seiner eGK zur Authentifizierungein personenbezogenes Zertifikat (AUT-Zertifikat) mit zugehörigem privatenSchlüssel als auch zur Verschlüsselung ein Zertifikat (ENC-Zertifikat) mit zugehörigemprivaten Schlüssel. Bei personenbezogenen Zertifikaten beinhaltet der Common Namedes Zertifikats den unveränderlichen Teil der KVNR, den Namen des Versicherten sowiedas Institutskennzeichen des Herausgebers. Die Schlüssel sind mit PIN-Eingabe des Versichertenin einer von der gematik zugelassenen Umgebung nach der CVC-Authentisierung mit HBA/SMC verwendbar.Die persönliche Identität wird für die Anwendungen des Versicherten, u. A. der Signaturvon Tickets im Rahmen der Rechteverwaltung und zur Autorisierung von Zugriffen derLeistungserbringer auf die Freiwilligen Anwendungen, durch Nachrichtensignatur genutzt.Damit sind folgende Anforderungen an die Anwendungen zu stellen:• OCSP: Eine Online-Verfolgung und Profilbildung der Aktivitäten der VersichertenDARF bei Gültigkeitsabfragen von persönlichen VersichertenzertifikatenNICHT erfolgen.• Fachdienste: Die Fachdienste MÜSSEN sicherstellen, dass die gespeichertenund übertragenen Metadaten nicht zu einer Profilbildung missbräuchlichvom Betreiber oder von Administratoren verwendet werden können.Eine Zusammenführung der Metadaten von zwei Fachdiensten DARF NICHTmöglich sein. Dies kann z. B. durch feingranulare Pseudonymisierung der gespeichertenDaten in jedem Fachdienst erreicht werden, so dass die Zugriffsschlüsselfür die Datenbankenzugriffe nicht zusammengeführt werden können.• Telematikkomponenten: Die Zwischenspeicherung und Verwendung vonpersonenbezogenen Daten in zentralen Komponenten der Telematikinfrastrukturaus betrieblichen Zwecken SOLL NICHT erfolgen z. B. IDS oderBehandlung von Fehlersituationen. In begründeten Ausnahmefällen MUSSder Datenschutzbeauftragte eingeschaltet und die gematik informiert werden.Die Wirksamkeit der getroffenen Maßnahmen MUSS im spezifischen Sicherheitskonzeptdieser Dienste gezeigt werden.7.9.3 Anonymisierung des LeistungserbringerbezugsDie Broker Services führen für relevante Dienste die Anonymisierung des Leistungserbringersin Nachrichten vom Konnektor zum Fachdienst durch. Nach Prüfung der Nachrichtensignaturund der Rolle des Leistungserbringers durch den Broker ersetzt dieser dieNachrichtensignatur durch die Signatur des Brokers. Lediglich nicht personenbezogeneInformationen werden aus dem signierenden Zertifikat übernommen, und an den Fachdienstweitergeleitet, wie zum Beispiel die Rolle des Handelnden. Durch dieses Vorgehenwird die Identität des Leistungserbringers anonymisiert und eine Erstellung von Bewegungsprofilen(insbesondere durch den Kostenträger bzw. dem Betreiber von Fachdiensten)ausgeschlossen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 135 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDerzeit ist diese Anonymisierung des Leistungserbringerbezugs nur für den Zugriff aufden VSDD vorgeschrieben. Möglich ist diese Anonymisierung für jeden Zugriff bei demdie eGK anwesend ist. Daher SOLL für alle diese Zugriffe die Angemessenheit der Nutzungdieser bereits im Broker vorhandenen Anonymisierungsfunktionalität geprüft werden.7.10 Treuhänder7.10.1 Beschreibung der Rolle des TreuhändersIn der Telematikinfrastruktur wird ein Treuhänder als vertrauenswürdige Instanz gesehen,welche treuhänderisch Zugriff auf bestimmte vertrauenswürdige Datenobjekte hat.Die wichtigsten Anwendungsfälle sind:• Aufbewahrung und Nutzung von Schlüsselmaterial, um den Versicherten imFalle des Verlustes von Schlüsselmaterial (z. B. auch der eGK) oder der PINdie Wiedererlangung des Zuganges zu seinen Daten zu ermöglichen,• Nutzung von Schlüsselmaterial zur Umschlüsselung von Schlüsseln und Datenobjekten,wenn dies durch die Änderung der in der Telematik verwendetenkryptographischen Verfahren zum Zwecke der Datenmigration erforderlichwird.Die Beschreibung der Rolle des Treuhändlers wird parallel zu den Konzepten zum Datenerhaltdetailliert.7.10.2 Sicherheitsanforderungen an den TreuhänderdienstDerzeit stehen folgende Anforderungen an den Treuhänderdienst fest:• Die Rechte des Versicherten, insbesondere das Recht auf informelle Selbstbestimmung,dürfen durch Treuhänder nicht eingeschränkt werden. Dies bedeutetinsbesondere auch, dass der Treuhänder die ihm anvertrauten Schlüsselund Daten Dritten nicht zugänglich und in keiner Weise exponieren darf.• Der Treuhänder muss organisatorisch unabhängig von allen am Betrieb derTelematik Beteiligten sein, er darf also weder in die Organisation der gematik,noch in diejenige eines Betreibers oder Kostenträgers eingebunden sein.• Es muss technisch und organisatorisch sichergestellt sein, dass der Schutzder Datenobjekte und des Schlüsselmaterials entsprechend den Vorgabendes Sicherheitskonzeptes auch bei allen Prozessen, in die der Treuhändereingebunden ist, gewährleistet ist. Diese Prozesse dürfen zu keiner Erweiterungder Möglichkeiten Dritter, auf diese Daten zuzugreifen, führen.• Der Treuhänder darf nicht in die Lage versetzt werden, ohne Einbindung inden Gesamtprozess, dessen Sicherheit auch darauf basiert, dass mehrere Instanzenzwingend involviert sind und getrennt kontrolliert werden, Daten desVersicherten zu entschlüsseln.• Die treuhänderischen Daten müssen vor Beschlagnahmung geschützt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 136 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Die Inanspruchnahme eines Dienstes, der das Vertrauen des Versicherten ineinen Treuhänder voaraussetzt, ist freiwillig.• Das treuhänderisch verwalteten Informationen dürfen nicht geeignet sein, denZugriff auf die Daten der für den Versicherten verpflichtenden Anwendung zuerleichtern.Die Anforderungen des Datenschutzes und der Informationssicherheit werden parallel zur Detaillierung derRollenbeschreibung des Treuhänders verfeinert.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 137 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur7.11 Zusammenstellung der AusgangsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02293SKonnektor_Offline_1: Nachricht an PrimärsystemIst ein Konnektor „offline“, MUSS das den Primärsystemenals Antwort auf Funktionsaufrufe mitgeteilt werden,wenn diese nicht oder nur eingeschränkt durchgeführtwerden können. Der Online-Modus ist derNormalfall. Der Offline-Modus ermöglicht, dass in Fällen,in denen keine VPN Verbindung aufgebaut werdenkann, wichtige Funktionen trotzdem genutzt werdenkönnenA_02294 S Konnektor_Offline_2: C2C-Funktionen Die für den Offline-Fall vorgesehenen SicherheitsanforderungenMÜSSEN mittels Card-2-Card (C2C) Sicherheitsfunktionensichergestellt werden. Dies umfasstu. a. die Offline Protokollierung von Zugriffen aufder eGK, die C2C Authentifizierung mittels CV-Zertifikaten und die Autorisierung über rollenbasierte,verbindliche Access Control Policies für einen Datenbearbeiter.Die Autorisierung für den Offline-Zugriff durch die Versichertenerfolgt durch die Herausgabe der eGKA_02295 S Zonen_Übergänge: Schutzstufen Es existieren 4 Schutzstufen:1: Es MUSS mindestens eine Filterung auf Basis vonstatischen Filtern von Netzwerkpaketen (Static Packetfiltering)stattfinden.2: Es MUSS mindestens eine Filterung auf Basis derAnalyse der jeweiligen Verbindung (Stateful Inspection)stattfinden. Die Anforderung von Stufe 1 MUSSerfüllt werden.Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 138 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02296 S Zone_AS_ZTe-0001: Verarbeitung unverschlüsselterpersonenbezogener DatenA_02297 S Zone_AS_ZTe-0002:Protection Profilesfür Informationsobjekte mit sehr hohemSchutzbedarfA_02298 S Zone_AS_ZTe-0003: EigenverantwortlicherSchutz3: Die Authentizität des Senders jedes NetzwerkpaketsMUSS gegeben sein. Die Anforderungen von Stufe 1und 2 MÜSSEN erfüllt werden.4:Es MUSS eine Filterung/Prüfung auf der Ebene desApplikationsprotokolls auf die Zulässigkeit der übertragenenInhalte erfolgen („Application Level Firewall“bzw. „Content-Inspection“). Die Anforderungen vonStufe 1 und 2 MÜSSEN erfüllt werden.Zone/extern:Protection Profiles für Komponenten zur Verarbeitungvon unverschlüsselten personenbezogenen Daten.Unverschlüsselte personenbezogene Daten MÜSSENvon Komponenten verarbeitet werden, deren Vertrauenswürdigkeitmittels einer auf einem gültigen ProtectionProfile basierenden Zertifizierung dokumentiertwurde, wenn die gematik die Verantwortung für dieseKomponente trägt.Zone/extern:Protection Profiles für Komponenten zur Verarbeitungvon Informationsobjekten mit sehr hohem SchutzbedarfInformationsobjekte mit sehr hohem SchutzbedarfMÜSSEN von einer Komponente verarbeitet werden,deren Vertrauenswürdigkeit mittels einer auf einemgültigen Protection Profile basierenden Zertifizierungdokumentiert wurde.Zone/extern:Eigenverantwortlichkeit externer KommunikationspartnerJeder externe Teilnehmer an der Telematikinfrastrukturist für den Schutz vor sicherheitsrelevanten Zugrif-Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 139 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02299 S Zone_AS_ZTi-0001:Protection Profiles fürKomponenten zur Verarbeitung von unverschlüsseltenpersonenbezogenen DatenA_02300 S Zone_AS_ZTi-0002: Beschränkung desDirekten Zugriffs durch AnwenderA_02301 S Zone_AS_ZTi-0003:Indirekter Zugriffdurch Anwender über dokumentiert vertrauenswürdigeKomponentenfen aus der Telematikinfrastruktur seiner Komponenten(d. h. die eindeutig in seiner Verantwortung stehen)verantwortlich. Dies bedeutet, dass für den Schutz vortechnisch schädlichen Inhalten, deren Ursprung inanderen externen Systemen liegt (auch wenn dieseInhalte über die Telematikinfrastruktur transportiertwurden) eindeutig der für externe Komponenten Zuständigeentsprechende Maßnahmen treffen MUSS.Zone/intern:Protection Profiles für Komponenten zur Verarbeitungvon unverschlüsselten personenbezogenen DatenUnverschlüsselte personenbezogene Daten mit einemSchutzbedarf der Vertraulichkeit von hoch und sehrhoch MÜSSEN von einer Komponente verarbeitetwerden, deren Vertrauenswürdigkeit mittels einer aufeinem gültigen Protection Profile basierenden Zertifizierungdokumentiert wurde, es sei denn, die Verantwortungfür den Umgang mit diesen Daten ist eindeutigjener juristischen Person zugeordnet, die auch dieVerantwortung für die verarbeitende Komponenteträgt.Zone/intern:Direkter Zugriff durch AnwenderDie Möglichkeit eines direkten Zugriffs auf ein internesSystem MUSS auf interne Anwender beschränkt werden.Zone/intern:Indirekter Zugriff durch Anwender über dokumentiertvertrauenswürdige KomponentenDie Möglichkeit eines indirekten Zugriffs auf ein inter-Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 140 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02302 S Zone_AS_ZTz-0001:Sehr hohe VerfügbarkeitA_02303 S Zone_AS_ZTz-0002:Keine unverschlüsselteSpeicherung und Übertragung vonpersonenbezogener DatenA_02304 S Zone_AS_Z1000-0001:Verantwortung fürVertrauenswürdigkeit von Komponentenzur Verarbeitung unverschlüsselter personenbezogenerDaten.A_02305 S Zone_AS_Z1000-0002:Erkennbarkeit vonManipulationen an Telematik-Komponentennes System KANN einem externen Anwender gegebenwerden, wenn er über Komponenten erfolgt, derenVertrauenswürdigkeit mittels einer auf einem gültigenProtection Profile basierenden Zertifizierung dokumentiertwurdeZone/Zentral:Sehr hohe VerfügbarkeitZentrale Komponenten SOLLEN generell einenSchutzbedarf von SEHR HOCH hinsichtlich ihrer VerfügbarkeiterfüllenZone/Zentral:Keine unverschlüsselte Speicherung und Übertragungvon personenbezogener DatenPersonenbezogene Daten mit einem Schutzbedarf derVertraulichkeit von hoch und sehr hoch DÜRFEN ineiner zentralen Zone NICHT unverschlüsselt gespeichertoder übertragen werdenZone 1/dezentral frontend extern:Verantwortung für Vertrauenswürdigkeit von Komponentenzur Verarbeitung unverschlüsselter personenbezogenerDaten.Aufgrund des allgemein nicht garantierbaren Sicherheitsniveausin dieser Zone MUSS die Verantwortungfür die Vertrauenswürdigkeit von Komponenten dieunverschlüsselte personenbezogene Daten verarbeiten,eindeutig geregelt werden.Zone 1/dezentral frontend extern:Erkennbarkeit von Manipulationen an Telematik-Komponenten.Komponenten, deren vertrauenswürdige Ausgestaltungin der Verantwortung der gematik liegt, MÜSSENKap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 141 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellederart gestaltet sein, dass Manipulationen erkennbarsindA_02306 S Zone_AS_Z1000-0003:Manipulationssicherheit von Telematik-KomponentenA_02307 S Zone_AS_Z1000-0004:Nachweis derVertrauenswürdigkeit von Telematik-KomponentenA_02308 S Zone_AS_Z1000-0005:Schutz der Kommunikationzwischen Telematik-KomponentenA_02309 S Zone_AS_Z1000-0006:Prüfung der aufTelematik-Komponenten ausgeführtenDiensteA_02310 S Zone_AS_Z1000-0007:Schutz vor Angriffenüber das NetzwerkZone 1/dezentral frontend extern:Manipulationssicherheit von Telematik-Komponenten.Telematik-Komponenten SOLLEN derart gestaltetsein, dass Manipulationen zur Abschaltung der KomponenteführenZone 1/dezentral frontend extern:Nachweis der Vertrauenswürdigkeit von Telematik-Komponenten.Die Vertrauenswürdigkeit einer Telematik-KomponenteMUSS nachgewiesen werden. Der Nachweis SOLLauf einer Zertifizierung nach einem Protection ProfilebasierenZone 1/dezentral frontend extern:Schutz der Kommunikation zwischen Telematik-Komponenten.Die Kommunikation zwischen Telematik-KomponentenMUSS einen Schutz vor Integritäts- und VertraulichkeitsverletzungenbietenZone 1/dezentral frontend extern:Prüfung der auf Telematik-Komponenten ausgeführtenDienste.Die Authentizität und Integrität eines Dienstes, der aufeiner Telematik-Komponente ausgeführt wird und unverschlüsseltepersonenbezogene Daten verarbeitetMÜSSEN vor dessen Ausführung geprüft werden.Zone 1/dezentral frontend extern:Schutz vor Angriffen über das Netzwerk.Alle Telematik-Komponenten MÜSSEN vor AngriffenKap. 7Kap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 142 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02311 S Zone_AS_Z1000-0008:Überprüfung derAuthentizität anderer Telematik-KomponentenA_02312 S Zone_AS_Z1100-0001:Prüfung derDienste auf Authentizität und IntegritätA_02313 S Zone_AS_Z1900-0001:Verbindungen vonTelematik assoziierte Netzen zu anderenNetzen.A_02314 S Zone_AS_Z2000-0001:Platzierung allerKomponenten in einem Bereich mit ausreichendemphysischen Schutzüber ein Netzwerk entsprechend dem Schutzbedarfder von der Komponenten verarbeiteten Datenobjektegeschützt werden.Zone 1/dezentral frontend extern:Überprüfung der Authentizität anderer Telematik-Komponenten.Alle Telematik-Komponenten SOLLEN nur Kommunikationsbeziehungenzu anderen Telematik-Komponenten unterhalten, deren Authentizität beimKommunikationsaufbau kryptografisch beweisbar ist.Zone 1.1 /Dienste:Prüfung der Dienste auf Authentizität und Integrität.Alle Telematik assoziierten Dienste SOLLEN vor derAusführung auf deren Authentizität und Integrität überprüftwerdenZone 1.9 / Netzwerk:Verbindungen von Telematik assoziierte Netzen zuanderen Netzen.Telematik assoziierte Netze SOLLEN keine direktenVerbindungen ins Internet oder zu anderen nicht mitder Telematik assoziierten Netzen besitzen. Davonausgenommen ist die Verbindung des Netzkonnektorsüber das Internet zum TelematikzugangsproviderZone 2 / zentral extern:Platzierung aller Komponenten in einem Bereich mitausreichendem physischen Schutz.Alle Komponenten MÜSSEN in einem Bereich („Sicherheitsbereich“)platziert sein, der einen ausreichendenphysischen Schutz vor böswilliger und zufälli-gerManipulation/Betriebsstörung bietetKap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 143 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02315 S Zone_AS_Z2000-0002:Schutz der Komponentenvor Angriffen über NetzwerkeA_02316 S Zone_AS_Z2300-0001:Rückführbarkeitdes Zugriffs auf Komponenten.A_02317 S Zone_AS_Z2400-0001:Rückführbarkeitdes Zugriffs auf Komponenten dieser Zoneauf nat. Personen.A_02318 S Zone_AS_Z2400-0002:Rückführbarkeitdes Zugriffs auf Komponenten dieser Zoneauf jur. Personen.A_02319 S Zone_AS_Z2400-0003:Trennung derAdministrationA_02320 S Zone_AS-Z2410-0001:Rückführbarkeitdes Zugriffs auf Komponenten dieser Zoneauf nat. PersonenZone 2 / zentral extern:Schutz der Komponenten vor Angriffen über Netzwerke.Alle Komponenten SOLLEN sich selbst („Host basedFirewalls“) vor Angriffen über das Netzwerk (internoder extern) schützen.Zone 2.3 / Eingeschränkte Dienste:Rückführbarkeit des Zugriffs auf Komponenten dieserZone aus Zone 1.Jeder Zugriff auf Komponenten dieser Zone aus Zone1 MUSS auf eine juristische Person rückführbar seinZone 2.4 / Benutzerindividuelle Dienste:Rückführbarkeit des Zugriffs auf Komponenten dieserZone aus Zone 1 auf nat. Personen.Jeder Zugriff auf Komponenten dieser Zone aus Zone1 SOLL auf eine natürliche Person rückführbar seinZone 2.4 / Benutzerindividuelle Dienste:Rückführbarkeit des Zugriffs auf Komponenten dieserZone aus Zone 1 auf jur. Personen.Jeder Zugriff auf Komponenten dieser Zone aus Zone1 MUSS auf eine juristische Person (z. B. registrierterBesitzer eines Konnektors) rückführbar seinZone 2.4 / Benutzerindividuelle Dienste:Trennung der Administration.Die Komponenten MÜSSEN von anderen Personenadministriert werden, als die Komponenten in den Zonen2.2 und 2.9Zone 2.4.1 / Externe Dienste:Rückführbarkeit des Zugriffs auf Komponenten dieserZone aus Zone 1 auf nat. Personen.Jeder Zugriff auf Komponenten dieser Zone aus ZoneKap. 7Kap. 7Kap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 144 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelle1 SOLL auf eine natürliche Person rückführbar seinA_02321 S Zone_AS-Z2420-0001::Rückführbarkeitdes Zugriffs auf Komponenten dieser Zoneauf nat. PersonenA_02322 S Zone_AS-Z3600-0001:Trennung der Administration.A_02323 S Zone_AS-Z3700-0001:Trennung der AdministrationA_02324 S Zone_AS-Z3800-0001:Trennung der AdministrationA_02325 S Zone_AS-Z4700-0001:Trennung der AdministrationA_02326 S Zone_AS-Z4500-0001:Trennung der AdministrationZone 2.4.2 / Interne Dienste:Rückführbarkeit des Zugriffs auf Komponenten dieserZone aus Zone 1 auf nat. PersonenJeder Zugriff auf Komponenten dieser Zone MUSS aufeine natürliche Person rückführbar seinZone 3.6 / Sicherheitsdienste:Trennung der Administration.Die Komponenten MÜSSEN von anderen Personenadministriert werden, als die Komponenten in den Zonen2 und 3.Zone 3.7 / Administrationsdienste:Trennung der Administration.Die Komponenten MÜSSEN von anderen Personenadministriert werden, als die Komponenten in den Zonen2 und 3.Zone 3.8 / Monitoring Dienste:Trennung der Administration.Die Komponenten MÜSSEN von anderen Personenadministriert werden, als die Komponenten in den Zonen2 und 3.Zone 4.7 /Administrationsdienste:Trennung der Administration.Die Komponenten MÜSSEN von anderen Personenadministriert werden, als die Komponenten in der Zone4.Zone 4.6 / Sicherheitsdienste:Trennung der Administration.Die Komponenten MÜSSEN von anderen PersonenKap. 7Kap. 7Kap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 145 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleadministriert werden, als die Komponenten in der Zone4A_02327 S Zone_AS-Z5000-0001:Trennung der AdministrationA_02328 S Zone_Zonenübergang_5:Ein Informationsflussvon Zone 4 nach Zone 5 DARFNICHT erfolgenA_02329 S Zone_Zonenübergang_6; MehrwertdiensteKÖNNEN in Zone 6 betreiben werden.A_02330 S Zone_Zonenübergänge_AS-Zu-0001:Trennung der Administration vonZonen und ZonenübergängenZone 5 / Dezentral Backend extern:Trennung der Administration.Die Komponenten MÜSSEN von anderen Personenadministriert werden, als die Komponenten in den Zonen2, 3 und 4Ein Informationsfluss von Zone 4 nach Zone 5 DARFNICHT erfolgen.Im Sicherheitskonzept des Betreibers der FachdiensteMUSS die Wirksamkeit der Maßnahmen gezeigt werden,mit denen sichergestellt wird, dass die Daten derFachdienste nur im Rahmen der Zweckbestimmungdes §291a verwendet und nicht über den Zonenübergangin Zone 5 in die existierenden IT-Systemen übertragenund weiterverarbeitet werden könnenZone 6 beinhaltet Mehrwertdienste, die von unabhängigenAnbietern konzipiert und auch entsprechendextern betrieben werden. Auch wenn für Mehrwertdiensteim konkreten Fall gesetzliche Regelungen fürden Umgang mit Gesundheitsdaten relevanten Inhaltenexistieren, erfolgt deren Umsetzung nicht im Rahmender von der gematik verantworteten Telematikinfrastruktur.Die Verantwortung für Schutzmaßnahmenliegt ausschließlich beim Anbieter des MehrwertdienstesTrennung der Administration von Zonen und Zonenübergängen.Die Administration eines Zonenüberganges SOLL voneiner anderen Rolle administriert werden als die Kom-Kap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 146 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02331 S Zone_Zonenübergänge_AS-Zu-0002:Verwendung minimaler RegelsätzeA_02332 S Zone_Zonenübergänge_AS-Zu-0003:Protokollierung von AngriffenA_02333 S Zone_Zonenübergänge_AS-Zu-0004:Protokollierung ohne Überlastungder Kernaufgabe einer KomponenteA_02334 S Zone_Zonenübergänge_AS-Zu-0005:Festlegung von verhinderndenMaßnahmen für alle im Rahmen des Zonenkonzeptsnicht erlaubten Übergängeponenten innerhalb der Quell-/Zielzonen. Im Rahmeneiner „Separation of Duties“ - Strategie sollen Komponentenzur Kontrolle von Zonenübergängen von anderenRollen administriert werden, als die Komponentenin den Quell-/Zielzonen.Verwendung minimaler Regelsätze.Die Regelsätze (für Firewalls etc.) MÜSSEN derartgestaltet sein, dass ausschließlich die unbedingt zurDiensterbringung benötigten Verbindungen möglichsind. Diese umfassen auch Verbindungen der Administrationsdiensteund Monitoring-Dienste.Protokollierung von Angriffen.Alle erkannten Angriffe MÜSSEN protokolliert werdenProtokollierung ohne Überlastung der Kernaufgabeeiner Komponente.Die Protokollierung MUSS so umgesetzt sein, dass derService-Level der Kernaufgabe einer Komponente (z.B. Annahme von VPN-Verbindungen) trotz der zu protokollierenderDatenpakete/ Verbindungsinformationeneingehalten werden kann.Festlegung von verhindernden Maßnahmen für alle imRahmen des Zonenkonzepts nicht erlaubten Übergänge.Für alle im Rahmen des Zonenkonzepts nicht erlaubtenÜbergänge MÜSSEN physische, organisatorischeoder technische Maßnahmen festgelegt werden, diediesen Übergang nicht möglich machen. Besteht z. B.physisch keine Verbindung zwischen zwei Zonen, sosind organisatorische Maßnahmen festzulegen, diediesen Zustand über die Lebenszeit des Systems auf-Kap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 147 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellerechterhalten.A_02335 S Zonenzuordnung_Z1: Systeme der Zone1.Zone 1.2: öffentlich zugängliche Umgebung beim Leistungserbringer;• eKiosk Umgebung (z. B. Selbstbedienungs-Terminal)Zone 1.3: überwachte Umgebung beim Leistungserbringer• Primärsysteme: PVS, AVS, KIS• Kartenterminals, Trusted Viewer• eKiosk-Umgebung (z. B. PC-Terminal)Zone 1.4: zutrittsbeschränkte Umgebung beim Leistungserbringer• Primärsysteme: PVS, AVS, KIS• Kartenterminals, Primärsysteme, Trusted ViewerZone 1.9: Netzwerk• LAN des LeistungserbringersZone 1.1.1: Anwendungsdienste• Connectorservice, BrokerserviceZone 1.1.3: Basisdienste• KTS, KartenterminalserviceZone 1.14: Sicherheitssdienste• Trusted Viewer Service (TVS), SAK, TicketserviceZone 1.1.6: Netzwerk(WAN)• WANKap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 148 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02336 S Zonenzuordnung_Z2:Systeme der Zone 2 Zone 2.9: Zugangsnetzwerk• NetzwerkkomponentenZone 2.2: Öffentliche Dienste• Externes DNS, VPN GatewayVPN Gateway für MehrwertdiensteKap. 7Zone 2.3:Eingeschränkte Dienste• Broker Appl. Proxy• OCSP Responder• CRL Validation, CRL Provider Proxy und CRL ProviderBasisdienst• internes DNS, NTPZone 2.4.1 Benutzerindividuelle Dienste - ExterneDiensteBroker ServerZone 2.4.2: Benutzerindividuelle Dienste – InterneDiensteA_02337 S Zonenzuordnung_Z3:Systeme der Zone 3 Zone 3.1: AnwendungsdiensteKap. 7Zone 3.1: Anwendungsdienste• ADV, VfAZone 3.5: Infrastrukturdienste• DNS (root), NTP (Stratum 1), SDSZone 3.6: Sicherheitsdienste• Trusted Service, SVS, SCS• AuditS• OCSP, TSL, TCLgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 149 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleZone 3.7: Administration• Broker AdministrationZone 3.8: MonitoringA_02338 S Zonenzuordnung_Z4:Systeme der Zone4.A_02339 S Zonenzuordnung_Z5:Systeme der Zone5.• Systemmonitoring• Service Monitoring (Broker, Audit, DNS etc.)Zone 4.1: Anwendungsdienste• UFS, CAMS,• VODM,VSDM• AMTS, NFDMZone 4.5: Infrastrukturdienste• NTPZone 4.6: Sicherheitsdienste• Authentisierungsservice• Autorisierungsservice mit Ticketservice• Datenerhalt - UmschlüsselnZone 4.7: Administration• Administrationskomponenten• Treuhänder für DatenerhaltZone 4.8: Monitoring Komponenten der Fachdienste,CAMSZone 5 enthält existierende Stammdatensysteme derKostenträgerKap. 7Kap. 7A_02340 S Zonenzuordnung_Z6:Systeme der Zone6.Zone 6 enthält Systeme für Mehrwertdienste. Kap. 7A_02341 S Sicherheit_Ticket: Nur der Versichertedarf ein Ticket mit Berechtigungen fürLeistungserbringer zum Zugriff auf seine• Nur der Versicherte darf ein Ticket mit Berechtigungenfür Leistungserbringer zum Zugriff auf seine Versichertendatenvergeben. Zur Rechtevergabe dürfenKap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 150 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleVersichertendaten vergeben.A_02342 S Sicherheit_Ticket_1:Berechtigungsverwaltungkeine anderen Beteiligten notwendig sein bzw. zugelassenwerden.• Dem Versicherten muss unmissverständlich bewusstsein, dass er durch das Ausstellen und Signieren desTickets Berechtigungen an berechtigte Leistungserbringervergibt. Er muss sich darüber hinaus auch sichersein können, dass durch das Signieren keine andereAktion als die Rechtevergabe realisiert wird.• Das Ausstellen von Tickets muss vom Versichertenin gesicherten Umgebungen stattfinden, in denen erunbeobachtet und freiwillig Tickets für berechtigteLeistungserbringer ausstellen bzw. auch wieder löschenkann.BerechtigungsverwaltungDie Berechtigungsverwaltung MUSS vom Versichertenautark in einer zugelassenen Umgebung zur Wahrnehmungder Rechte des Versicherten durchgeführtwerden können.Konsequenzen• Versicherte DÜRFEN die Verwaltung von BerechtigungenNICHT an andere Personen delegieren.• Versicherten MUSS eine handhabbare Fachdienstübergreifende,logisch einheitliche Schnittstelle zurVerwaltung von Berechtigungen mit einer allgemeinverständlichen Oberflächengestaltung zur Verfügunggestellt werden.• Die Trennung der Ticketverwaltung von der Ticketnutzungdurch die Leistungserbringer MUSS für denVersicherten deutlich erkennbar sein.Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 151 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02343 S Sicherheit_Ticket_2:Durchgängige transparenteTrennung von Rechteverwaltungund RechtenutzungA_02344 S Sicherheit_Ticket_3:ServiceTicketsMÜSSEN vom Versicherten jederzeit gelöschtwerden können.A_02345 S Protokollierung_1: In den fachlichen ProtokollenMUSS mindestens protokolliertwerden „WER“, „WANN“, „WAS“ ausgeführthat.A_02346 S Protokollierung_2:Die Dauer der Speicherungder Protokollierungen richtet sichnach den relevanten gesetzlichen VorgabenA_02347 S Protokollierung_3:Grundsätzlich MUSSdie Protokollierung dem Prinzip der DatensparsamkeitgenügenDurchgängige transparente Trennung von Rechteverwaltungund RechtenutzungDie Verwaltung von im Ermessen des Versichertenstehenden Rechten MUSS informationstechnischdurchgängig von der Nutzung der §291a Anwendungendurch die Leistungserbringer getrennt sein.Konsequenzen• Im Konnektor und in Fachdiensten MUSS die Rechteverwaltungs-und Kerndienst-Schnittstelle getrenntwerden.ServiceTicketsServiceTickets MÜSSEN vom Versicherten jederzeitgelöscht werden können. Die mit dem ServiceTicketverbundenen Berechtigungen MÜSSEN dann demBerechtigten sofort entzogen werden.In den fachlichen Protokollen MUSS mindestens protokolliertwerden „WER“, „WANN“, „WAS“ ausgeführthat. Medizinische Daten DÜRFEN in den ProtokollenNICHT – auch nicht verschlüsselt – gespeichert werden.Die Dauer der Speicherung der Protokollierungen richtetsich nach den relevanten gesetzlichen Vorgaben.Es MUSS hierbei sichergestellt sein, dass auf der eGKmindestens die letzten 50 Zugriffe gespeichert sindGrundsätzlich MUSS die Protokollierung dem Prinzipder Datensparsamkeit genügen. Es MUSS sichergestelltsein, dass nur die unbedingt notwendigen Datenprotokolliert werden.Weiterhin MÜSSEN grundsätzlich gesetzliche Anforderungenerfüllt werden, das inkludiert u.a. auch die Anforderungenaus dem BundesdatenschutzgesetzKap. 7Kap. 7Kap. 7Kap 7.Kap 7.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 152 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02348 S Protokollierung_eGK Zur Datenschutzkontrolle MÜSSEN auf der eGK mindestensdie letzten 50 Zugriffe der dem informationellenSelbstbestimmungsrecht des Versicherten unterliegendenDaten protokolliert werden.Die Protokollierungseinträge werden vom Konnektorerstellt. Die Voraussetzung für das Schreiben einesRecords ist eine erfolgreiche C2C-Authentifikation miteiner SMC oder einem HBA.Über die für die Versicherten unentgeltlich zur Verfügungzu stellenden eKioske MUSS die Einsicht auf dieProtokolleinträge auf der eGK verständlich und übersichtlichmöglich sein.A_02349 S Versichertenzentrierter_Audit_1:VersichertenindividuelleVerschlüsselung.A_02350 S Versichertenzentrierter_Audit_2: Datenzusammenführungund getrennte Verarbeitung.Der Auditdienst stellt eine fachliche Protokollierungdar. Er MUSS die Einträge versichertenzentriert speichernund versichertenindividuell verschlüsseln.Die notwendigen Auditdaten MÜSSEN in der Telematikinfrastrukturgrundsätzlich so übertragen bzw. gespeichertwerden, dass eine Zusammenführung vonEreignissen unterschiedlicher Versicherter bzw. Profilbildungnicht möglich ist (Generelle Grundlage BDSG§9 und Anhang B).Die protokollierten Zugriffe für Datenschutzzweckewerden dem Versicherten unabhängig vom Speicherortin einer allgemein verständlichen, übersichtlichenForm angezeigt. Dabei gilt:• Es MÜSSEN die versichertenzentrierten Auditinformationenverschiedener Fachdienste für einen Versichertenzusammengeführt werden.• Es MÜSSEN die zu unterschiedlichen Anwendungenerhobenen Auditinformationen getrennt verarbeitet undggf. dargestellt werden können.Kap. 7Kap 7.Kap 7.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 153 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02351 S Versichertenzentrierter_Audit_3: Zweckbindungder DatenA_02352 S Technische_Protokollierung_1: BetreiberMÜSSEN jeweils lokal eine technischeProtokollierung (Logging) durchführenA_02353 S Zeitstempel_Synchronisation: Synchronisationinnerhalb der Telematikinfrastruktur/ interne SynchronisationA_02354 S Zeitstempel_False_Ticker: Erkennungvon False_Ticker.A_02355 S Zeitstempel_False_Speaker: Erkennungvon False_SpeakerDem Versicherten MÜSSEN Möglichkeiten zur unbeobachtetenEinsichtnahme in das Zugriffsprotokoll angebotenwerden.Die Zweckbindung der Daten (Anlage zu §9, Satz 1,Nummer 8, BDSG) ist auch bei der Zusammenführungder Auditdaten für einen Versicherten insoweit zu beachten,dass zumindest eine getrennte Anzeige nachden unterschiedlichen Anwendungen ermöglicht wirdBetreiber MÜSSEN jeweils lokal eine technische Protokollierung(Logging) durchführen. Diese Protokollierunghat das Ziel im Fehlerfall Fehler erkennen undbeheben zu können.Diese technische Protokollierung umfasst einerseitsdas Systemprotokoll, in dem Logmeldungen des Gesamtsystemsprotokolliert werden und andererseitsspezielle Logs einzelner Applikationen, z. B. Logs derFirewall oder des VPN-KonzentratorsZeitstempel_Synchronisation:Synchronisation innerhalb der Telematikinfrastruktur /interne Synchronisation. Systemkomponenten MÜS-SEN ihre Uhrzeit regelmäßig prüfen und gegebenenfallsaktualisierenZeitstempel_False_Ticker:Um robust gegenüber diesem Fehler (False Ticker) zusein, MÜSSEN mindestens 3 Stratum-2-Server eingesetztwerden. Die Stratum-1 Server können einfachausgelegt sein, da die Stratum-2 Server untereinanderals Peers fungierenZeitstempel_False_Speaker :Es wird gefordert, dass genau ein „False Speaker“erkannt werden muss. Deshalb MÜSSEN – da Kon-Kap 7.Kap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 154 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellenektoren nur auf Stratum-2 Zeitserver zugreifen können– mindestens 4 Stratum-2 Zeitserver eingesetztwerden.A_02356 S Zeitstempel_Redundanz Zeitstempel_Redundanz:Im Falle redundanter RZ-Standorte MUSS an jedemStandort eine minimale Anzahl von 3 Stratum-2 Zeitservernverfügbar sein(d. h. „False Ticker“ MÜSSEN beim Ausfall einesStandortes oder der Verbindung zwischen diesenStandorten von nach gelagerten Systemen noch identifizierbarbleiben).A_02357 S Zeitstempel_Korrekturtzeit: maximaleZeitabweichungAbweichung.A_02358 S Krypt_TI: Kryptographischen AnforderungenA_02359A_02360AS-Krypt-01AS-Krypt-02SKrypt-01: Stand der Technik und BSI TR-03116Zeitstempel_Korrekturtzeit :Außer beim initialen Setup DARF die im Rahmen derSynchronisation empfangene Zeit NICHT um mehr als±5 Minuten von der aktuellen Zeit im aktiven KonnektorabweichenEs MÜSSEN die kryptographischen Anforderungenund festgelegten Algorithmen der gematik vom Keymanagementder verwendeten Schlüssel in jeder Phasedes Lebenszyklus der Schlüssel mindestens eingehaltenoder sogar übertroffen werdenFür kryptographische Operationen in der TelematikinfrastrukturMÜSSEN stets nach dem Stand derWissenschaft und Technik geeignete Algorithmen undParameter entsprechend der Technischen Richtliniedes BSI [BSI TR-03116] eingesetzt werden.S Krypt-02: Jährliche Anpassung Die Liste der in der Telematikinfrastruktur verwendbarenAlgorithmen MUSS von der gematik mindestenseinmal jährlich und bei Bedarf (z. B. bei neuen wissenschaftlichenErkenntnissen bzw. bei Änderungen in[BSI TR-03116]) überprüft und ggf. angepasst werdenKap. 7Kap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 155 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02361A_02362A_02363A_02364AS-Krypt-03Die Hard- und Softwarearchitektur MUSS den Austauschkryptographischer Algorithmen und Parametererlauben und eine Migrationsfähigkeit zur Anpassungen,u. a. bei Änderungen von [BSI TR-03116], vorsehen.Die Kommunikations-Protokolle bzw. SicherheitskomponentenMÜSSEN so gestaltet sein, dass ein Erzwingendes Einsatzes von Algorithmen oder Parametern,deren Sicherheitseignung nicht mehr gegeben ist,AS-Krypt-04AS-Krypt-05AS-Krypt-06SSKrypt-03: Austausch von Algorithmen undParameternKrypt-04: Verhinderung der Nutzung vonnicht mehr freigegebenen Algorithmenund Parametern.nicht möglich ist.S Krypt-05: Migrationsphase. Während einer im Anlassfall zu definierenden ÜbergangsphaseMÜSSEN sowohl neue als auch alte Algorithmenund Parameter verarbeitet werden können.Hinweis: Eine Anpassung der Schlüssellänge/Tauschdes Algorithmus jedes eingesetzten Verfahrens sollteinnerhalb von 6 Monaten für alle im Einsatz befindlichenSchlüssel/Verfahren möglich sein. Während dieserÜbergangsphase müssen sowohl neue als auchalte Schlüssel/Verfahren verarbeitet werden können.[Welche Vorlaufzeit tatsächlich benötigt wird, kann imEinzelfall bewertet und entschieden werden. Die technischeLösung muss aber eine Anpassung innerhalbdieses Zeitraums ermöglichen. Die Laufzeiten von ggf.zu tauschenden Karten sind in diesen 6 Monaten nichtenthalten]SKrypt-06: Neuverschlüsselung und Anchsignatur.Übersteigt die Lebensdauer kryptographisch behandelterDaten die Dauer der Sicherheitseignung der eingesetztenAlgorithmen und Parameter so MÜSSEN dieDaten vor dem Ablauf der Sicherheitseignung durcheine erneute Verschlüsselung bzw. Nachsignatur entsprechendgeschützt werdenKap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 156 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02365A_02366AS-Krypt-07AS-Krypt-08SKrypt-07: Migrationsfähigkeit von Algorithmen.Alle Sicherheitskomponenten SOLLEN für jedes kryptographischePrimitiv die notwendige Migrationsfähigkeitvon Algorithmen unterstützen. Nähere VorgabenSOLLEN in den jeweiligen Einsatzumgebungen dereinzelnen Anwendungsbereiche festgelegt werdenS Krypt-08: KEY lifecycle nach ISO 11770. Für jeden Schlüssel MÜSSEN die relevanten Abläufewährend des kompletten Lebenszyklus festgelegt werden.Der Lebenszyklus eines Schlüssels umfasst nachISO 11770 Erzeugung (Generation), Aktivierung (Activation)mit Installation jeweils optional Zertifikatserzeugung,Schlüsselableitung, Schlüsselverteilung,Registrierung des Schlüssels/Zertifikats, Speicherungdes Schlüssels, sowie Deaktivierung (Deactivation),Reaktivierung (Reactivation) und Zerstörung desSchlüssels (Destruction).A_02367 S Anonymisierung_Pseudonymisierung_01:Die Telematikinfrastruktur ist daher so zugestalten, dass sie möglichst keinen Personenbezugund auch keine Personenbeziehbarkeitaufweist.A_02368 S Anonymisierung_Pseudonymisierung_02:AllgemeinMUSS die Zuordnung der Daten einesVersicherten in der Telematikinfrastrukturzu der Identität des Versicherten sichergestelltwerdenDie Telematikinfrastruktur MUSS so gestaltet werden,dass sie möglichst keinen Personenbezug und auchkeine Personenbeziehbarkeit aufweist (AD-GA-01).Von den Möglichkeiten der Anonymisierung und Pseudonymisierungist Gebrauch zu machen, soweit diesmöglich ist und der Aufwand in einem angemessenenVerhältnis zu dem angestrebten Schutzzweck steht.Allgemein MUSS die Zuordnung der Daten eines Versichertenin der Telematikinfrastruktur zu der Identitätdes Versicherten sichergestellt werden.Auch bei dem Wechsel der kryptographischen Identität(Kartenwechsel) MUSS dieser Bezug erhalten bleibenund es dürfen keine medizinischen Daten des Versichertenverloren gehen.Kap. 7Kap. 7Kap 7.Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 157 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02369 S Anonymisierung_Pseudonymisierung_03:Die Gestaltung der Telematikinfrastrukturmuss jedoch den Schutz der Daten in derTI vor missbräuchlicher Verwendung berücksichtigen.A_02370 S Pseudonymisierung_Pflichanwendungen_01: Eindeutigkeit derPseudonymeA_02371 S Pseudonymisierung_Pflichanwendungen_02: Pseudonymisierungin VSDD und VODD.Die Gestaltung der Telematikinfrastruktur muss jedochden Schutz der Daten in der TI vor missbräuchlicherVerwendung (AD-GA-32) berücksichtigen. Es dürfendurch die Verwendung der TI keine zusätzlichen Informationenund Profilbildungen über Versicherte undLeistungserbringer entstehen und verwendet werden.Zu diesem Zweck werden folgende Maßnahmen realisiert:• Pseudonymisierung der Datenhaltung und des Datenzugriffsbei den Pflichtanwendungen,• Der Zugriff und die Ablage der Daten in den freiwilligenAnwendungen erfolgt unter dem lebenslang eindeutigenTeil der Krankenversicherungsnummer,Anonymisierung des Leistungserbringerbezugs imBroker beim Zugriff auf die Fachdienste insbesonderedes VSDDPseudonymisierung/Pflichtanwendungen:Nach Erzeugung des Pseudonyms MUSS geprüftwerden, ob dieses Pseudonym vom Kartenherausgeberbereits vergeben wurde. Ist dies der Fall, DARFdieses Pseudonym NICHT verwendet werden. DiePseudonyme bei einem Kartenherausgeber MÜSSENeindeutig sein und es DARF NICHT zu Kollisionengegen aktuell verwendete Pseudonyme in der Telematikinfrastrukturkommen. Dem Versicherten MUSS daherauch bei einem Kartenwechsel ein neues Pseudonymzugewiesen werdenVSDD und VODD: Zugriffskriterium ist das Pseudonym.Die Daten in VSDD und VODD MÜSSEN soverschlüsselt werden, dass eine Zuordnung KVNR zuPseudonym in diesen Diensten NICHT MÖGLICH ist.Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 158 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02372 S Pseudonymisierung_Pflichanwendungen_03: Hinweispflicht.A_02373 S Pseudonymisierung_Pflichanwendungen_04: Löschung ungültigerVerordnungen.A_02374 S Pseudonymisierung_Pflichanwendungen_05: Verhinderungvon Profilbildung im UFS.A_02375 S Pseudonymisierung_Pflichanwendungen_06: Verhinderungvon Profilbildung durch OCSPDer Kartenherausgeber MUSS sicherstellen, dass dieAuflösung des Pseudonyms nur von ausgewähltenPersonen mit Einbeziehung des Datenschutzbeauftragtender Kasse möglich ist. Damit wird eine Profilbildungweitgehend mit organisatorischen Maßnahmenausgeschlossen..Pseudonymisierung/Pflichtanwendungen:Die Versicherten MÜSSEN – insbesondere bei regulärenKartenwechseln - darauf hingewiesen werden,dass noch vorhandene Verordnungen eingelöst werdensolltenPseudonymisierung/Pflichtanwendungen:Der VODD muss ungültige und nicht mehr verwendbareVerordnungen selbständig löschen (siehe [BDSG]und Grundsatz der Datenqualität in [Dat07]).Pseudonymisierung/Pflichtanwendungen:UFS: Eine Online-Verfolgung und Profilbildung derAktivitäten der Versicherten DARF bei UFS-AnfragenNICHT erfolgen. Die Daten im UFS MÜSSEN so geschütztwerden, dass eine Zuordnung der KVNR zumPseudonym nicht möglich ist und die Kasse MUSSsicherstellen, dass die Auflösung des Pseudonyms nurvon ausgewählten Personen mit Einbeziehung desDatenschutzbeauftragten möglich ist. Damit wird eineProfilbildung weitgehend mit organisatorischen MaßnahmenausgeschlossenPseudonymisierung/Pflichtanwendungen:OCSP: Eine Online-Verfolgung und Profilbildung derAktivitäten der Versicherten DARF bei Gültigkeitsabfragenvon pseudonymen VersichertenzertifikatenNICHT erfolgen. Die Daten MÜSSEN so gespeichertKap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 159 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02376 S Pseudonymisierung_Pflichanwendungen_07: Nachweis derWirksamkeit.A_02377 S Pseudonymisierung_Freiwillige_Anwendungen_01:VerhinderungvonProfilbildung durch OCSP.A_02378 S Pseudonymisierung_Freiwillige_Anwendungen_02:VerhinderungvonProfilbildung.A_02379 S Pseudonymisierung_Freiwillige_Anwendungen_03: Vermeidungder Zwischenspeicherung.und verarbeitet werden, dass eine Zuordnung KVNRzu Pseudonym nicht möglich ist. Dabei sind auch zeitlicheKorrelationen zwischen pseudonymen und personenbezogenenAnfragen eines Leistungserbringerszu berücksichtigen.Pseudonymisierung/Pflichtanwendungen:Die Wirksamkeit der getroffenen Maßnahmen MUSSim spezifischen Sicherheitskonzept dieser Dienste(VSDD,VODD,UDS,OCSP) gezeigt werdenPseudonymisierung_Freiwillige_AnwendungenOCSP: Eine Online-Verfolgung und Profilbildung derAktivitäten der Versicherten DARF bei Gültigkeitsabfragenvon persönlichen VersichertenzertifikatenNICHT erfolgenPseudonymisierung_Freiwillige_AnwendungenFachdienste: Die Fachdienste MÜSSEN sicherstellen,dass die gespeicherten und übertragenen Metadatennicht zu einer Profilbildung missbräuchlich vom Betreiberoder von Administratoren verwendet werden können.Eine Zusammenführung der Metadaten von zweiFachdiensten DARF NICHT möglich sein. Dies kann z.B. durch feingranulare Pseudonymisierung der gespeichertenDaten in jedem Fachdienst erreicht werden, sodass die Zugriffsschlüssel für die Datenbankenzugriffenicht zusammengeführt werden können.Pseudonymisierung_Freiwillige_Anwendungen:Die Zwischenspeicherung und Verwendung von personenbezogenenDaten in zentralen Komponenten derTelematikinfrastruktur aus betrieblichen ZweckenSOLL NICHT erfolgen z. B. IDS oder Behandlung vonKap. 7Kap. 7Kap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 160 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02380 S Pseudonymisierung_Freiwillige_Anwendungen_04:Nachweisder Wirksamkeit.A_02381 S Anonymisierung_Leistungserbringer:Verhinderung der Profilbildung durch A-nonymisierung des Leistungserbringers.A_02382 S Treuhänder_01: Keine Einschränkung derinformellen. SelbstbestimmungFehlersituationen. In begründeten AusnahmefällenMUSS der Datenschutzbeauftragte eingeschaltet unddie gematik informiert werden.Pseudonymisierung_Freiwillige_AnwendungenDie Wirksamkeit der getroffenen Maßnahmen MUSSim spezifischen Sicherheitskonzept(OCSP,Fachdienste, Telematikkomponenten) gezeigtwerden.Die Broker Services MÜSSEN für relevante Dienstedie Anonymisierung des Leistungserbringers in Nachrichtenvom Konnektor zum Fachdienst durchführen.Nach Prüfung der Nachrichtensignatur und der Rolledes Leistungserbringers durch den Broker ersetzt dieserdie Nachrichtensignatur durch die Signatur desBrokers. Lediglich nicht personenbezogene Informationenwerden aus dem signierenden Zertifikat übernommen,und an den Fachdienst weitergeleitet, wiezum Beispiel die Rolle des Handelnden. Durch diesesVorgehen wird die Identität des Leistungserbringersanonymisiert und eine Erstellung von Bewegungsprofilen(insbesondere durch den Kostenträger bzw. demBetreiber von Fachdiensten) ausgeschlossen.Möglich ist diese Anonymisierung für jeden Zugriff beidem die eGK anwesend ist. Daher SOLL für alleDienst-Zugriffe die Angemessenheit der Nutzung derim Broker vorhandenen Anonymisierungsfunktionalitätgeprüft werden.Die Rechte des Versicherten, insbesondere das Rechtauf informelle Selbstbestimmung, dürfen durch Treuhändernicht eingeschränkt werden. Dies bedeutetinsbesondere auch, dass der Treuhänder die ihm an-Kap. 7Kap. 7Kap 7.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 161 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellevertrauten Schlüssel und Daten Dritten nicht zugänglichund in keiner Weise exponieren darf.A_02383A_02384SSTreuhänder_02: Organisatorische unabhängigkeit.Treuhänder_03: Technischer und OrganisatorsicherSchutz der Datenobjekte unddes Schlüsselmaterials.Der Treuhänder muss organisatorisch unabhängig vonallen am Betrieb der Telematik Beteiligten sein, er darfalso weder in die Organisation der gematik, noch indiejenige eines Betreibers oder Kostenträgers eingebundenseinEs muss technisch und organisatorisch sichergestelltsein, dass der Schutz der Datenobjekte und desSchlüsselmaterials entsprechend den Vorgaben desSicherheitskonzeptes auch bei allen Prozessen, in dieder Treuhänder eingebunden ist, gewährleistet ist.Diese Prozesse dürfen zu keiner Erweiterung der MöglichkeitenDritter, auf diese Daten zuzugreifen führenKap. 7Kap. 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 162 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur8 Sicherheitsmanagement8.1 BegriffsbestimmungSicherheitsmanagement ist die Gesamtheit von Verfahren und Prozessen zur Aufrechterhaltungder primären Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit von Informationsobjektensowie der nachgeordneten Schutzziele Authentizität, Nachvollziehbarkkeitund Nichtabstreitbarkeit von Zugriffen Auf Basis eines Risikoansatzes umfasst Sicherheitsmanagementdie Planung, Implementierung, Überwachung und Verbesserung vonorganisatorischen und technischen Maßnahmen zur Informationssicherheit.Die Strategien und Konzepte des Sicherheitsmanagements sind ständig auf ihre Leistungsfähigkeitund Wirksamkeit zu überprüfen und bei Bedarf fortzuschreiben.Zu den Aufgaben des Sicherheitsmanagements gehören:• Festlegung der Sicherheitsziele, -strategien und –policies,• Festlegung der Sicherheitsanforderungen,• Ermittlung und Analyse von Bedrohungen und Risiken,• Festlegung geeigneter Sicherheitsmaßnahmen,• Überwachung der Implementierung und des laufenden Betriebes der selektiertenMaßnahmen,• Förderung des Sicherheitsbewusstseins sowie• Detektion von und Reaktion auf sicherheitsrelevante Ereignisse. (Security IncidentManagement; dieses soll in das allgemeine Incident Management eingebettetsein, welches möglichst nach ITIL eingebettet werden soll).Die Aktivitäten im Rahmen des Sicherheitsmanagements MÜSSEN in Anlehnung an ISO27001/27002:2005 gestaltet werden. Sowohl Dienstbetreiber, die Teile der Telematikinfrastrukturbetreiben, als auch die gematik MUSS ein Informationssicherheitsmanagementsystem(ISMS) implementieren. Auf dieser Basis soll die Verzahnung derProzesse und die Optimierung der Schnittstellen kontinuierlich verbessert werden.8.2 Sicherheitspolicy der Telematikinfrastruktur8.2.1 Definition und AbgrenzungFür die Telematikinfrastruktur wird seitens der gematik die Sicherheitspolicy der Telematikinfrastrukturherausgegeben, welche die grundlegenden Ziele, Strategien, Verantwortlichkeitenund Methoden für die Gewährleistung der Sicherheit festlegen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 163 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDiese Sicherheitspolicy der Telematikinfrastruktur ist eine Vorgabe, die durch die Sicherheitspoliciesaller Betreiber von Prozessen und Komponenten der Telematikinfrastrukturdetailliert und ergänzt wird.Bei der Verarbeitung von personenbezogenen Daten sind die Regelungen des BDSG,insb. auch § 11 (Auftragsdatenverarbeitung) zu beachten.8.2.2 GeltungsbereichDie Sicherheitspolicy der Telematikinfrastruktur erstreckt sich über die gesamte Telematikinfrastruktur.8.2.3 Inhalte, grundsätzliche Ziele und StrategienAufgabe der Sicherheitspolicy der Telematikinfrastruktur ist es, alle Aspekte einer sicherenNutzung der Informationstechnik abzudecken:• Das Dokument „Sicherheitspolicy der Telematikinfrastruktur“ bildet die Grundlagedes Sicherheitsmanagements.• Die Sicherheitspolicy der Telematikinfrastruktur legt Leitlinien fest, schreibtaber keine Implementierung vor.• Die Sicherheitspolicy der Telematikinfrastruktur wird offiziell verabschiedetund in Kraft gesetzt.• Jeder Beteiligte an der Telematikinfrastruktur muss Kenntnis über die wichtigstenInhalte der Sicherheitspolicy haben; die direkt mit der Sicherheit beschäftigtenMitarbeiter müssen im Besitz einer aktuellen Version der Sicherheitspolicysein, sie in Gänze kennen und ihr Arbeitsverhalten an denVorgaben der Policy ausrichten8.3 Delegation von VerantwortungDienstbetreiber, die Teile der Telematikinfrastruktur betreiben, tragen auch Verantwortungfür Risiken. In sofern wird die Verantwortung für Risiken von der gematik (normalerweiseprimär verantwortlich) an den Betreiber (sekundär Verantwortlicher) und von diesem ggf.wiederum an Dritte delegiert.In der Darstellung ist die Risikodelegation aus Gründen der Übersichtlichkeit auf drei E-benen beschränkt, in der Praxis kann es weitere Ebenen geben.Die Delegation der Verantwortung sowie die Übernahme dieser Risiken ist Bestandteil derentsprechenden Verträge zwischen den Verantwortlichen.Bezüglich der Delegation von Verantwortung wird der Begriff Assets (laut [ISO/IEC 13335-1:2004] „Anything that has Value to the Organisation“) auf „Informationsobjekt in Komponente“reduziert.Der Verantwortliche dokumentiert im Rahmen des entsprechenden Sicherheitskonzeptes,welche Risiken für die ihnen überantworteten Assets bestehen, und wie sie diesen Risikenbegegnen.Der Verantwortliche hat folgende Möglichkeiten, Risiken zu begegnen:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 164 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Minderung des Risikos durch technische und/oder organisatorische Maßnahmen:Der Verantwortliche setzt Maßnahmen um, die die Schadenshöhe oderdie Eintrittswahrscheinlichkeit von Schadensereignissen reduzieren.Die Wirksamkeitder getroffenen Maßnahmen ist nachzuweisen und regelmäßig imRahmen eines InternenKontrollSystems (IKS) zu überprüfen.• Minderung des Risikos durch Delegation: Der Verantwortliche delegiert Verantwortungan einen Dritten.• Minderung des Risikos durch Beschränkung: Der Verantwortliche schränkt dieNutzung des Assets ein, beispielsweise in dem das Asset in einer bestimmtenEinsatzumgebung nicht erlaubt und die Nutzung durch technische Maßnahmenausgeschlossen wird. Dieser Strategie sind durch vorgegebene SystemanforderungenGrenzen gesetzt.)• Akzeptieren als Restrisiko: Risiken, die nach Umsetzung der vorgenanntenOptionen noch bestehen, sind Restrisiken. Akzeptierte Restrisiken müssenstets an den Auftraggeber gemeldet und von diesem akzeptiert werden.•Da es keine weiteren Möglichkeiten gibt, kann leicht geprüft werden, ob alle Risiken einerdieser Kategorien zugeordnet wurden.Abbildung 22: Sicherheitspolicy und Risikomanagementgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 165 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur8.4 Organisation und VerantwortlichkeitenUm die im Sicherheitsmanagementprozess definierten Schritte zu managen, zu vollziehenund zu kontrollieren sowie alle in diesen Prozess involvierten Gruppen möglichst effizienteinzubinden, MÜSSEN Rollen und Verantwortlichkeiten festgelegt werden.8.4.1 Telematik-Informationssicherheit-Board (TIB)Das Sicherheitsboard hat die Aufgabe, die Gesellschaft bei der Gewährleistung des notwendigenSicherheitsniveaus der Telematikinfrastruktur und der Einhaltung der Vorschriftenzum Schutz personenbezogener Daten im Rahmen der Einführung und Anwendungder elektronischen Gesundheitskarte zu unterstützen.Dazu erörtern die Mitglieder des Sicherheitsboards Fragen des Datenschutzes und derInformationssicherheit, fördern einen regen Informationsaustausch und beraten die Geschäftsführung.Das Sicherheitsboard erfüllt seine Aufgaben in vertrauensvoller Zusammenarbeit mit denGesellschaftsorganen.Die Geschäftsordnung für das Sicherheitsboard der gematik regelt die Aufgaben, Zusammensetzungund Geschäftsprozesse des Sicherheitsboards.8.5 RisikomanagementprozessAuf Basis der von der gematik festgelegten Mindeststandards MUSS jeder Betreiber innerhalbder Telematikinfrastruktur seinen eigenen Risikomanagementprozess gestalten,mittels dessen er Schwachstellen erkennt und durch Maßnahmen mindert, das Restrisikobestimmt und die Verantwortung dafür übernimmt.Die vom Betreiber bestimmten Restrisiken müssen immer an die gematik gemeldet undvon dieser akzeptiert werden.8.5.1 VorgehensweiseDie wesentliche Aufgabe des Sicherheitsmanagements ist das Erkennen und Einschätzenvon Sicherheitsrisiken und deren Reduktion auf ein tragbares Maß; es bedient sich hierzudreier unterschiedlicher Ansätze:• Detaillierte Risikoanalyse• Grundschutzansatz• Kombinierter Ansatz8.5.2 Risikoanalysestrategien8.5.2.1 AllgemeinesEin methodisches Risikomanagement MUSS zur Erarbeitung eines vollständigen und alleBereiche der Telematikinfrastruktur betreffenden Sicherheitskonzeptes eingerichtet wer-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 166 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturden. Ziel ist es, das Risiko so weit zu reduzieren, dass das verbleibende Restrisiko quantifizierbarund akzeptierbar wird.In der Sicherheitspolicy eines jeden Betreibers MUSS die Risikoanalysestrategie festgelegtwerden. Des weiteren MUSS der Prozess zur Bewertung und zum Akzeptieren vonRestrisiken definiert werden.8.5.2.2 VariantenDie heute gängige Praxis kennt drei Hauptvarianten zur Risikoanalysestrategie:• GrundschutzansatzUnabhängig vom tatsächlichen Schutzbedarf werden für alle Systeme undApplikationen Grundschutzmaßnahmen eingesetzt.Dieser Ansatz orientiert sich im Wesentlichen an den Normen des BSI.• Detaillierte RisikoanalyseFür alle Systeme wird eine detaillierte Risikoanalyse durchgeführt; hierdurchwird gewährleistet, dass effektive und angemessene Sicherheitsmaßnahmengewählt werden.Dieser Ansatz orientiert sich im Wesentlichen an der Norm ISO/IEC 13335-3.• Kombinierter AnsatzIn einem ersten Schritt wird in einer Schutzbedarfsfeststellung (High LevelRisk Analysis) der Schutzbedarf für die einzelnen Systeme ermittelt.Für Systeme der Schutzbedarfskategorie „niedrig bis mittel“ wird von einerpauschalierten Gefährdungslage ausgegangen, so dass auf eine detaillierteRisikoanalyse verzichtet und eine Grundschutzanalyse durchgeführt werdenkann.Systeme der Schutzbedarfskategorie „hoch oder sehr hoch“ MÜSSEN einerdetaillierten Risikoanalyse unterzogen werden, auf deren Basis individuelleSicherheitsmaßnahmen ausgewählt werden.8.5.2.3 Akzeptables RestrisikoTrotz der Durchführung aller ausgewählten Sicherheitsmaßnahmen verbleibt im Allgemeinenein Restrisiko. In der Risiikoanalyse eines jeden Betreibers MÜSSEN diese akzeptablenRestrisiken so exakt wie möglich benannt werden.8.5.2.4 Vorgehensweise bei außergewöhnlichen RestrisikenVerbleibt nach Durchführung aller im Sicherheitsplan vorgesehenen Maßnahmen einRestrisiko, das höher ist als das generell akzeptierte und dessen weitere Reduktion nichtmöglich ist, so besteht in begründeten Ausnahmefällen die Möglichkeit einer bewusstenAkzeptanz des erhöhten Restrisikos.In der Sicherheitsvorschriften eines jeden Betreibers MÜSSENgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 167 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• das Vorgehen bei Risiken, die in Abweichung von der generellen Sicherheitsvorschriftenin Kauf genommen werden sollen, sowie• die Verantwortlichkeiten dafürfestgelegt werden.8.5.3 Detaillierte RisikoanalyseBei Systemen, auf denen Anwendungen mit hohem oder sehr hohem Schutzbedarf installiertsind, muss eine genaue Analyse der bestehenden Werte, Bedrohungen undSchwachstellen und damit eine detaillierte Risikoanalyse durchgeführt werden. - Hinweisezu diesem Verfahren finden sich etwa in ISO/IEC 13335-3, Anhang D sowie in BSI 7105,S. 199ff.Bei der Durchführung einer Risikoanalyse MÜSSEN folgende Prinzipien und Vorgehensweisenbeachtet werden:• Das gesamte Verfahren MUSS transparent gemacht werden.• Es DÜRFEN NICHT versteckte Annahmen gemacht werden, die etwa dazuführen, dass Bedrohungen unbetrachtet bleiben.• Alle Bewertungen MÜSSEN begründet werden, um subjektive Einflüsse zu erkennenund so weit wie möglich zu vermeiden.• Alle Schritte MÜSSEN so dokumentiert sein, dass sie später auch für anderenachvollziehbar sind.• Es MÜSSEN alle wesentlichen Bedrohungen erfasst werden.• Zu jeder Bedrohung MUSS die Eintrittswahrscheinlichkeit in Relation gesetztwerden.• Es MÜSSEN möglichst alle Schwachstellen des Systems in den BereichenOrganisation, Hard- und Software, Personal und Infrastruktur identifiziert undihre Bedeutung klassifiziert werden.• Risiken, denen die Telematikinfrastruktur ausgesetzt ist, MÜSSEN erkannt,dokumentiert und bewertet werden.• Jegliche Änderung an Werten, Bedrohungen, Schwachstellen oder SicherheitsmaßnahmenMUSS in ihrem Einfluss auf die Einzelrisiken und auf dasGesamtrisiko bewertet werden.8.5.4 GrundschutzanalyseDie Vorgehensweise zur Grundschutzanalyse muss den Vorgaben des BSI (IT-Grundschutzkatalogendes BSI, BSI GSHB) folgen. Eine Grundschutzanalyse genügt für die Ableitungder Schutzmaßnahmen von Datenobjekten mit niedrigem und mittlerem Schutzbedarf.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 168 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur8.5.5 Kombinierter AnsatzDie Zeit sparende Auswahl kostengünstiger Sicherheitsmaßnahmen durch Grundschutzanalysenund die wirksame Reduktion hoher Sicherheitsrisiken durch eine detaillierte Risikoanalysewird durch den kombinierten Ansatz erreicht:Hierbei wird zunächst ermittelt, welche Systeme hohe oder sehr hohe Sicherheitsanforderungen,und welche niedrige bis mittlere haben (Schutzbedarfsfeststellung). Das Ergebnisdieses Schrittes ist eine Einteilung in zwei Schutzbedarfskategorien: „niedrig bis mittel“sowie „hoch und sehr hoch“.Systeme der Schutzbedarfskategorie „niedrig bis mittel“ werden einer Grundschutzanalyseunterzogen, wohingegen die der Schutzbedarfskategorie „hoch und sehr hoch“ einerdetaillierten Risikoanalyse zu unterziehen sind, auf deren Basis dann individuelle Schutzmaßnahmenausgewählt werden.Aus Sicht der gematik muss mindestens der kombinierte Ansatz gewählt werden; derGrundschutzansatz ist aufgrund des hohen Schutzbedarfes nicht ausreichend..8.5.5.1 Vorgehensweise• Festlegung von SchutzbedarfskategorienAbweichend vom BSI GSHB, welches drei Schutzbedarfskategorien vorsieht,wird hier von nur zwei Kategorien ausgegangen: „niedrig bis mittel“, „hoch bissehr hoch“.• SchutzbedarfsfeststellungDie Schutzbedarfsfeststellung muss in drei aufeinander aufbauenden Schrittenerfolgen:oooErfassung aller vorhandenen oder geplanten SystemeErfassung der Applikationen und Zuordnung zu den einzelnen SystemenSchutzbedarfsfeststellung für jedes System• Akzeptables RestrisikoUm für die Telematikinfrastruktur ein konsistentes Niveau des Restrisikos zugewährleisten, wird dieser Prozess durch generelle Richtlinien unterstützt.Diese werden im Rahmen der Sicherheitspolicy der Telematikinfrastruktur definiertund legen fest, welche Risiken akzeptiert werden können.Der primär Verantwortliche ist immer über die akzeptierten Restrisiken zu informieren;er kann überprüfen, ob die Restrisiken gemäß Sicherheitspolicy derTI akzeptabel sind und hat diesbezüglich „das letze Wort“. Die Entscheidungüber die Akzeptanz von Restrisiken ist dabei immer eine für das spezielleSystem zu treffende Managemententscheidung.• Akzeptanz von außergewöhnlichen RestrisikenDie Entscheidung über die Akzeptanz eines außergewöhnlichen Restrisikosist durch das Management zu treffen; die genauen Verantwortlichkeiten dafürmüssen in der Sicherheitspolicy der Telematikinfrastruktur festgelegt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 169 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDer primär Verantwortliche ist immer über die außergewöhnlichen Restrisikenzu informieren; er entscheidet, ob diese tragbar sind, oder nicht.8.6 Spezifisches Sicherheitskonzept8.6.1 AbgrenzungUnter dem „Spezifischen Sicherheitskonzept“ wird hier das Sicherheitskonzept desBetreibers eines Dienstes der Telematikinfrastruktur verstanden; es soll somit unterschiedensein vom „Übergreifenden Sicherheitskonzept“.8.6.2 InhaltsübersichtDer Dienstbetreiber MUSS ein Sicherheitskonzept erstellen. Das SicherheitskonzeptMUSS die folgenden Kapitel umfassen:• Beschreibung des Dienstes (s. Abschnitt 8.6.3)• Sicherheitspolicy des Dienstes ((s. Abschnitt 8.6.4)• Schutzbedarf der Daten (s. Abschnitt 8.6.5)• Bedrohungsanalyse (s. Abschnitt 8.6.6)• Sicherheitsanforderungen der gematik (s. Abschnitt 8.6.7)• Sicherheitsmaßnahmen (s. Abschnitt 8.6.8)• Ablauforganisation (s. Abschnitt 8.6.9)• Besondere technische Komponenten (s. Abschnitt 8.6.10)• Schlüssel- und Zertifikatsmanagement (s. Abschnitt 8.6.11)• Wirksamkeit der Sicherheitsmaßnahmen (s. Abschnitt 8.6.12)• Erstellung einer Restrisikoabschätzung (s. Abschnitt 8.6.13)• Erstellung eines Notfallkonzepts (s. Abschnitt 8.6.14)• Einordnung in das Zonenkonzept der gematik (s. Abschnitt 8.6.15)• Verfahrenanweisungen zur nachhaltigen Wirksamkeitskontrolle der definiertenMaßnahmen (InternesKontrollSystem=IKS, Compliance Checks).• Aufstellung sicherheitsrelevanter Parameter, die im Rahmen eines technischenCompliance-Checks bzw. Integritätschecks überwacht werden müssen.• Aufstellung und Klassifikation von Logfile-Einträgen, die im Rahmen des SecurityIncidentManagemntbearbeitet werden müssen.Die konkreten Anforderungen zu den einzelnen Kapiteln werden in den nachfolgendenAbschnitten erläutert.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 170 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDem Dienstanbieter ist es freigestellt, das Sicherheitskonzept um weitere Kapitel zu ergänzen,sofern er dies für seinen Betrieb als vorteilhaft ansieht. Der Dienstbetreiber mussdieses Sicherheitskonzept fortschreiben.Der Dienstanbieter muss den RFC 2119 (Begriffsbestimmungen zu MUSS, DARF, SOLL,KANN, etc.) berücksichtigen.8.6.3 Beschreibung des DienstesDer Dienstanbieter kann in seinem Sicherheitskonzept zur Beschreibung des Dienstes aufdie entsprechenden Spezifikationen der gematik verweisen.Ergänzende, die Umsetzung betreffende Festlegungen des Dienstanbieters MÜSSENbeschrieben werden.8.6.4 Spezifische SicherheitspolicyUnter spezifischen Sicherheitspolicies werden hier wie im Folgenden die dienstspezifischenSicherheitsleitlinien des Dienstanbieters verstanden. Sie sind keinesfalls zu verwechselnoder gar gleichzusetzen mit der oben beschriebenen Sicherheitspolicy der Telematikinfrastruktur.8.6.4.1 Aufgaben und ZieleEine spezifische Sicherheitspolicy für einen Dienst stellt ein Basisdokument dar, in demdie grundlegenden Vorgaben und Leitlinien zur Sicherheit eines Dienstes definiert werden.8.6.4.2 InhalteEine spezifische Sicherheitspolicy für ein System bzw. eine Applikation muss Aussagenzu folgenden Bereichen treffen:• Definition und Abgrenzung des Dienstes• Beschreibung der wichtigsten Komponenten• Definition der wichtigsten Ziele und Funktionalitäten• Festlegung der Sicherheitsziele• Abhängigkeiten der Sicherheit der Telematikinfrastruktur von dem betrachtetenDienst• Risikoanalysestrategie• Verantwortlichkeiten für die Erstellung und Umsetzung des Sicherheitskonzeptes8.6.4.3 Fortschreibung der spezifischen SicherheitspolicyDie spezifische Sicherheitspolicy muss regelmäßig aktualisiert und bei Bedarf entsprechendangepasst werden. Sie ist mindestens jährlich zu überprüfen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 171 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur8.6.5 Schutzbedarf der Daten8.6.5.1 Vordefinierte SchutzobjekteIm Anhang C wird für ausgewählte Daten und Komponenten (Schutzobjekte) der Telematikinfrastruktureine Schutzbedarfsfeststellung vorgenommen.Die Schutzobjekte werden hinsichtlich der Kriterien• Vertraulichkeit• Integrität• Verfügbarkeit• Authentizität• Nichtabstreitbarkeiteingestuft. Sofern von einem Infrastrukturdienst grundsätzlich sehr hohe Verfügbarkeitverlangt wird, ist der Punkt Verfügbarkeit nicht für jedes einzelne Schutzobjekt zu betrachten.Im Übrigen wird darauf hingewiesen, dass die Fragen zur Verfügbarkeit nicht im Sicherheitsprofilsondern bei den nichtfunktionalen Anforderungen betrachtet werden.Im Sicherheitskonzept des Dienstanbieters MUSS für jedes Schutzobjekt aus Anhang Cerläutert werden, ob und wie der Dienstanbieter aktiv zum Schutz des Schutzobjekts beiträgt.Beispiele:• Ein Schutzobjekt ist der private Entschlüsselungsschlüssel des Versicherten.Da ein Dienstanbieter mit diesem Schlüssel nicht in Berührung kommt, trägtder Dienstanbieter nicht zum Schutz dieses Schutzobjekts bei. Er kann imFolgenden unberücksichtigt bleiben.• Ein Schutzobjekt sind die Notfalldaten. Da die Infrastrukturdienste die Notfalldatenentweder verschlüsselt durchreichen oder gar nicht mit ihnen in Berührungkommen, tragen diese Dienstanbieter zum Schutz der Notfalldaten nichtbei. Sie können im Folgenden unberücksichtigt bleiben.Als Ergebnis dieses Abschnitts ergibt sich, zu welchen der vordefinierten Schutzobjekteder Infrastrukturdienst aktiv beiträgt. Die Angemessenheit der Schutzmaßnahmen für dieseSchutzobjekte ist in den Folgekapiteln des Sicherheitskonzepts zu begründen.8.6.5.2 Selbst definierte SchutzobjekteNeben den durch die gematik vordefinierten Schutzobjekten müssen dienstspezifisch weitereSchutzobjekte identifiziert werden, die in dem Sicherheitskonzept zu berücksichtigensind.8.6.6 BedrohungsanalyseDer Dienstanbieter MUSS in seinem Sicherheitskonzept eine Bedrohungsanalyse gegenüberden in Abschnitt 8.6.5 beschriebenen Schutzobjekten vornehmen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 172 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDa manche Bedrohungen gegen die in Abschnitt 8.6.5 beschriebenen Schutzobjekte bereitsdurch Sicherheitsmaßnahmen abgewehrt werden, die nicht durch den Infrastrukturdienst,sondern durch andere Stellen der Telematikinfrastruktur abgewehrt werden, kannder Dienstanbieter schon an dieser Stelle darauf verweisen, dass eine solche Bedrohungnicht zum Tragen kommt. In diesem Fall muss sie im Folgenden nicht weiter betrachtetwerden.Die Nicht-Relevanz ist im Zweifelsfall zu bergründen.Beispiel für eine solche Bedrohung ist die unbefugte Kenntnisnahme von elektronischenRezepten durch den Brokerdienst. Da der Brokerdienst die medizinischen Inhalte eineselektronischen Rezepts verschlüsselt erhält und über keine Schlüssel zur Entschlüsselungverfügt, ist die Bedrohung der unbefugten Kenntnisnahme bereits durch die äußere Telematikinfrastrukturabgewehrt.8.6.7 Sicherheitsanforderungen der gematikDie gematik hat eine eigene Bedrohungsanalyse für die Telematikinfrastruktur vorgenommen,welche für Anbieter auszugsweise (und ohne Anspruch auf Vollständigkeit) verfügbarist.Aus dieser Bedrohungsanalyse hat die gematik Sicherheitsanforderungen abgeleitet, diedurch den Dienstanbieter einzuhalten sind. Die übergreifenden Sicherheitsanforderungensind vorwiegend im Anhang B – Sicherheitsanforderungen und Anhang G – SicherheitsanforderungenBetrieb dieses Dokumentes enthalten.In das Sicherheitskonzept des Dienstanbieters sind alle Sicherheitsanforderungen ausdeM übergreifendeN Sicherheitskonzept der Telematikinfrastruktur aufzunehmen undderen Umsetzung bzw. Einhaltung im Folgenden zu dokumentieren.8.6.8 Sicherheitsmaßnahmen8.6.8.1 Auswahl von MaßnahmenEs MUSS eine Liste existierender bzw. geplanter Sicherheitsmaßnahmen unter Berücksichtigungder Ergebnisse der Risikobewertung erstellt werden. Dabei SOLL auf die Ausgewogenheitvon technischen und nicht-technischen Maßnahmen geachtet werden.Der Dienstanbieter MUSS die folgenden Punkte dokumentieren:• Organisatorische Sicherheitsmaßnahmen, z. B. organisatorische Regelungenzum IT-Sicherheitsmanagement, zur Datensicherung, zur Intrusion Detectionoder zum Virenschutz• Personelle Sicherheitsmaßnahmen, insbesondere die Verfahren zur Beurteilungund Sicherstellung der Zuverlässigkeit und Fachkunde des Personals• Infrastrukturelle Sicherheitsmaßnahmen wie bauliche Sicherheit (z.B. Vereinzelungsschleusen,Tresore) sowie die organisatorischen Aspekte der baulichenSicherheit ( z. B. Wachdienste),• Netzwerksicherheit einschließlich Intrusion Detection, Virenschutz, etc.• Sicherheit der IT-Systeme• Administration, Wartung, Pflege der IT-Systemegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 173 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Zugriffskontrolle, Beweissicherung, Protokollauswertung, etc.8.6.8.2 Bewertung der MaßnahmenEs MUSS eine Bewertung der Sicherheitsmaßnahmen erfolgen, welche mindestens Aussagenzu folgenden Punkten enthält:• Erfassung aller Bedrohungen gegen die die ausgewählten Maßnahmen wirken,• Beschreibung der Auswirkungen der Einzelmaßnahmen,• Beschreibung des Zusammenwirkens der ausgewählten und der bereits vorhandenenMaßnahmen,• Überprüfung, ob und inwieweit die Maßnahmen zu Behinderungen beim laufendenBetrieb führen können,• Überprüfung der Vereinbarkeit der Maßnahmen mit geltenden rechtlichenVorschriften und Richtlinien und• Bewertung, in welchem Ausmaß die Maßnahmen eine Reduktion der Risikenbewirken.8.6.9 AblauforganisationIm Kapitel zur Ablauforganisation hat der Dienstanbieter die folgenden Punkte zu behandeln:• Beschreibung der sicherheitsrelevanten Abläufe• Einhaltung des 4-Augen-Prinzip, falls erforderlich• Beschreibung zur Einhaltung der Genehmigungsverfahren8.6.10 Besondere technische KomponentenFür ausgewählte Aufgaben muss der Dienstanbieter technische Komponenten einsetzen,deren Sicherheit überprüft wurde. Im Einzelnen handelt es sich dabei beispielsweise um• die VPN-Konzentratoren,• die Firewalls,• die Hardware-Sicherheitsmodule zum Schutz kryptographischer Schlüssel,• die technischen Komponenten, die besonders sicherheitsrelevante Vorgängeder einzelnen Dienste umsetzen (z. B. die Signaturprüfung und Anonymisierungdurch den Broker oder der lesende Zugriff auf den Audit-Service).Die Anforderungen an die VPN-Konzentratoren und an die technischen Komponenten, diebesonders sicherheitsrelevante Vorgänge der einzelnen Dienste umsetzen (z. B. die Signaturprüfungund Anonymisierung durch den Broker), sind in den Sicherheitsanforderungender entsprechenden Dienste bzw. Netze enthalten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 174 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturIm Kapitel zu den technischen Komponenten MUSS der Dienstanbieter die folgendenPunkte behandeln:• Übersicht über die eingesetzten Produkte, welche die oben genannte Sicherheitsfunktionalitätumsetzen• Nachweis der Sicherheitsüberprüfungen dieser Produkte gemäß den Anforderungender gematikSofern die Sicherheitsbegutachtungen, z. B. Evaluierung nach Common Criteria (CC),besondere Anforderungen an die Einsatzumgebungen stellen, hat der Dienstanbieter zuerläutern, wie er diese Anforderungen umgesetzt hat.8.6.11 Schlüssel- und ZertifikatsmanagementFür alle kryptographischen Schlüssel und Zertifikate, die der Dienstanbieter zur Absicherungseines Dienstes oder Netzes einsetzt, MUSS der Dienstanbieter mindestens die folgendenInformationen in sein Sicherheitskonzept aufnehmen:Symmetrische Schlüssel• Verwendungszweck des Schlüssels, z. B. MAC-Sicherung von Protokolldaten• Zugehöriger kryptographischer Algorithmus, z. B. Triple-DES im CBC-Mode• Schlüssellänge (ggf. nach Zeiträumen gestaffelt)• Anzahl der Versionen (gemeint ist die Anzahl der Versionen und nicht die Anzahlder Stellen, an denen dieser Schlüssel gespeichert wird; z. B. eineSchlüsselversion pro Kalenderjahr, eine Schlüsselversion pro Chipkarte etc.)• Erzeugung (anzugeben ist, wo und durch wen der Schlüssel erzeugt wird)• Speicherung (anzugeben ist, an welchen Stellen der Schlüssel gespeichertwird)• Verteilung (anzugeben ist, wie der Schlüssel gesichert von dem Ort seiner Erzeugungzu dem Ort seiner Speicherung gelangt)• Schlüsselwechsel (anzugeben ist, in welchen Rhythmen der Schüssel gewechseltwird; ein Schlüsselwechsel bedeutet nicht automatisch, dass der alteSchlüssel ungültig wird)• Löschen des Schlüssels• Gültigkeitsdauer des SchlüsselsPrivate asymmetrische Schlüssel• Angaben wie für symmetrische Schlüssel, nur ohne Gültigkeitsdauer (die Gültigkeitsdauerwird über das Zertifikat bestimmt)Öffentliche asymmetrische Schlüssel• Verwendungszweck (s. symmetrische Schlüssel)• Speicherung (s. symmetrische Schlüssel)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 175 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZertifikate• Verteilung (s. symmetrische Schlüssel)• Herausgeber des Zertifikats• Erzeugung des Zertifikats (anzugeben ist, wo und durch wen das Zertifikat erzeugtwird)• Speicherung (s. symmetrische Schlüssel)• Verteilung (s. symmetrische Schlüssel)• Sperrung (anzugeben ist, wer die Berechtigung zur Sperrung dieses Zertifikatsbesitzt)• Gültigkeitsdauer des Zertifikats• Für alle vertraulichen Schlüsselmittel ist zu dokumentieren, wie die Vertraulichkeitbei Transport und Speicherung gewährleistet wird.• Bei Schutzanforderungen bzgl. Integrität ist zu dokumentiren, wie die Integritätbei Transport und Speicherung gewährleistet wird.8.6.12 Wirksamkeit der SicherheitsmaßnahmenDie Dienstanbieter MUSS in seinem Sicherheitskonzept die Wirksamkeit der Sicherheitsmaßnahmenerläutern.Hierzu MUSS der Dienstanbieter erklären, welche Sicherheitsmaßnahmen den in Abschnitt8.6.6 genannten Bedrohungen entgegenwirken.Ferner MUSS der Dienstanbieter erklären, welche Sicherheitsmaßnahmen die in Abschnitt8.6.7 genannten Sicherheitsanforderungen umsetzen.8.6.13 Erstellung einer RestrisikoabschätzungDer Dienstanbieter muss eine Restrisikoabschätzung vornehmen. Darin MUSS derDienstanbieter die verbleibenden Risiken darstellen und bewerten. Insbesondere MUSSer begründen, warum die verbleibenden Risiken akzeptabel sind.Hierzu MUSS der Dienstanbieter die Restrisiken aufzählen und eine Einstufung dieserRestrisiken in die Risikoklassen vornehmen.RisikoklasseUntragbarBeschreibungTabelle 26: RisikoklassenDer Eintritt dieses Ereignisses ist mit hoher Wahrscheinlichkeitexistenzbedrohend. Eine Akzeptanz dieses Risikos ist ausgeschlossen.Eine Risikoreduktion durch spezielle Maßnahmen istnotwendig, Überlegungen zu systemischen Risiken und strategischenMaßnahmen sind angeraten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 176 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturRisikoklasseSehr hochHochGeringVernachlässigbarBeschreibungEs ist dringender Handlungsbedarf gegeben. Eine auf einer Kosten/Nutzen-Bewertungder Sicherungsmaßnahmen basierendeAkzeptanz des Risikos bedarf einer breiten Zustimmung unter autorisiertenEntscheidungsträgern. Der Eintritt des Ereignisses hatsignifikante negative Auswirkungen. Eine existenzbedrohendeSituation kann nicht vollständig ausgeschlossen werden. Eine Risikoreduktiondurch Maßnahmen des Grundschutzes sowie durchspezielle Maßnahmen ist notwendig.Es ist Handlungsbedarf gegeben. Im Rahmen einer Kosten/Nutzen-Bewertungder zu setzenden Sicherungsmaßnahmenkönnte das Risiko aber auch getragen werden. Eine beträchtlichnegative Auswirkung kann nicht vollständig ausgeschlossen werden,eine existenzbedrohende Situation scheint aber nicht möglich.Eine Risikoreduktion, mindestens durch Maßnahmen des IT-Grundschutz, ist notwendig und spezielle Maßnahmen sind angeraten.Handlungsbedarf ist möglicherweise gegeben. Der Eintritt einer füreinen Akteur beträchtlich negativen Situation scheint aber ausgeschlossen.Eine Risikoreduktion durch Maßnahmen des Grundschutzbzw. Best-Practices ist angeraten.Es ist kein Handlungsbedarf gegeben. Das Ereignis tritt kaum odersehr selten ein und es wird maximal ein mittleres Schadensausmaßerwartet.Ferner ist für jedes Restrisiko eine Eintrittswahrscheinlichkeit abzuschätzen und zu begründen.Tabelle 27: Eintrittswahrscheinlichkeiten für RestrisikenKategorie Bezeichnung Interpretation 1 Interpretation 21 kaum weniger als 1/Jahr 56%Interpretation 1: Wird verwendet, wenn ein Ereignis aus einer vergleichsweise kleinenGrundmenge in einem Jahr eintreten kann, z. B. der Ausfall eines Rechenzentrums auseiner Grundmenge von 5 Rechenzentren. Die Semantik dieser Interpretation ist „tritt x-Malpro Jahr“ ein.Interpretation 2: Wird verwendet, wenn die Eintrittswahrscheinlichkeit für ein Ereignisaus einer vergleichsweise großen Grundmenge (z. B. die Menge aller eGKs) geschätztwird. Die Semantik dieser Interpretation ist „x% aller Elemente sind in einem Jahr vondiesem Ereignis betroffen“ (z. B. 10-15% aller ausgegebenen eGKs werden in einem Jahrgestohlen).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 177 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAllgemein ist die Wahl zwischen Interpretation 1 und 2 von der Anzahl der Elemente derbetrachteten Grundmenge abhängig. Beispielsweise könnte man die Interpretation 2 abeiner Grundmenge von deutlich mehr als 100 Elementen wählen. Dies ist jedoch abhängigvom Dienst bzw. Netz und somit nicht allgemein gültig. Der Dienstanbieter MUSSdeshalb die Grenze für Interpretation 1 oder Interpretation 2 für den jeweiligen Dienst bzw.das jeweilige Netz selbst festlegen und begründen.Die Bewertung der Restrisiken erfolgt dann in der üblichen Weise durch gleichzeitige Betrachtungder Risikoklasse und der Eintrittswahrscheinlichkeit.8.6.14 Erstellung eines NotfallkonzeptsDer Dienstanbieter MUSS ein Notfallkonzept erstellen. Das Notfallkonzept MUSS mindestensdie folgenden Punkte umfassen:• Übergeordnete Notfallstrategie• Gesetzliche und vertragliche Anforderungen• Rollen und Verantwortliche in Bezug auf das Notfall-Management• Dokumentation zur Notfallvorsorge• Verhalten in Notfällen• Spezielle Notfälle wie Brand, Einbruch, Wasser, Stromausfall, etc.• Nachbereitung von Notfällen• Prävention, insbesondere Fachkunde und SchulungenDer Dienstanbieter SOLL der Gliederung und den inhaltlichen Vorgaben des DokumentsBSI: Notfallvorsorgekonzept – Beispiel [BSI_NVK] folgen.8.6.15 Einordnung des Dienstes in das Zonenkonzept der gematikDie Komponenten, mit deren Hilfe ein Dienst der Telematikinfrastruktur umgesetzt wird,werden verschiedenen Zonen zugeordnet. Dabei werden die Zonen insbesondere aufBasis der notwendigen Kommunikationsbeziehungen der in ihr enthaltenen Komponentencharakterisiert.Da ein Dienst zu seiner Realisierung mehrere Komponenten verwenden kann, kann sichein Dienst damit grundsätzlich auch über mehrere Zonen erstrecken.An jede Zone der Telematikinfrastruktur werden verschiedene Arten von Sicherheitsanforderungendefiniert, die im Sicherheitskonzept des Dienstanbieters zu berücksichtigensind.Die Anforderungen an die verschiedenen Zonen gliedern sich in:• Allgemeine Sicherheitsanforderungen an Top-Level-Zonenklassen• Detaillierte Sicherheitsanforderungen an Zonen• Anforderungen an Zonenübergängegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 178 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Anforderungen aus dem IT-Grundschutz für die Sicherheitsbereiche• Spezielle Anforderungen an die SicherheitsbereicheDer Dienstanbieter MUSS in seinem Sicherheitskonzept grundsätzlich alle Komponenten,die zur Realisierung des Dienstes verwendet werden sollen, angeben (vergleiche auchKapitel 8.6.3) und aufzeigen, in welcher Zone diese Komponenten betrieben werden sollen.Daraus ergibt sich, welche Anforderungen im Sicherheitskonzept adressiert werdenmüssen.8.6.16 Fortschreibung des spezifisches SicherheitskonzeptDas spezifische Sicherheitskonzept muss laufend fortgeschrieben werden. Anlässe füreine neue Untersuchung und das Fortschreiben des Konzeptes sind etwa:• Ablauf eines vorgeschriebenen oder vereinbarten Zeitraumes (etwa jährlichesUpdate)• Eintritt von Ereignissen, die die Bedrohungslage verändern• Eintritt von Ereignissen, die die Werte verändern• Ereignisse, die die Eintrittswahrscheinlichkeit von Bedrohungen verändern,• neue Möglichkeiten für Sicherheitsmaßnahmen.• Grundlegende sicherheitsrelevante Änderungen an den betriebenden Systemen.• Sobald sich im Sicherheitskonzept gemachte Annahmen oder dokumentierteTatsachen, die Sicherheitsrelevanz besitzen, verändern, muss das Konzeptaktualisiert werden.• Um die Voraussetzungen für eine effiziente und zielgerichtete Fortschreibungdes Sicherheitskonzeptes zu gewährleisten, müssen folgende Aspekte umgesetztund dokumentiert werden• laufende Überprüfung von Akzeptanz und Einhaltung der Maßnahmen• Protokollierung von Schadensereignissen• Kontrolle der Wirksamkeit und Angemessenheit der Maßnahmen8.6.16.1 Umsetzung des spezifischen SicherheitskonzeptsVor der Umsetzung des Sicherheitskonzeptes sind die zu implementierenden Maßnahmenauf ihre Übereinstimmung mit der Sicherheitspolicy zu überprüfen (Security ComplianceChecking). Ferner sind sie auf Vollständigkeit zu prüfen und zu testen. Vor der Aufnahmeder Produktion erfolgt eine Abnahme durch die gematik.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 179 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur8.7 Implementierung von Maßnahmen8.7.1.1 DokumentationEs muss eine detaillierte, korrekte, prüfbare und aktuelle Dokumentation der Implementierungenerfolgen.8.7.1.2 Implementierung von technischen und organisatorischen AbläufenDie Implementierung der ausgewählten Sicherheitsmaßnahmen muss anhand eines Sicherheitsplanes,entsprechend der vorgegebenen Zeitpläne und Prioritäten, erfolgen.Die Verantwortlichkeiten müssen detailliert beschrieben werden.8.7.1.3 Prüfung der Maßnahmen auf Übereinstimmung mit der SicherheitspolicySecurity Compliance Checks müssen sowohl im Rahmen der Implementierung der Maßnahmenals auch als wiederholte Aktivität zur Gewährleistung der Sicherheit im laufendenBetrieb durchgeführt werden.Dabei muss geprüft werden:• die vollständige und korrekte Umsetzung der Sicherheitsmaßnahmen• der korrekte Einsatz der implementierten Sicherheitsmaßnahmen• die Einhaltung der organisatorischen Sicherheitsmaßnahmen im täglichen Betrieb.8.8 Sicherheitsanforderungen an den BetriebDie Dienste werden potenziell nicht von der gematik, sondern von vertraglich beauftragtenDienstleistern betrieben. Insofern ist es notwendig, auch die zu treffenden Sicherheitsmaßnahmenvertraglich fest zu legen. Bei der Verarbeitung von personenbezogenen Datensind ggf. die Regelungen des § 11 BDSG zu beachten.Im Anhang G werden die vereinbarten Sicherheitsmaßnahmen festgelegt - es ist jeweilsgekennzeichnet, ob der Dienstbetreiber sie umsetzen SOLL oder MUSS. Der Dienstleisterhat den Nachweis der Umsetzung zu erbringen bzw. im Falle einer Soll-Maßnahme dieGleichwertigkeit seiner getroffenen Alternativmaßnahmen nachzuweisen.Vom Dienstbetreiber werden im Einzelfall weitere, aus dem Schutzbedarf und den Bedrohungendes spezifischen Dienstes abgeleitete, Maßnahmen festgelegt. In sofern beschreibtdieses Dokument Mindestanforderungen zum Betrieb der Infrastruktur, die durchdie anderen, in der Leistungsbeschreibung referenzierten Dokumente, um weitere Anforderungenerweitert werden.Die Sicherheitsmaßnahmen sind den entsprechenden Kapiteln aus ISO 27002:2005 zugeordnet.Dieses Dokument beschreibt die Anforderungen der gematik an die Umsetzungeinzelner Punkte dieses Standards durch den Betreiber genauer und detaillierter. Davonunabhängig bleibt die Forderung weiter bestehen, dass der Dienstbetreiber seine Betriebsführunggenerell an den Empfehlungen des ISO 27001:2005 ausrichtet. Dies bedeutet,dass er dokumentiert hat, wie die Empfehlungen des ISO 27002:2005 durch seine Be-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 180 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturtriebsführung erfüllt werden. Die weitergehenden Anforderungen an die Umsetzung vonISO 27001:2005 bleiben unberührt.In diesem Kapitel wurde bereits berücksichtigt, dass der Dienstbetreiber möglicherweiseVerantwortungen an einen anderen Auftragnehmer delegiert. Deswegen sind die konkretenVerantwortlichkeiten so weit aufgeschlüsselt, dass eine Zuweisung bestimmter Verantwortungenan einen Dritten durch Zuteilen der Art der Verantwortung (P = Perform, A =Assistiert) leicht möglich ist. Die Tatsache, dass der Vertragspartner der gematik auch fürdie Umsetzung der Maßnahmen durch Unterauftragnehmer verantwortlich ist, bleibt davonunberührt.Schwerpunkte der vorgegebenen Maßnahmen liegen in den folgenden Bereichen:• Personelle Anforderungen: Anforderungen an die Auswahl und die Schulungvon Mitarbeitern.• Physikalische Anforderungen: Festlegung der Mindestanforderungen an diephysikalische Sicherheit kontrollierter Bereiche, Quantifizierte Anforderungennach dem Grundschutzkatalog des BSI, Bauliche Vorgaben, OrganisatorischeVorgaben, insbesondere für die Verwaltung von Zutrittsrechten. Vorgaben fürdie Platzierung von Servern, Peripherie und Datenträgern.• Anforderungen an logische Zugriffskontrollen: Sicherheit von Benutzer-IDsund Kennwörtern.• Definition eines Rollen- und Berechtigungskonzeptes für Betrieb und Administration, das dem Minimalitätsprinzip genügt.• Definition und Schutz von Assets: Klassifizierung, von Assets, Sicherung derAssets in Test- und Betriebsumgebung, Einsatz von Verschlüsselungsverfahren.• Protokollierung und Meldung von Zugriffsverletzungen• Vorgaben für den Umgang mit Speichermedien• Vorgaben für das Management von Sicherheitszwischenfällen• Vorgaben für den Einsatz von Firewalls, IDSen und Malware-Schutz.8.9 Zulassungs- und AkkreditierungsprozesseErst nach erfolgter Zulassung bzw. Akkreditierung durch die gematik darf das Systembzw. die Applikation in Echt- oder Wirkbetrieb gehen.8.9.1 gematik: Zulassungsverfahren der dezentralen IT- KomponenteHier wird das Zulassungsverfahren der gematik für die dezentralen IT-Komponenten derelektronischen Gesundheitskarte zusammengefasst. Die dezentralen IT-Komponentenbestehen aus:• elektronische Gesundheitskarte (eGk)• HBAgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 181 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• SMC• Kartenterminal• KonnektorZur Orientierung soll Abbildung 23 eine Hilfe sein:Abbildung 23: Übersicht ZulassungsverfahrenZiel der Zulassung ist den Betrieb der Infrastruktur für das Telematiksystem abzusichern.Alle dezentralen IT- Komponenten erfordern laut Gesetz (z. B. SGB V) und Rechtsverordnungüber Testmaßnahmen eine Zulassung von der gematik.Die Abbildung 24 stellt eine Übersicht über die Struktur und Aufbau der Zulassung dar.Eine Zulassung ist Voraussetzung für die Auslieferung und Nutzung der dezentrale IT-Komponente. Die gematik Zulassungsstelle ist zuständig für die Bearbeitung der Zulassungsanträgeund die Erteilung der Zulassung. Zudem führt die gematik die Prüfungenzur funktionalen und materialtechnischen (elektrisch/physikalische) Eignung durch. DiesePrüfungen beinhalten die Tests zu den Funktionen, der Konformität, Integration und Interoperabilität.Die Testung wird jeweils durch das zentrale Testlabor der gematik durchgeführt.Die sicherheitstechnische Eignung einer Komponente muss durch das BSI bzw. durch einvon der BSI anerkanntes IT-Sicherheitszertifikat und ggf. durch eine Bestätigung gemäßSigG nachgewiesen werden. 2222 Die Mehrbox-Lösung, wie sie z. B. in einem RZ im Krankenhaus verwendet wird, muss mit existierendennicht zertifizierten Komponenten aufgebaut werden. Äquivalente organisatorische Maßnahmenmüssen in einer Betriebspolicy beschrieben sein (siehe Kapitel 9).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 182 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZudem erwartet die gematik eine Sicherheitsdokumentation in folgender Gliederung:• Gegenstand der Sicherheitsdokumentation einschließlich der Darstellung derbetrachteten Abläufe und der Schnittstellen nach außen• Auflistung der zugrunde liegenden Dokumente der gematik• Auflistung der zugrunde liegenden Dokumente der für den Teil-/Gesamtprozess verantwortlichen Organisationseinheit oder Organisation.• Referenz auf das zugrunde liegende Sicherheitskonzept• Bewertung des Sicherheitskonzeptes in Bezug auf den Schutzbedarf• Abschließende Bemerkung und explizite EmpfehlunggematikZulassungsstelleFunktionaleEignungFunktionstestsKonformitätstestsIntegrationstestsdurchgematikSicherheitstechnischeTests und BestätigungIT Sicherheitszertifizierung undggf. Bestätigung (nach SigG)durchBSI sowieZertifizierungsstellenderen Zertifikate durch das BSIanerkannt werden undBestätigungsstellenMaterialprüfungDurchführungphysikalischer,mechanischer,elektrischer TestsdurchPrüfstellenZulassung / PrüfnachweiseAbbildung 24: Struktur und Aufbau der Zulassung8.9.2 VerfahrensablaufUm ein Verfahren zu initiieren muss der Hersteller einen Antrag bei der gematik stellen.Der Antrag muss schriftlich erfolgen. Zudem stimmt der Hersteller mit dem Zulassungsantrageiner Veröffentlichung seiner Zulassung zu. Der Antrag wird dann von der gematikbearbeitet.Dem Antrag wird eine Anmeldungs-ID zugeteilt nach dem folgenden Muster:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 183 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnm_Komponente_Firmenname_Datum (JJMMTT)_lfd.Nr.Für jeden Zulassungsantrag wird eine Zulassungsakte und Zulassungscheckliste angelegt.Nachdem alle Prüfnachweise für die zuzulassende Komponente geprüft sind, wird einZulassungsbericht erstellt, in dem die Ergebnisse des Verfahrens und ein abschließendesVotum dokumentiert werden. Eine Zulassung wird durch Zulassungsurkunden dokumentiert.Ein Votum kann jeweils eine:• Zulassung versagen• Beschränkte Zulassung aussprechen• Unbeschränkte Zulassung (mit oder ohne Auflagen) aussprechen.Sollten die Unterlagen vom Antragsteller fehlerhaft/unvollständig sein, so wird der Antragstellerzur Nachbesserung gebeten (soweit eine Nachbesserung möglich ist). Werdendie Nachweise nicht nach einer bestimmten Zeitfrist eingereicht, so kann das Zulassungsverfahreneingestellt werden. Werden die Nachweise zeitgerecht eingereicht, so kann(aber muss nicht) ein erneutes Zulassungsverfahren initiiert werden. Ein Zulassungsverfahrenwird abgeschlossen indem alle Antragsteller postalisch benachrichtigt werden. Zudemwerden, erfolgte Zulassungen mit Zulassungsurkunde unter www.gematik.de publiziert.Ist eine eGk zugelassen worden und sind zu einem späteren Zeitpunkt vom AntragstellerÄnderungen an der eGk vorgenommen worden (Release-Wechsel), so darf die geänderteVersion dann als zugelassen bezeichnet werden, wenn das Zulassungsverfahren für diegeänderte eGk erneut vollständig und erfolgreich durchlaufen ist.Abbildung 25 gibt eine detaillierte Sicht vom Zulassungsverfahren.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 184 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturHerstellerHerstellerAntrag aufZulassungMat.-PrüfungIT-SicherheitNachweis derfunktionalenTestsBerichtUrkundeBeginnZulassungs-VerfahrenPrüfnachweiseAntragsbearbeitungZulassungEndeZulassungs-VerfahrengematikPrüflabore z.B.BSI/gematikgematikAbbildung 25: Detaillierte Darstellung des Zulassungsverfahrens8.9.3 Einspruchsverfahren vom Antragsteller und Entzug von ZulassungenIst der Antragsteller mit der Entscheidung der Zulassungsstelle nicht einverstanden, sokann er schriftlich und mit Begründung innerhalb 14 Tage Einspruch erheben. Die gematikentscheidet über solche Einsprüche regelmäßig.Neue technische Informationen oder Erkenntnisse über eine bereits zugelassene eGkkönnen im Extremfall dazu führen, dass die Zulassung nachträglich entzogen werdenmuss. Hier wird der Antragsteller schriftlich informiert und gebeten, die Zulassungsurkundeim Original zurückzusenden. Der Entzug einer Zulassung wird unterhttp://www.gematik.de/ publiziert. Der Antragsteller hat die Möglichkeit, Einspruch zu erheben.8.9.4 Besonderheiten der EinführungsphaseWährend der Einführungsphase der eGk gibt es Besonderheiten (Erleichterungen im Zulassungsverfahren),die nach Erreichen der Betriebsphase nicht mehr gelten. Die Einführungsphaseumfasst die Teststufen 1 bis 4.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 185 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 26: Übersicht über die TeststufenFür die Teilnahme an den Teststufen 1 (Labor) und 2 (Anwendertest) ist keine offizielleZulassung erforderlich. Teststufe 1 umfasst die funktionalen Eignungstests. Nach Abschlussdieser Tests kann die Komponente für den Einsatz in den weiterführenden Anwendertestsder Teststufe 2 freigegeben werden. Für Teststufe 3 ist die beschränkte Zulassungdurch die gematik erforderlich. Ab dem 10.000er Test ist der Einsatz von realenKomponenten Voraussetzung. Für diese beschränkte Betriebszulassung werden folgendePrüfnachweise erfordert:• Nachweise der funktionalen Eignung• IT-sicherheitstechnische Zertifizierung und ggf. Bestätigung (Die Prüfungender SecurityTargets gegen die PP müssen zu diesem Zeitpunkt entfallen,wenn eine IT-sicherheitstechnische Prüfung nach den Common Criteria [CC]auf Grund der fehlenden PP noch nicht durchgeführt werden kann.)• Nachweis der elektrischen und physikalischen Eignung.Für Teststufe 4 und das spätere Roll-Out ist eine vollständige Zulassung der Komponentedurch die gematik entsprechend der drei oben genannten Kriterien erforderlich.8.9.5 Besonderheiten der Zulassung der eGkDie eGk setzt sich aus verschiedenen Komponenten zusammen:• Betriebssystem und Anwendungssoftware• Chip als Hardwareplattform• Kartenkörper.Die Zulassung des Betriebssystems umfasst den Nachweis der funktionalen Eignung unddie IT-Sicherheitszertifizierung und ggf. Bestätigung. Die Zulassung des Chips umfasstden Nachweis der funktionalen Eignung und IT-Sicherheitszertifizierung und ggf. Bestätigung.Die Zulassung des Kartenkörpers umfasst den Nachweis der Materialprüfung. Sollgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 186 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktureine eGK zugelassen werden, so können die bereits erfolgten Einzeltests im Nachweisbeigefügt und für die Zulassung anerkannt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 187 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur8.10 Zusammenstellung der AusgangsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_02385 S Sec_Management_001: Beachtung der NormenISO27001/27002:2005.A_02386 S Sec_Management_002: Aufgaben des Sicherheitsmanagements.A_02387 S Sec_Policy_01:Definition SicherheitspolicyA_02388 S Sec_Policy_02: Beachtungder Sicherhietspolicy.Die Aktivitäten im Rahmen des Sicherheitsmanagements MÜSSEN inAnlehnung an ISO 27001/27002:2005 gestaltet werden. SowohlDienstbetreiber, die Teile der Telematikinfrastruktur betreiben, als auchdie gematik MUSS ein Informationssicherheitsmanagementsystem(ISMS) implementieren. Auf dieser Basis soll die Verzahnung der Prozesseund die Optimierung der Schnittstellen kontinuierlich verbessertwerden.MUSS-Anforderungen an das Sicherheitsmanagements:• Festlegung der Sicherheitsziele, -strategien und –policies,• Festlegung der Sicherheitsanforderungen,• Ermittlung und Analyse von Bedrohungen und Risiken,• Festlegung geeigneter Sicherheitsmaßnahmen,• Überwachung der Implementierung und des laufenden Betriebes derselektierten Maßnahmen,• Förderung des Sicherheitsbewusstseins sowie• Detektion von und Reaktion auf sicherheitsrelevante Ereignisse. (Security-incident-Management;dieses soll in das allgemeine Incident_Managementeingebettet sein, welches möglichst nach ITIL organisiertwerden soll).Die Sicherheitspolicy der Telematikinfrastruktur ist eine MUSS-Vorgabeund MUSS durch die Sicherheitspolicies aller Betreiber von Prozessenund Komponenten der Telematikinfrastruktur detailliert und ergänztwerden.Jeder Beteiligte an der Telematikinfrastruktur muss Kenntnis über diewichtigsten Inhalte der Sicherheitspolicy haben; die direkt mit der Sicherheitbeschäftigten Mitarbeiter müssen im Besitz einer aktuellenVersion der Sicherheitspolicy sein, sie in Gänze kennen und ihr Ar-Kap. 8Kap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 188 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturbeitsverhalten an den Vorgaben der Policy ausrichtenA_02389 S Sec_Organisation undVerantwortlichkeiten:Festlegung von Rollenund Verantwortlichkeiten.A_02390 S Risikomanagemntprozess:Gestaltung desRisikomanagements.A_02391 S Risikoanalyse_01:FestlegungderRisikoanalysestrategie.A_02392 S Risikoanalyse_02:Durchführung der Risikoanalyse.A_02393 S Akzeptables_Restrisiko:In derRisikoanalyse einesUm die im Sicherheitsmanagementprozess definierten Schritte zu managen,zu vollziehen und zu kontrollieren sowie alle in diesen Prozessinvolvierten Gruppen möglichst effizient einzubinden, MÜSSEN Rollenund Verantwortlichkeiten festgelegt werdenAuf Basis der von der gematik festgelegten Mindeststandards MUSSjeder Betreiber innerhalb der Telematikinfrastruktur seinen eigenenRisikomanagementprozess gestalten, mittels dessen er Schwachstellenerkennt und durch Maßnahmen mindert, das Restrisiko bestimmt unddie Verantwortung dafür übernimmt.Die vom Betreiber bestimmten Restrisiken müssen immer an die gematikgemeldet und von dieser akzeptiert werdenEin methodisches Risikomanagement MUSS zur Erarbeitung einesvollständigen und alle Bereiche der Telematikinfrastruktur betreffendenSicherheitskonzeptes eingerichtet werden. Ziel ist es, das Risiko soweit zu reduzieren, dass das verbleibende Restrisiko quantifizierbarund akzeptierbar wird.In der Sicherheitspolicy eines jeden Betreibers MUSS die Risikoanalysestrategiefestgelegt werden. Des weiteren MUSS der Prozess zurBewertung und zum Akzeptieren von Restrisiken definiert werdenFür Systeme der Schutzbedarfskategorie „niedrig bis mittel“ wird voneiner pauschalierten Gefährdungslage ausgegangen, so dass auf einedetaillierte Risikoanalyse verzichtet und eine Grundschutzanalysedurchgeführt werden kann.Systeme der Schutzbedarfskategorie „hoch oder sehr hoch“ MÜSSENeiner detaillierten Risikoanalyse unterzogen werden, auf deren Basisindividuelle Sicherheitsmaßnahmen ausgewählt werdenTrotz der Durchführung aller ausgewählten Sicherheitsmaßnahmenverbleibt im Allgemeinen ein Restrisiko. In der Risikoanalyse eines jedenBetreibers MÜSSEN diese akzeptablen Restrisiken so exakt wieKap. 8Kap. 8Kap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 189 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturjeden Betreibers MÜS-SEN diese akzeptablenRestrisiken so exaktwie möglich benanntwerdenA_02394 S Außergewöhnliche_Risiken:BehandlungaußergewöhnlicherRisiken.A_02395 S Risikoanalyse_Detail_01:DetaillierteRisikoanalysenach ISO/IEC 13335-3.A_02396 S Risikoanalyse_Detail_02:Grundlagender Risikoanalyse.möglich benannt werdenVerbleibt nach Durchführung aller im Sicherheitsplan vorgesehenenMaßnahmen ein Restrisiko, das höher ist als das generell akzeptierteund dessen weitere Reduktion nicht möglich ist, so besteht in begründetenAusnahmefällen die Möglichkeit einer bewussten Akzeptanz deserhöhten Restrisikos.In der Sicherheitsvorschriften eines jeden Betreibers MÜSSEN• das Vorgehen bei Risiken, die in Abweichung von der generellen Sicherheitsvorschriftenin Kauf genommen werden sollen, sowie• die Verantwortlichkeiten dafürfestgelegt werden.Risikoananalyse:Bei Systemen, auf denen Anwendungen mit hohem oder sehr hohemSchutzbedarf installiert sind, muss eine genaue Analyse der bestehendenWerte, Bedrohungen und Schwachstellen und damit eine detaillierteRisikoanalyse durchgeführt werden. - Hinweise zu diesem Verfahrenfinden sich etwa in ISO/IEC 13335-3, Anhang D sowie in BSI 7105, S.199ffBei der Durchführung einer Risikoanalyse MÜSSEN folgende Prinzipienund Vorgehensweisen beachtet werden:• Das gesamte Verfahren MUSS transparent gemacht werden.• Es DÜRFEN NICHT versteckte Annahmen gemacht werden, die etwadazu führen, dass Bedrohungen unbetrachtet bleiben.• Alle Bewertungen MÜSSEN begründet werden, um subjektive Einflüssezu erkennen und so weit wie möglich zu vermeiden.• Alle Schritte MÜSSEN so dokumentiert sein, dass sie später auch fürandere nachvollziehbar sind.• Es MÜSSEN alle wesentlichen Bedrohungen erfasst werden.• Zu jeder Bedrohung MUSS die Eintrittswahrscheinlichkeit in Relationgesetzt werden.Kap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 190 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02397 S Risikoanalyse_Detail_03:Anapassungder Risikoanalysestrategiean denSchutzbedarf.A_02398 S Risikoanalyse_Grundschutz:Beachtungder IT-Grundschutzkatalogedes BSIA_02399 S Risikoanalyse_Detail_04:Nutzungdes kombinierten Ansatzes.A_02400 S Spezifisches Sicherheitskonzept_01:Mindestumfangdes spezifischenSicherheitskonzeptes..• Es MÜSSEN möglichst alle Schwachstellen des Systems in den BereichenOrganisation, Hard- und Software, Personal und Infrastrukturidentifiziert und ihre Bedeutung klassifiziert werden.• Risiken, denen die Telematikinfrastruktur ausgesetzt ist, MÜSSENerkannt, dokumentiert und bewertet werden.• Jegliche Änderung an Werten, Bedrohungen, Schwachstellen oderSicherheitsmaßnahmen MUSS in ihrem Einfluss auf die Einzelrisikenund auf das Gesamtrisiko bewertet werden.Systeme der Schutzbedarfskategorie „niedrig bis mittel“ MÜSSEN einerGrundschutzanalyse unterzogen werden, wohingegen die derSchutzbedarfskategorie „hoch und sehr hoch“ einer detaillierten Risikoanalyseunterzogen werden MÜSSEN, auf deren Basis dann individuelleSchutzmaßnahmen ausgewählt werdenDie Vorgehensweise zur Grundschutzanalyse muss den Vorgaben desBSI (IT-Grundschutzkatalogen des BSI, BSI GSHB) folgenRisikoanalyse:Es muss mindestens der kombinierte Ansatz gewählt werden; derGrundschutzansatz ist aufgrund des hohen Schutzbedarfes nicht ausreichend.Der Dienstbetreiber MUSS ein Sicherheitskonzept erstellen. Das SicherheitskonzeptMUSS die folgenden Kapitel umfassen:• Beschreibung des Dienstes (s. Abschnitt 1.6.3)• Sicherheitspolicy des Dienstes ((s. Abschnitt 1.6.4)• Schutzbedarf der Daten (s. Abschnitt 1.6.5)• Bedrohungsanalyse (s. Abschnitt 1.6.6)• Sicherheitsanforderungen der gematik (s. Abschnitt 1.6.7)• Sicherheitsmaßnahmen (s. Abschnitt 1.6.8)• Ablauforganisation (s. Abschnitt 1.6.9)• Besondere technische Komponenten (s. Abschnitt 1.6.10)• Schlüssel- und Zertifikatsmanagement (s. Abschnitt 1.6.11)• Wirksamkeit der Sicherheitsmaßnahmen (s. Abschnitt 1.6.12)Kap. 8Kap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 191 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02401 S Spezifisches Sicherheitskonzept_02:Verweisauf Konzepote derGematik.A_02402 S Spezifische Sicherheitspolicy:Mindestumfangder spezifischenSicherheitspolicy.A_02403 S Schutzbedarf_Daten:Einstufung nach Vertraulichkeit,Integrität,Verfügbar• Erstellung einer Restrisikoabschätzung (s. Abschnitt 1.6.13)• Erstellung eines Notfallkonzepts (s. Abschnitt 1.6.14)• Einordnung in das Zonenkonzept der gematik (s. Abschnitt 1.6.15)• Verfahrenanweisungen zur nachhaltigen Wirksamkeitskontrolle derdefinierten Maßnahmen (InternesKontrollSystem=IKS, ComplianceChecks).• Aufstellung sicherheitsrelevanter Parameter, die im Rahmen einestechnischen Compliance-Checks bzw. Integritätschecks überwachtwerden müssen.• Aufstellung und Klassifikation von Logfile-Einträgen, die im Rahmendes SecurityIncidentManagemnt bearbeitet werden müssen.Der Dienstanbieter kann in seinem Sicherheitskonzept zur Beschreibungdes Dienstes auf die entsprechenden Spezifikationen der gematikverweisen.Ergänzende, die Umsetzung betreffende Festlegungen des DienstanbietersMÜSSEN beschrieben werdenEine spezifische Sicherheitspolicy für ein System bzw. eine Applikationmuss Aussagen zu folgenden Bereichen treffen:• Definition und Abgrenzung des Dienstes• Beschreibung der wichtigsten Komponenten• Definition der wichtigsten Ziele und Funktionalitäten• Festlegung der Sicherheitsziele• Abhängigkeiten der Sicherheit der Telematikinfrastruktur von dembetrachteten Dienst• Risikoanalysestrategie• Verantwortlichkeiten für die Erstellung und Umsetzung des Sicherheitskonzeptes.Die spezifische Sicherheitspolicy muss regelmäßig aktualisiert und beiBedarf entsprechend angepasst werden. Sie ist mindestens jährlich zuüberprüfen.Die Schutzobjekte werden hinsichtlich der Kriterien• Vertraulichkeit• Integrität• VerfügbarkeitKap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 192 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturkeit,Authentizität,NichtabstreitbarkeitA_02404 S Bedrohungsanalyse:Der DienstanbieterMUSS in seinem SicherheitskonzepteineBedrohungsanalysevornehmen.A_02405 S Sicherheitsanforderungen:Dokumentationder Sicherheitsanforderungensowie derenUmsetzung.A_02406 S Sicherheitsmaßnahmen_01:Dokumentationder Sicherheitsmaßnahmen.• Authentizität• Nichtabstreitbarkeiteingestuft. Sofern von einem Infrastrukturdienst grundsätzlich sehr hoheVerfügbarkeit verlangt wird, ist der Punkt Verfügbarkeit nicht für jedeseinzelne Schutzobjekt zu betrachten. Im Übrigen wird darauf hingewiesen,dass die Fragen zur Verfügbarkeit nicht im Sicherheitsprofilsondern bei den nichtfunktionalen Anforderungen betrachtet werden.Im Sicherheitskonzept des Dienstanbieters MUSS für jedes Schutzobjektaus Anhang C erläutert werden, ob und wie der Dienstanbieter aktivzum Schutz des Schutzobjekts beiträgt.Der Dienstanbieter MUSS in seinem Sicherheitskonzept eine Bedrohungsanalysegegenüber den in Abschnitt 1.6.5 beschriebenenSchutzobjekten vornehmen.Da manche Bedrohungen gegen die in Abschnitt 1.6.5 beschriebenenSchutzobjekte bereits durch Sicherheitsmaßnahmen abgewehrt werden,die nicht durch den Infrastrukturdienst, sondern durch andere Stellender Telematikinfrastruktur abgewehrt werden, kann der Dienstanbieterschon an dieser Stelle darauf verweisen, dass eine solche Bedrohungnicht zum Tragen kommt. In diesem Fall muss sie im Folgendennicht weiter betrachtet werden.Die Nicht-Relevanz ist im Zweifelsfall zu bergründen.In das Sicherheitskonzept des Dienstanbieters MÜSSEN alle Sicherheitsanforderungenaus dem übergreifendes Sicherheitskonzept derTelematikinfrastrukturaufgenommen und deren Umsetzung bzw. Einhaltungim folgenden dokumentiert werden.Es MUSS eine Liste existierender bzw. geplanter Sicherheitsmaßnahmenunter Berücksichtigung der Ergebnisse der Risikobewertung erstelltwerden. Dabei SOLL auf die Ausgewogenheit von technischenund nicht-technischen Maßnahmen geachtet werden.Der Dienstanbieter MUSS die folgenden Punkte dokumentieren:• Organisatorische Sicherheitsmaßnahmen, z. B. organisatorische Regelungenzum IT-Sicherheitsmanagement, zur Datensicherung, zurIntrusion Detection oder zum VirenschutzKap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 193 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02407 S Sicherheitsmaßnahmen_02:Bewertungder SicherheitsmaßnahmenA_02408 S Ablauforganisation:Mindestumfang derDokumentation.A_02409 S Technische_Komponenten:Dokumentation dertechnischen Komponentenund der gefor-• Personelle Sicherheitsmaßnahmen, insbesondere die Verfahren zurBeurteilung und Sicherstellung der Zuverlässigkeit und Fachkunde desPersonals zu behandeln• Infrastrukturelle Sicherheitsmaßnahmen wie bauliche Sicherheit (z.B.Vereinzelungsschleusen, Tresore) sowie die organisatorischen Aspekteder baulichen Sicherheit ( z. B. Wachdienste),• Netzwerksicherheit einschließlich Intrusion Detection, Virenschutz,etc.• Sicherheit der IT-Systeme• Administration, Wartung, Pflege der IT-Systeme• Zugriffskontrolle, Beweissicherung, Protokollauswertung, etc.Es MUSS eine Bewertung der Sicherheitsmaßnahmen erfolgen, welchemindestens Aussagen zu folgenden Punkten enthält:• Erfassung aller Bedrohungen gegen die die ausgewählten Maßnahmenwirken,• Beschreibung der Auswirkungen der Einzelmaßnahmen,• Beschreibung des Zusammenwirkens der ausgewählten und der bereitsvorhandenen Maßnahmen,• Überprüfung, ob und inwieweit die Maßnahmen zu Behinderungenbeim laufenden Betrieb führen können,• Überprüfung der Vereinbarkeit der Maßnahmen mit geltenden rechtlichenVorschriften und Richtlinien und• Bewertung, in welchem Ausmaß die Maßnahmen eine Reduktion derRisiken bewirken.Im Kapitel zur Ablauforganisation MUSS Dienstanbieter die folgendenPunkte behandeln:• Beschreibung der sicherheitsrelevanten Abläufe• Einhaltung des 4-Augen-Prinzip, falls erforderlich• Beschreibung zur Einhaltung der GenehmigungsverfahrenIm Kapitel zu den technischen Komponenten MUSS der Dienstanbieterdie folgenden Punkte behandeln:• Übersicht über die eingesetzten Produkte, welche die oben genannteSicherheitsfunktionalität umsetzen• Nachweis der Sicherheitsüberprüfungen dieser Produkte gemäß denKap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 194 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturderten Sicherheitsfunktionalität.A_02410 S Schlüssen- und Zertifikatsmanagement:Mindenstumfangder Dokumentationbzgl. Key-Management.Anforderungen der gematikSofern die Sicherheitsbegutachtungen, z. B. Evaluierung nach CommonCriteria (CC), besondere Anforderungen an die Einsatzumgebungenstellen, hat der Dienstanbieter zu erläutern, wie er diese Anforderungenumgesetzt hat.Für alle kryptographischen Schlüssel und Zertifikate, die der Dienstanbieterzur Absicherung seines Dienstes oder Netzes einsetzt, MUSSder Dienstanbieter mindestens die folgenden Informationen in sein Sicherheitskonzeptaufnehmen:Symmetrische Schlüssel• Verwendungszweck des Schlüssels, z. B. MAC-Sicherung von Protokolldaten• Zugehöriger kryptographischer Algorithmus, z. B. Triple-DES im CBC-Mode• Schlüssellänge (ggf. nach Zeiträumen gestaffelt)• Anzahl der Versionen (gemeint ist die Anzahl der Versionen und nichtdie Anzahl der Stellen, an denen dieser Schlüssel gespeichert wird; z.B. eine Schlüsselversion pro Kalenderjahr, eine Schlüsselversion proChipkarte etc.)• Erzeugung (anzugeben ist, wo und durch wen der Schlüssel erzeugtwird)• Speicherung (anzugeben ist, an welchen Stellen der Schlüssel gespeichertwird)• Verteilung (anzugeben ist, wie der Schlüssel gesichert von dem Ortseiner Erzeugung zu dem Ort seiner Speicherung gelangt)• Schlüsselwechsel (anzugeben ist, in welchen Rhythmen der Schüsselgewechselt wird; ein Schlüsselwechsel bedeutet nicht automatisch,dass der alte Schlüssel ungültig wird)• Löschen des Schlüssels• Gültigkeitsdauer des SchlüsselsPrivate asymmetrische Schlüssel• Angaben wie für symmetrische Schlüssel, nur ohne Gültigkeitsdauer(die Gültigkeitsdauer wird über das Zertifikat bestimmt)Öffentliche asymmetrische SchlüsselKap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 195 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02411 S Sicherheitsmaßnahmen:Die DienstanbieterMUSS in seinemSicherheitskonzept dieWirksamkeit der SicherheitsmaßnahmenerläuternA_02412 S Restrisikoabschätzung:Der Dienstanbietermuss eine Restrisiko-• Verwendungszweck (s. symmetrische Schlüssel)• Speicherung (s. symmetrische Schlüssel)• Verteilung (s. symmetrische Schlüssel)Zertifikate• Herausgeber des Zertifikats• Erzeugung des Zertifikats (anzugeben ist, wo und durch wen das Zertifikaterzeugt wird)• Speicherung (s. symmetrische Schlüssel)• Verteilung (s. symmetrische Schlüssel)• Sperrung (anzugeben ist, wer die Berechtigung zur Sperrung diesesZertifikats besitzt)• Gültigkeitsdauer des ZertifikatsFür alle vertraulichen Schlüsselmittel ist zu dokumentieren, wie die Vertraulichkeitbei Transport und Speicherung gewährleistet wird.Bei Schutzanforderungen bzgl. Integrität ist zu dokumentieren, wie dieIntegrität bei Transport und Speicherung gewährleistet wird.Die Dienstanbieter MUSS in seinem Sicherheitskonzept die Wirksamkeitder Sicherheitsmaßnahmen erläutern.Hierzu MUSS der Dienstanbieter erklären, welche Sicherheitsmaßnahmenden in Abschnitt 1.6.6 genannten Bedrohungen entgegenwirken.Ferner MUSS der Dienstanbieter erklären, welche Sicherheitsmaßnahmendie in Abschnitt 1.6.7 genannten Sicherheitsanforderungenumsetzen.Der Dienstanbieter muss eine Restrisikoabschätzung vornehmen. DarinMUSS der Dienstanbieter die verbleibenden Risiken darstellen undbewerten. Insbesondere MUSS er begründen, warum die verbleibendenRisiken akzeptabel sind.Hierzu MUSS der Dienstanbieter die Restrisiken aufzählen und eineEinstufung dieser Restrisiken in die Risikoklassen vornehmenDer Dienstanbieter muss eine Restrisikoabschätzung vornehmen. DarinMUSS der Dienstanbieter die verbleibenden Risiken darstellen undbewerten. Insbesondere MUSS er begründen, warum die verbleiben-Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 196 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturabschätzung vornehmenA_02413 S Restrisikoabschätzung_Eintrittswahrscheinlichkeit: Für jedesRestrisiko ist eine Eintrittswahrscheinlichkeitabzuschätzen und zubegründenA_02414 S Notfallkonzept: DerDienstanbieter MUSSein NotfallkonzepterstellenA_02415 S Zonenkonzept: DerDienstanbieter MUSSin seinem Sicherheitskonzeptgrundsätzlichalle Komponenten angebenund Zonen zuordnen.den Risiken akzeptabel sind.Hierzu MUSS der Dienstanbieter die Restrisiken aufzählen und eineEinstufung dieser Restrisiken in die Risikoklassen vornehmen.Ferner MUSS für jedes Restrisiko eine Eintrittswahrscheinlichkeit abzuschätztund begründet werden.Der Dienstanbieter MUSS ein Notfallkonzept erstellen. Das NotfallkonzeptMUSS mindestens die folgenden Punkte umfassen:• Übergeordnete Notfallstrategie• Gesetzliche und vertragliche Anforderungen• Rollen und Verantwortliche in Bezug auf das Notfall-Management• Dokumentation zur Notfallvorsorge• Verhalten in Notfällen• Spezielle Notfälle wie Brand, Einbruch, Wasser, Stromausfall, etc.• Nachbereitung von Notfällen• Prävention und Vorbeugung, insbesondere Fachkunde und SchulungenDer Dienstanbieter SOLL der Gliederung und den inhaltlichen Vorgabendes DokumentsBSI: Notfallvorsorgekonzept – Beispiel [BSI_NVK]folgen.Der Dienstanbieter MUSS in seinem Sicherheitskonzept grundsätzlichalle Komponenten, die zur Realisierung des Dienstes verwendet werdensollen, angeben (vergleiche auch Kapitel 1.6.3) und aufzeigen, inwelcher Zone diese Komponenten betrieben werden sollen. Darausergibt sich, welche Anforderungen im Sicherheitskonzept adressiertwerden müssenKap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 197 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02416 S Fortschreibung_spezifisches_Siko: Das spezifische Sicherheitskonzeptmusslaufend fortgeschriebenwerdenA_02417 S Umsetzung_spezifisches_Siko: Vor der Umsetzungdes Sicherheitskonzeptessind die zu implementierendenMaßnahmenauf ihre Übereinstimmungmit derSicherheitspolicy zuüberprüfen.A_02418 S Umsetzung_Maßnahmen_spezifisches_Siko: Um-Das spezifische Sicherheitskonzept muss laufend fortgeschrieben werden.Anlässe für eine neue Untersuchung und das Fortschreiben desKonzeptes sind etwa:• Ablauf eines vorgeschriebenen oder vereinbarten Zeitraumes (etwajährliches Update)• Eintritt von Ereignissen, die die Bedrohungslage verändern• Eintritt von Ereignissen, die die Werte verändern• Ereignisse, die die Eintrittswahrscheinlichkeit von Bedrohungen verändern,• neue Möglichkeiten für Sicherheitsmaßnahmen.• Grundlegende sicherheitsrelevante Änderungen an den betriebendenSystemen.Sobald sich im Sicherheitskonzept gemachte Annahmen oder dokumentierteTatsachen, die Sicherheitsrelevanz besitzen verändern, mußdas Konzept aktualisiert werden.Um die Voraussetzungen für eine effiziente und zielgerichtete Fortschreibungdes Sicherheitskonzeptes zu gewährleisten, müssen folgendeAspekte umgesetzt und dokumentiert werden• laufende Überprüfung von Akzeptanz und Einhaltung der Maßnahmen• Protokollierung von Schadensereignissen• Kontrolle der Wirksamkeit und Angemessenheit der MaßnahmenVor der Umsetzung des Sicherheitskonzeptes sind die zu implementierendenMaßnahmen auf ihre Übereinstimmung mit der Sicherheitspolicyzu überprüfen (Security Compliance Checking). Ferner sind sie aufVollständigkeit zu prüfen und zu testen. Vor der Aufnahme der Produktionerfolgt eine Abnahme durch die gematik.Umsetzung von Maßnahmen:Es muss eine detaillierte, korrekte, prüfbare und aktuelle Dokumentationder Implementierungen erfolgenKap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 198 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktursetzung und Prüfbarkeitvon Maßnahmen.A_02419 S Implementierung_Maßnahmen_spezifisches_SikoA_02420 S Prüfung_Maßnahmen_spezifisches_Siko: SecurityCompliance Checkssind zur Umsetzjngskontrolleerforderlich.A_02421 S Zulassungs- und Akkreditierungsprozesse:Erst nach Zulassungdarf Wirkbetrieb erfolgen.A_02422 S Zulassung_01: Voraussetzungfür dieAuslieferung und Nutzungder dezentrale IT-A_02423SKomponenteZulassung_02: Ein vomBSI anerkanntes Sicherheitszertifikatisterforderlich.Die Implementierung der ausgewählten Sicherheitsmaßnahmen mussanhand eines Sicherheitsplanes, entsprechend der vorgegebenen Zeitpläneund Prioritäten, erfolgen.Die Verantwortlichkeiten müssen detailliert beschrieben werden.Security Compliance Checks müssen sowohl im Rahmen der Implementierungder Maßnahmen als auch als wiederholte Aktivität zur Gewährleistungder Sicherheit im laufenden Betrieb durchgeführt werden.Dabei muss geprüft werden:• die vollständige und korrekte Umsetzung der Sicherheitsmaßnahmen• der korrekte Einsatz der implementierten Sicherheitsmaßnahmen• die Einhaltung der organisatorischen Sicherheitsmaßnahmen im täglichenBetrieb.Erst nach erfolgter Zulassung bzw. Akkreditierung durch die gematikdarf das System bzw. die Applikation in Echt- oder Wirkbetrieb gehen.Eine Zulassung MUSS vor Auslieferung und Nutzung der dezentralenIT- Komponente erfolgen.Die sicherheitstechnische Eignung einer Komponente muss durch dasBSI bzw. durch ein von der BSI anerkanntes IT-Sicherheitszertifikat undggf. durch eine Bestätigung gemäß SigG nachgewiesen werden.Die Mehrbox-Lösung, wie sie z. B. in einem RZ im Krankenhaus verwendetwird, muss mit existierenden nicht zertifizierten Komponentenaufgebaut werden. Äquivalente organisatorische Maßnahmen müssenin einer Betriebspolicy beschrieben seinKap. 8Kap. 8Kap. 8Kap. 8Kap. 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 199 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur9 Zusammenfassung der akzeptierten RestrisikenVor allem die gesetzlichen Grundlagen bilden die Basis für die Schutzbedarfsanalyse undFestlegung des Schutzbedarfs der fachlichen und technischen Informationsobjekte (sieheKap. 5.3, 7.3 und Anhang C). Entsprechend dem dort festgelegten Schutzbedarf werdentechnische und organisatorische Mindeststandards im Sicherheitskonzept übergreifendfestgelegt (siehe Kap. 4), um damit das notwendige Sicherheitsniveau der Komponentenund Dienste der Telematikinfrastruktur zu erreichen und die Restrisiken zu begrenzen.Durch Maßnahmen die diese Mindeststandards umsetzen, sind untragbare initiale Risikenauf ein akzeptables Niveau gesenkt worden. Zusätzlich werden die sicherheitsrelevantenFunktionalitäten in aufeinander aufbauenden Stufen entwickelt, erprobt und erst dannschrittweise eingeführt. Durch diese gestufte Vorgehensweise werden mögliche Bedrohungenin den einzelnen Stufen begrenzt und Restrisiken beherrschbar.In einem kontinuierlich durchzuführenden Risikomanagementprozess (siehe Kapitel 8.5)werden bestehende und vor allem aber auch neue auftretende Risiken in den verschiedenenBereichen bzw. bei den verschiedenen Betreibern strukturiert erfasst, bewertet undadäquate risikomindernde Maßnahmen oder eine bewusste Akzeptanz des Risikos gefordert.Diese akzeptierten Restrisiken MÜSSEN der gematik gemeldet werden. Damit hatdie gematik den Überblick über die aktuell vorhandenen Gesamtrisiken. Bei neu auftretendenund erkannten Bedrohungen kann durch Notfall- und Ersatzverfahren angemessenreagiert und damit der Schaden minimiert werden. Bei Bedrohungen die auf einenBetreiber begrenzt sind, MUSS der dafür zuständige Sicherheitsverantwortliche unverzüglichdie notwendigen Maßnahmen einleiten. Notwendige übergreifende MaßnahmenMÜSSEN durch das zu etablierende Telematik-Informationssicherheits-Board der gematikabgestimmt und koordiniert werden.Die Verantwortung der gematik endet an den Sicherheitsgrenzen der Telematikinfrastruktur.Deshalb sind die existierenden Systeme der Leistungserbringer und Kostenträger vonden in diesem Sicherheitskonzept festgelegten Regelungen und Mindeststandards der gematiknicht direkt betroffen. Dies erfordert jedoch besondere Sorgfalt bei der Anbindungder existierenden Systeme an die Telematikinfrastruktur. Es ist dabei darauf zu achten,dass Bedrohungen aus den existierenden Systemen sich nicht auf die Telematikinfrastrukturauswirken bzw. sich über die Telematikinfrastruktur in andere Systeme ausbreiten.Die wesentliche Komponente zur Begrenzung dieser Risiken ist der Konnektor,der durch das Schutzprofil und die Evaluierung dieser Komponente die Sicherheitseigenschaftan der Grenze der Telematikinfrastruktur nachweisbar sicherstellt. Falls keine zertifizierteKomponente an den Sicherheitsgrenzen der Telematikinfrastruktur eingesetztwerden kann, MUSS durch die Gestaltung der Schnittstelle in die Telematikinfrastruktureine entsprechende Abgrenzbarkeit der von den gematik Mindeststandards betroffenenSystemen erreicht werden. Für diese Schnittstellenkomponenten und Dienste MUSSdurch dem Schutzprofil äquivalente organisatorische Sicherheitsmaßnahmen das notwendigeSicherheitsniveau dieser betroffenen Schnittstellenkomponenten und Dienstegewährleistet werden. Dabei MÜSSEN die Mindeststandards der gematik eingehaltenwerden. Die spezifische Einsatz- und Betriebsumgebung dieser SchnittstellenkomponentenMUSS adäquat (siehe z.B. Anhang G bezüglich der Mindestanforderungen) geschütztwerden und der Dienstbetreiber MUSS die Verantwortung für den adäquaten Schutz unddie verbleibenden Restrisiken tragen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 200 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie wesentlichen Sicherheitsverantwortlichkeiten für einzelne Bereiche, Komponentenund Dienste der Telematikinfrastruktur sind in den Grundsatzpositionen und – entscheidungenzu Telematikanwendungen der Gesundheitskarte (siehe [Grundsatzentscheidung])festgelegt worden:• „Die sichere Anbindung der Anwender an die Telematikinfrastruktur wird inden einzelnen Sektoren durch die jeweils zuständige Spitzenorganisation verantwortet.“• „Die Krankenkassen und privaten Krankenversicherungenoogeben die eGK aus und gestalten die dafür notwendige Zertifizierungsinfrastruktur,organisieren eigenständig den Versichertenstammdatendienst und dessenBetrieb.“• „Die Leistungsträgerorganisationen:ooogeben HBAs aus und gestalten die dafür notwendige Zertifizierungsinfrastruktur“,konzipieren unter begleitender Beratung der Kostenträger die freiwilligenAnwendungen und richten die zusätzlich erforderlichen Infrastrukturdiensteein“,betreiben Datenstellen und Infrastrukturdienste (SaveD, ePA-Server, Verordnungsdatenserver).• Die gematik:ospezifiziert, zertifiziert und betreibt übergeordnete Dienste der Telematikinfrastruktur,die sektorenübergreifend verfügbar sein müssen, um Interoperabilitätzu gewährleisten (OID-Dienst zur eindeutigen Nummernvergabe,Zeitdienst usw.).Die jeweiligen Sicherheitsverantwortlichkeiten MÜSSEN mit der gematik abgestimmtwahrgenommen und von der gematik koordiniert werden (siehe § 291b Abs. 1 Satz 4: „MitTeilaufgaben der Gesellschaft für Telematik können einzelne Gesellschafter oder Drittebeauftragt werden; hierbei sind durch die Gesellschaft für Telematik Interoperabilität,Kompatibilität und das notwendige Sicherheitsniveau der Telematikinfrastruktur zu gewährleisten.“).Die übergreifende Sicherheitsorganisation und Sicherheitsprozesse (sieheKap. 8) der einzelnen Sicherheitsverantwortlichen der einzelnen Bereiche der Telematikinfrastrukturwerden entsprechend dem Aufbau und Rollout der Telematikinfrastruktur inden nachfolgenden Stufen operational wirksam:• Festlegung der Verantwortlichkeiten und der Sicherheitsverantwortlichen• Abstimmung und Festlegung der übergreifenden Anforderungen• Identifikation der Risiken und Rahmenbedingungen in den einzelnen Sektorenund Bereiche• Festlegung der Risikoklassen, spezifischer Policies und zugehöriger Haftungsregelungen• Bewertung und Optimierung der internen und übergreifenden Sicherheits-Management Prozessegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 201 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDamit sind die wesentlichen Sicherheitsverantwortlichkeiten und die Vorgehensweise zurAkzeptanz der in der Risikoanalyse identifizierten Restrisiken festgelegt. SpezifischeRestrisiken MÜSSEN mit den betroffenen Betreibern jeweils individuell abgestimmt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 202 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur9.1 Zusammenfassung der AusgangsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_02424SA_02425SAkzeptierte Restrisiken undorganisatorische Maßnahmen_01:OrganisatorischeMaßnahmen zur Überwachungund Mitigation vonRestrisiken.Akzeptierte Restrisiken undorganisatorische Maßnahmen_02:Die Verantwortungder gematik endet an denSicherheitsgrenzen der Telematikinfrastruktur.In einem kontinuierlich durchzuführenden Risikomanagementprozess (sieheKapitel 8.5) werden bestehende und vor allem aber auch neue auftretende Risikenin den verschiedenen Bereichen bzw. bei den verschiedenen Betreibernstrukturiert erfasst, bewertet und adäquate risikomindernde Maßnahmen odereine bewusste Akzeptanz des Risikos gefordert. Diese akzeptierten RestrisikenMÜSSEN der gematik gemeldet werden. Damit hat die gematik den Überblicküber die aktuell vorhandenen Gesamtrisiken. Bei neu auftretenden und erkanntenBedrohungen kann durch Notfall- und Ersatzverfahren angemessen reagiertund damit der Schaden minimiert werden. Bei Bedrohungen die auf einenBetreiber begrenzt sind, MUSS der dafür zuständige Sicherheitsverantwortlicheunverzüglich die notwendigen Maßnahmen einleiten. Notwendige übergreifendeMaßnahmen MÜSSEN durch das zu etablierende Telematik-Informationssicherheits-Board der gematik abgestimmt und koordiniert werden.Die Verantwortung der gematik endet an den Sicherheitsgrenzen der Telematikinfrastruktur.Deshalb sind die existierenden Systeme der Leistungserbringerund Kostenträger von den in diesem Sicherheitskonzept festgelegten Regelungenund Mindeststandards der gematik nicht direkt betroffen. Dies erfordert jedochbesondere Sorgfalt bei der Anbindung der existierenden Systeme an dieTelematikinfrastruktur. Es ist dabei darauf zu achten, dass Bedrohungen ausden existierenden Systemen sich nicht auf die Telematikinfrastruktur auswirkenbzw. sich über die Telematikinfrastruktur in andere Systeme ausbreiten. Diewesentliche Komponente zur Begrenzung dieser Risiken ist der Konnektor, derdurch das Schutzprofil und die Evaluierung dieser Komponente die Sicherheitseigenschaftan der Grenze der Telematikinfrastruktur nachweisbar sicherstellt.Falls keine zertifizierte Komponente an den Sicherheitsgrenzen der Telematikinfrastruktureingesetzt werden kann, MUSS durch die Gestaltung der Schnittstellein die Telematikinfrastruktur eine entsprechende Abgrenzbarkeit der vonden gematik Mindeststandards betroffenen Systemen erreicht werden. Für dieseKap. 9Kap. 9gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 203 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Art Titel Beschreibung Rel. QuelleA_02426SAkzeptierte Restrisiken undorganisatorische Maßnahmen_03:Festlegung vonVerantwortlichkeiten undZustaändigkeiten.Schnittstellenkomponenten und Dienste MUSS durch dem Schutzprofil äquivalenteorganisatorische Sicherheitsmaßnahmen das notwendige Sicherheitsniveaudieser betroffenen Schnittstellenkomponenten und Dienste gewährleistetwerden. Dabei MÜSSEN die Mindeststandards der gematik eingehalten werden.Die spezifische Einsatz- und Betriebsumgebung dieser SchnittstellenkomponentenMUSS adäquat (siehe z.B. Anhang G bezüglich der Mindestanforderungen)geschützt werden und der Dienstbetreiber MUSS die Verantwortung für denadäquaten Schutz und die verbleibenden Restrisiken tragen.Die wesentlichen Sicherheitsverantwortlichkeiten für einzelne Bereiche, Komponentenund Dienste der Telematikinfrastruktur sind in den Grundsatzpositionenund – entscheidungen zu Telematikanwendungen der Gesundheitskarte (siehe[Grundsatzentscheidung]) festgelegt worden:• „Die sichere Anbindung der Anwender an die Telematikinfrastruktur wird in deneinzelnen Sektoren durch die jeweils zuständige Spitzenorganisation verantwortet.“• „Die Krankenkassen und privaten Krankenversicherungengeben die eGK aus und gestalten die dafür notwendige Zertifizierungsinfrastruktur,organisieren eigenständig den Versichertenstammdatendienst und dessen Betrieb.“• „Die Leistungsträgerorganisationen:geben HBAs aus und gestalten die dafür notwendige Zertifizierungsinfrastruktur“,konzipieren unter begleitender Beratung der Kostenträger die freiwilligen Anwendungenund richten die zusätzlich erforderlichen Infrastrukturdienste ein“,betreiben Datenstellen und Infrastrukturdienste (SaveD, ePA-Server, Verordnungsdatenserver).• Die gematik:übergeordnete Dienste der Telematikinfrastruktur, die sektorenübergreifend verfügbarsein müssen, um Interoperabilität zu gewährleisten (OID-Dienst zur eindeutigenNummernvergabe, Zeitdienst usw.), werden von der gematik spezifi-Kap. 9gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 204 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Art Titel Beschreibung Rel. Quelleziert, zertifiziert und betrieben.Die jeweiligen Sicherheitsverantwortlichkeiten MÜSSEN mit der gematik abgestimmtwahrgenommen und von der gematik koordiniert werden (siehe § 291bAbs. 1 Satz 4: „Mit Teilaufgaben der Gesellschaft für Telematik können einzelneGesellschafter oder Dritte beauftragt werden; hierbei sind durch die Gesellschaftfür Telematik Interoperabilität, Kompatibilität und das notwendige Sicherheitsniveauder Telematikinfrastruktur zu gewährleisten.“). Die übergreifende Sicherheitsorganisationund Sicherheitsprozesse (siehe Kap. 8) der einzelnen Sicherheitsverantwortlichender einzelnen Bereiche der Telematikinfrastruktur werdenentsprechend dem Aufbau und Rollout der Telematikinfrastruktur in den nachfolgendenStufen operational wirksam:• Festlegung der Verantwortlichkeiten und der Sicherheitsverantwortlichen• Abstimmung und Festlegung der übergreifenden Anforderungen• Identifikation der Risiken und Rahmenbedingungen in den einzelnen Sektorenund Bereiche• Festlegung der Risikoklassen, spezifischer Policies und zugehöriger Haftungsregelungen• Bewertung und Optimierung der internen und übergreifenden Sicherheits-Management ProzesseDamit sind die wesentlichen Sicherheitsverantwortlichkeiten und die Vorgehensweisezur Akzeptanz der in der Risikoanalyse identifizierten Restrisikenfestgelegt. Spezifische Restrisiken MÜSSEN mit den betroffenen Betreibernjeweils individuell abgestimmt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 205 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang AAnhang A wurde zur Verbesserung der Übersichtlichkeit in den Anhang Z auf Seite 788verschoben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 206 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang B – SicherheitsanforderungenB1 - Normative Anforderungen des DatenschutzesDie nachfolgende Abbildung zeigt die Strukturierung der datenschutzrechtlichen Anforderungen.Rechtliche und Geschäftspolitische RahmenbedingungenSigG§SGB V§BDSG§Gesellschafter-beschlüsseSicherheitskonzeptPolicies,LeitlinienVersichertenrechteGrundsätze,rechtlicheVorgabenFachkonzepteFacharchitekturen,Schutzbedarf,BerechtigungskonzeptSchutzprofileMaßnahmenAnforderungenübergreifende Architekturbausteine, DiensteSpezifikationen von Schnittstellen, KomponentenGesamtarchitektur Konzept……Abbildung 27: Einordnung und Abgrenzung der Anforderungen des DatenschutzesB1.1 - Grundsätzliche Anforderungen und Eckpunkte des DatenschutzesDie Stärkung der Versichertensouveränität, der Versichertenrechte und eine Ausweitungder Eigenverantwortung und Beteiligungsrechte der Versicherten ist eines der wesentlichenZiele des GKV-Modernisierungsgesetzes (GMG). Bei der Einführung der Telematikinfrastrukturwird sich die datenschutzrechtliche Position der Versicherten nicht verschlechtern.Der Versicherte hat die Datenhoheit für alle seine Anwendungen und Gesundheitsdatenin der Telematikinfrastruktur. Der Grundsatz der Freiwilligkeit der Speicherungvon Gesundheitsdaten muss bewahrt werden, d. h.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 207 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Die Versicherten müssen darüber entscheiden können, welche ihrer Gesundheitsdatenaufgenommen und welche gelöscht werden und ob und wenn ja,welche Daten sie einem Leistungserbringer zugänglich machen.• Die Versicherten haben das Informations- und Leserecht, über ihre gespeichertenDaten und alle diese Daten betreffenden Vorgänge.Aufgrund des sehr hohen Schutzbedarfs der Daten, die von medizinischen Systemen verarbeitetwerden, ergeben sich spezielle Sicherheitsanforderungen und Sicherheitsmaßnahmen,die aus datenschutzrechtlicher Sicht als unabdingbar anzusehen sind. Dies sindinsbesondere Kriterien, die die Verlässlichkeit und Beherrschbarkeit von Systemen beschreiben.Es gibt daher einen engen Zusammenhang zwischen den Datenschutz- undden Sicherheitsanforderungen, die in der folgenden Abbildung dargestellt sind.BeherrschbarkeitVerantwortlichkeitNutzungsfestlegungNachweisbarkeitRevisionsfähigkeitUnabstreitbarkeitBeweissicherheitInformationsqualitätVerlässlichkeitDas System tut das, was manvon ihm erwartet und nichtsanderes. Insbesondere gewährtes IT-Sicherheit.DatenschutzVertraulichkeitFokus desDatenschutzkonzeptsInformationssicherheitIT-SicherheitFokus desDatensicherheits-konzeptsDatenschutzfördernde TechnikSelbstdatenschutzBeteiligungsrechteFreiwilligkeitTransparenzDatenvermeidung und -sparsamkeitSchutz von Informationen vorMissbrauch, unberechtigter Einsichtoder Verwendung, Änderung oderVerfälschung (einschließlichKatastrophenschutz).Datensicherheit in einem IT-System mit dem Schutz derIntegrität des IT-Systems.Abbildung 28: Anforderungen des Datenschutzes und der Sicherheit.Die nachfolgenden Unterkapitel fokussieren speziell auf Datenschutzanforderungen. Diesich daraus ergebenden Anforderungen an IT-Sicherheit werden in den folgenden Kapitelnzusammengefasst und dargestellt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 208 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 28: Eckpunkte des DatenschutzesAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02427 AD-GRU-01SDS_Eckpunkt_01: Vorrang(Primat) des DatenschutzesVorrang (Primat) des Datenschutzes(siehe [Grundsatzentscheidung]).Die Infrastruktur in der Telematik richtet sich prioritär amNutzen für den Versicherten aus, und alle Komponenten,Schnittstellen, Dienste und Prozesse in der TelematikMÜSSEN an erster Stelle den Erfordernissen des Datenschutzesund der Datensicherheit entsprechen.Bei der Einführung der eGK und der Telematik MÜSSENdas heute gültige Datenschutzniveau und die heute gültigenDatenzugriffsrechte erhalten werden. Änderungen derDatenzugriffsrechte erfordern gesetzliche Vorgaben odergeänderte vertragliche Beziehungen. Zur Realisierungdieser Grundsätze könnten ggf. einvernehmlich auch höherwertigeRealisierungsoptionen gewählt werden.Konsequenzen:Die Erfordernisse des Datenschutzes MÜSSEN bei allenArchitekturentscheidungen explizit berücksichtigt werden(siehe A_02457).Die Prozessgestaltung für die Pflichtanwendungen MUSSdie derzeitigen Zugriffsmöglichkeiten (siehe AD-VSDD-n,AD-VODD-n) erhalten und darf das heute gültige Datenschutzniveaudes Versicherten nicht einschränken.Anhang B 1A_02428 AD-GRU-02SDS_Eckpunkt_02: Stärkungder Versichertensouveränität,der Versichertenrechteund Ausweitung der Eigen-Stärkung der Versichertensouveränität, der Versichertenrechteund Ausweitung der Eigenverantwortungund Beteiligungsrechte der Versicherten(siehe [Grundsatzentscheidung])Anhang B 1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 209 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleverantwortung und Beteiligungsrechteder VersichertenDie Versichertensouveränität und die Versichertenrechtewerden gestärkt und die Entscheidungsfreiheiten der Versichertenausgeweitet. Die Versicherten werden künftigstärker in die Entscheidungsprozesse eingebunden. DieStärkung der Versichertensouveränität und der Ausbauder Versichertenrechte werden die Versicherten von Betroffenenzu Beteiligten und mitverantwortlichen Partnernbei der Gesundheitsversorgung machen.Die Gesundheitskarte wird datenschutzrechtlichen Belangengenügen und administrative Daten wie z. B. den Namendes Versicherten und Angaben zur Krankenkassespeichern. Auf Wunsch des Versicherten werden Gesundheitsdaten,insbesondere die wichtigsten Angabenzur Notfallversorgung, verfügbar gemacht. Insbesonderedie für die Versicherten freiwilligen Anwendungen eröffnenden Versicherten die Möglichkeit, einen verbesserten Ü-berblick über ihren Gesundheitszustand zu erhalten. Damitschafft die Gesundheitskarte und die Telematikinfrastrukturfür die Versicherten Transparenz und fördertdie Versichertensouveränität. Gleichzeitig kann die elektronischeGesundheitskarte entscheidend zur Verbesserungder Qualität der medizinischen Behandlung beitragen,da Gesundheitsdaten zum Zeitpunkt und am Ort derBehandlung durch die Versicherten verfügbar gemachtwerden können.Konsequenzen:Den Versicherten MÜSSEN die für einen besseren Überblicküber ihren Gesundheitszustand notwendigen Auskunftsrechteund Beratungsmöglichkeiten durch alltagstaugliche(A_02439) technische und organisatorische Ver-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 210 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02429A_02430 AD-GRU-03A_02427 AD-GRU-04SSDS _Eckpunkt_03: Die DatenschutzgrundsätzesindsicherzustellenDS _Eckpunkt_04: Verlässlichkeitund Beherrschbarkeitder SystemeDS_Eckpunkt_01: Vorrang(Primat) des Datenschutzesfahren durch die verantwortliche Datenverarbeitungsstelleermöglicht und in ausreichendem Umfang unentgeltlichzur Verfügung gestellt werden (siehe A_02438). DieDurchsetzbarkeit der Betroffenenrechte ist zu gewährleisten(siehe A_02438) und MUSS durch die Telematikinfrastrukturtechnisch unterstützt werden (sieheA_02441, A_02458).Die Datenschutzgrundsätze sind sicherzustellenDie zu schaffenden technischen Verfahren der TelematikinfrastrukturMÜSSEN sich an den Datenschutzgrundsätzenausrichten und damit die Datenhoheit desVersicherten, die Freiwilligkeit der Speicherung der Datenund das Informations- und Leserecht des Versichertensicherstellen. Die Versicherten MÜSSEN darüber entscheidenkönnen, welche ihrer Gesundheitsdaten aufgenommenund welche gelöscht werden und ob und welcheDaten sie einem Leistungserbringer zugänglich machen.Konsequenzen:A_02431, A_02433, A_02434, A_02435, A_02436Verlässlichkeit und Beherrschbarkeit der SystemeAufgrund des sehr hohen Schutzbedarfs der Daten, dievon medizinischen Systemen verarbeitet werden, ergebensich spezielle Sicherheitsmaßnahmen, die aus datenschutzrechtlicherSicht als unabdingbar anzusehen sind.Dies sind insbesondere Kriterien, die die Verlässlichkeitund Beherrschbarkeit von Systemen beschreiben.Anhang B 1Anhang B 1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 211 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleKonsequenzen:Kriterien für die Verlässlichkeit - d. h. die Sicherheit desSystems selbst - sind die Verfügbarkeit (siehe A_02468),Integrität und Vertraulichkeit der Daten (siehe A_02459).Zu den Kriterien für die Beherrschbarkeit - d. h. die Sicherheitvor dem System- sind die Zurechenbarkeit der Daten(siehe A_02466); die Nicht-Abstreitbarkeit (sieheA_02440) und Revisionsfähigkeit (siehe A_02432) vonKommunikationsprozessen; die Nutzungsfestlegung durchZugriffskontrolle (siehe A_02432, A_02464) die Durchsetzbarkeitder Betroffenenrechte u. a. Auskunft, Berichtigung,Sperrung, Löschung (siehe A_02438); die Praktikabilitätund Alltagstauglichkeit der Nutzung (sieheA_02439).Durch Datenvermeidung und Datensparsamkeit bei derÜbertragung und Speicherung sind die Risiken zu begrenzen(siehe A_02456)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 212 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB1.2 - Fachliche Anforderungen und rechtliche RahmenbedingungenBei der Einführung der elektronischen Gesundheitskarte darf sich die datenschutzrechtlichePosition der Versicherten nicht verschlechtern. Die Versicherten sind bisher Herrihrer Daten und das muss auch so bleiben. Die Regelung des § 291a SGB V bietet dennormativen Rahmen, der diesem Parameter in ausreichender Form Rechnung trägt. Dietechnische Umsetzung darf nicht dazu führen, dass datenschutzrechtliche Einbußen erfolgen.Dies sind insbesondere:• Die Verantwortlichkeit und Datenhoheit des Versicherten MUSS durch technischeVerfahren und organisatorische Maßnahmen gewährleistet werden.• Die Nutzungsfestlegung im Rahmen des § 291a MUSS durch technischeMaßnahmen (u. a. Zugriffskontrolle) technisch erzwungen werden.• Die Verfahren MÜSSEN für alle Beteiligten praktikabel und alltagstauglichsein.• Die Rechtssicherheit der Kommunikationsprozesse und Zugriffe für die BeteiligtenMUSS gegeben sein.• Die Durchsetzbarkeit der Betroffenenrechte (Auskunft, Berichtigung, Sperrung,Löschung) MUSS durch organisatorische und technische Verfahren unterstütztwerden. Insbesondere MUSS für den Versicherten eine verantwortlicheStelle für die Datenverarbeitung festgelegt sein.Die grundlegenden Sicherheitsanforderungen ergeben sich zunächst aus § 9 BDSG. DieseVorschrift verlangt allgemein technische und organisatorische Maßnahmen zur Gewährleistungdes Schutzes personenbezogener Daten. Die in der Anlage zu § 9 BDSGbeschriebenen Regelungen (die auch denen einiger Länderdatenschutzgesetze entsprechen)definieren Sicherheitsmaßnahmen und haben im Wesentlichen die technischenKomponenten von Datenverarbeitungsanlagen zum Gegenstand. Aufgrund des sehr hohenSchutzbedarfs der Daten, die von medizinischen Systemen verarbeitet werden, ergebensich spezielle Sicherheitsmaßnahmen, die aus datenschutzrechtlicher Sicht als unabdingbaranzusehen sind.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 213 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 29: Anforderungen des Datenschutzes an die Prozessgestaltung und die FachkonzepteAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02431 AD-FK-01SDS _Fachkonzept_01:Datenhoheit des VersichertenA_02432 AD-FK-02 S DS_Fachkonzept_02:Nutzungsfestlegung und ZugriffsberechtigungenDatenhoheit des Versicherten:(siehe AD-GRU-03)Der Versicherte hat die Datenhoheit für alle seine § 291a-Anwendungen und den darin enthaltenen Gesundheitsdatenin der Telematikinfrastruktur. Ohne die Einwilligung und Freigabedes Zugriffs durch den Versicherten DÜRFEN die freiwilligenmedizinischen Anwendungen NICHT genutzt werden.Ein Austausch von personenbezogenen und medizinischenInformationen eines Versicherten DARF über die Telematikinfrastrukturohne Zustimmung und Information des VersichertenNICHT erfolgen.Für die Pflichtanwendungen MUSS die Zustimmung des Versichertenzum Zugriff auf die Daten durch die Übergabe derGesundheitskarte an den Leistungserbringer bzw. zusätzlichfür die freiwilligen Anwendungen – mit Ausnahme der Notfalldaten- durch eine explizite Autorisierung durch geeignetetechnische Verfahren (z. B. PIN) durch den Versicherten erfolgen.Konsequenzen:o Unumgänglichkeit der aktiven Mitwirkung des Versicherten(siehe AD-GA-22)o Schutz der Daten vor missbräuchlicher Verwendung (sieheAD-GA-32) undSchutz der Beteiligten vor ungerechtfertigen Verdächtigungen(siehe AD-GA-40)Nutzungsfestlegung und Zugriffsberechtigungen(siehe AD-GRU-04, §291a, SGBV)In § 291a Abs. 4 sind die zugriffsberechtigten Leistungserbringergruppenabschließend festgelegt. Ein Zugriff andererPersonen auf die Daten der Versicherten MUSS mit Sicher-Anhang B 1.2Anhang B 1.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 214 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleheitsmechanismen der Mechanismenstärke „sehr hoch“ verhindertwerden.Der Versicherte kann – im vorgegebenen Rahmen des § 291a- für jeden Leistungserbringer entscheiden und festlegen,welche medizinischen Informationen er zur Verfügung stellenwill. In Fällen, in denen der Versicherte nicht anwesend ist, istein geeignetes, nachvollziehbares technisches Verfahren einzusetzen,bei dem die Zustimmung und Information des Versichertenzum Zugriff durch den Leistungserbringer nachvollziehbarund revisionsfähig mit Mechanismenstärke mindestens„hoch“ sichergestellt ist. Ein Versicherter kann dabei – imRahmen der Regelungen des § 291a Absatz 4 - Zugriffsrechteeiner natürlichen Person, einer Institution oder einer festgelegtenGruppe von natürlichen und juristischen Personen jederzeiterteilen bzw. entziehen, die diese autorisieren ohneeGK-Anwesenheit die Daten des Versicherten zu nutzen. DasAusstellen einer Zugriffsberechtigung MUSS unter Nutzungder eGk erfolgen.A_02433 AD-FK-03 S DS_Fachkonzept_03:Freiwilligkeit der Datenspeiche-Konsequenzen:o Zugriff auf medizinischen Daten nur mit eGK und HBA/SMC(siehe AD-GA-21)o Bereitstellung von Komponenten und Schnittstellen zurRechteverwaltung (siehe AD-GA-30)Kostenträger dürfen weder Kenntnis über die Anwendungsdatennoch über die vom Versicherten betriebenen freiwilligenAnwendungen und den darin gespeicherten Berechtigungenerlangen.Freiwilligkeit:(siehe AD-GRU-02, AD-GRU-03, AD-FK-01, § 291a, Abs. 8,Satz 2, SGB V)Anhang B 1.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 215 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellerung.A_02434 AD-FK-04 S DS_Fachkonzept_04:Übernahme und Löschung vonDatenDie Speicherung von Gesundheitsdaten ist grundsätzlich freiwilligund im Ermessen des Versicherten. Versicherte dürfennicht bevorzugt oder benachteiligt werden, weil sie einenZugriff bewirkt oder verweigert haben.Konsequenzen:o Die Prozessgestaltung für die Speicherung von GesundheitsdatenMUSS die Freiwilligkeit des Versicherten durchorganisatorische oder technische Maßnahmen garantieren.Die technischen Maßnahmen MÜSSEN in Kommunikationsmusternbeschrieben werden.o Unumgänglichkeit der aktiven Mitwirkung des Versicherten(siehe AD-GA-22)Zugriff auf medizinische Daten nur mit eGK bzw. das Ausstelleneiner Berechtigung MUSS unter Nutzung der eGK erfolgen.Übernahme und Löschung von Daten:(siehe AD-GRU-02, AD-GRU-03, AD-FK-01)Der Versicherte MUSS darüber entscheiden können, welcheseiner Gesundheitsdaten aufgenommen und welche gelöschtwerden.Konsequenzen:o Die Prozessgestaltung für die Übernahme und LöschungMUSS die Einwilligung des Versicherten durch organisatorischeoder technische Maßnahmen garantieren. Die technischenMaßnahmen MÜSSEN in Kommunikationsmusternbeschrieben werden.o Unumgänglichkeit der aktiven Mitwirkung des Versicherten(siehe AD-GA-22)Aufnahme und Löschung von medizinischen Daten nur mitAnhang B 1.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 216 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleeGK bzw. das Ausstellen einer Berechtigung MUSS unterNutzung der eGK erfolgen.A_02435 AD-FK-05 S DS _Fachkonzept_05:Übergabe von Daten anLeistungserbringerÜbergabe von Daten an Leistungserbringer:(siehe AD-GRU-02, AD-GRU-03)Der Versicherte MUSS darüber entscheiden können, ob undwelche Daten er einem Leistungserbringer zugänglich macht.Anhang B 1.2A_02436 AD-FK-06 S DS_Fachkonzept_06:Informations- und Leserecht desVersicherten.Konsequenzen:o Die Prozessgestaltung für die Übergabe der Daten MUSSdie Einwilligung des Versicherten durch organisatorische odertechnische Maßnahmen garantieren. Die technischen MaßnahmenMÜSSEN in Kommunikationsmustern beschriebenwerden.o Unumgänglichkeit der aktiven Mitwirkung des Versicherten(siehe AD-GA-22)Aufnahme und Löschung von medizinischen Daten nur miteGK bzw. das Ausstellen einer Berechtigung MUSS unterNutzung der eGK erfolgen.Informations- und Leserecht:(siehe AD-GRU-02, AD-GRU-03, AD-FK-01)Der Versicherte hat das Informations- und Leserecht, überseine gespeicherten Daten und alle diese Daten betreffendenVorgänge.Anhang B 1.2Konsequenzen:o Alltagstaugliche (AD-FK-09) technische und organisatorischeVerfahren MÜSSEN dem Versicherten unentgeltlich zumLesen seiner Daten zur Verfügung gestellt werden.o Jeder Zugriff auf die Versichertendaten MUSS dem Versicherteneindeutig erkennbar angezeigt oder mitgeteilt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 217 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleVersichertenzentrierte Darstellung Protokollierung(siehe AD-GA-41)A_02437 AD-FK-07 S DS _Fachkonzept_07:Erkennbarkeit der KommunikationsvorgängeErkennbarkeit der Kommunikationsvorgänge(siehe AD-FK-01, §6c Abs. 3, BDSG )Die Kommunikationsvorgänge, die auf der Gesundheitskarteund in der Telematikinfrastruktur eine Datenverarbeitung auslösen,müssen für den Betroffenen eindeutig erkennbar sein.Anhang B 1.2A_02438 AD-FK-08 S DS_Fachkonzept_08:Durchsetzbarkeit der BetroffenenrechteKonsequenzen:ProzessgestaltungDie Erkennbarkeit der Kommunikationsvorgänge für den VersichertenMUSS bei der Prozessmodellierung und –gestaltung berücksichtigt werden. Insbesondere bei Prozessen,bei denen der der Versicherte nicht persönlich anwesendist, MÜSSEN besondere Maßnahmen getroffen und die auftretendenRisikenDurchsetzbarkeit der Betroffenenrechte(siehe AD-GRU-02, AD-GRU-04)Den Versicherten MÜSSEN die für einen besseren Überblicküber ihren Gesundheitszustand notwendigen Auskunftsrechteund Beratungsmöglichkeiten durch technische und organisatorischeVerfahren im notwendigen Umfang kostenfrei zurVerfügung gestellt werden. Die Telematikinfrastruktur MUSSdie Durchsetzbarkeit der Betroffenenrechte ermöglichen undtechnisch unterstützen.Anhang B 1.2Konsequenzen:Komponenten und Schnittstellen zur Wahrnehmung der Betroffenenrechte(siehe AD-GA-30)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 218 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02439 AD-FK-09 S DSPraktikabilität und Alltagstauglichkeit_Fachkonzept_09:Praktika (siehe AD-GRU-02, AD-GRU-04)bilität und AlltagstauglichkeitDie Telematikinfrastruktur, die Prozessgestaltung sowie dieBereitstellung der Umgebungen zur Wahrnehmung der VersichertenrechteMUSS die Praktikabilität und Alltagstauglichkeitberücksichtigen und technisch unterstützen, so dass bestimmtePersonengruppen (z. B. ältere Menschen) durch eineTechnisierung nicht benachteiligt werden.Anhang B 1.2Konsequenzen:o Nutzung der freiwilligen medizinischen Anwendungen währenddes BehandlungsbesuchsDie Nutzung der freiwilligen medizinischen AnwendungenMUSS dem Versicherten im Rahmen der Behandlung durchden Leistungserbringer ermöglicht werden. Eine Verzögerungder Nutzung bzw. ein zusätzlicher Aufwand und Wege sindeinem Versicherten nicht zuzumuten. Beispielsweise MUSSdie Behandlung von Fehlerfällen (PIN vergessen, Kartensperrungwegen mehrfacher falscher PIN-Eingabe) im Rahmeneines Arzt- oder Apothekerbesuches erfolgen können. DieseProzesse sind so zu gestalten, dass hier keine zusätzlichenWege für den Versicherten und eine Verzögerung der Behandlungeintreten.o Nutzung der Versichertenrechte während des BehandlungsbesuchsDie Wahrnehmung der Versichertenrechte MUSS dem Versichertenim Rahmen der Behandlung durch den Leistungserbringerermöglicht werden. Eine Verzögerung der Nutzungbzw. ein zusätzlicher Aufwand und Wege sind einem Versi-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 219 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellecherten nicht zuzumuten.Die Wahrnehmung der Versichertenrechte (Vergabe vonRechten, Einwilligungen) MUSS z. B. im Rahmen eines ArztoderApothekerbesuches erfolgen können. Diese Prozessesind so zu gestalten, dass hier keine zusätzlichen Wege fürden Versicherten und eine Verzögerung in der Wahrnehmungder Versichertenrechte eintreten.o Praktikable Verfahren für Nutzung der medizinische Anwendungenund der VersichertenrechteA_02440 AD-FK-10 S DS_Fachkonzept_10:Nachweisbare Datenübergabe undProtokollierung der ZugriffeDie Nutzung der freiwilligen medizinischen Anwendungensowie die Wahrnehmung der Versichertenrechte MUSS durchmöglichst praktikable und intuitiv für den Versicherten verständlicheVerfahren der jeweiligen Autorisierungen ermöglichtwerden. Beispielsweise wird eine komplizierte Verwendungvon 6 unterschiedlichen Autorisierungstokens (2PINs,2PUKs, 2 TransportPINs) als nicht tauglich für alle Versichertengruppenangesehen. Die IT-Systeme MÜSSEN so gestaltetsein, dass für bestimmte Versichertengruppen eine PINausreichend ist.Praktikable und handhabbare Gestaltung der IT-Systeme(siehe AD-GA-60).Nachweisbare Datenübergabe und Protokollierung der Zugriffe(siehe AD-GRU-04 , Anlage zu §9, Satz 1, Nummer 5, BDSG,§291a, Abs.6, Satz 2)Die Komponenten und Dienste der TelematikinfrastrukturMÜSSEN gewährleisten, dass nachträglich nachvollziehbarüberprüft und festgestellt werden kann, ob, von wem undwann Daten in die §291a Anwendungen und Fachdiensteeingegeben, verändert, entfernt oder gelesen worden sind.Anhang B 1.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 220 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleBei Zugriffen auf die Daten in der eGK ist zu gewährleisten,dass mindestens die letzten fünfzig Zugriffe für Zwecke derDatenschutzkontrolle protokolliert werden.Die Protokolldaten MÜSSEN durch geeignete Vorkehrungengegen zweckfremde Verwendung und sonstigen Missbrauchmit Mechanismen der Stärke mindestens hoch geschütztwerden.Die Revisionsfähigkeit von Kommunikationsprozessen erfordertdie Erfüllung des Kriteriums der Nicht-Abstreitbarkeit undder Authentizität der Daten und Zugriffe. Sie ist nur ein Teilaspektder Revisionsfähigkeit aller Verarbeitungsvorgängeund muss durch die Gestaltung der Geschäftsprozesse sichergestelltwerden.A_02441AD-FK-11 SDS_Fachkonzept_11:Ungerichtete KommunikationKonsequenzen:o Nichtabstreitbarkeit und revisionsfähige Protokollierung(siehe AD-GA-40)Versichertenzentrierte Darstellung Protokollierung(siehe AD-GA-41)Ungerichtete Kommunikation( siehe AD-GRU-02, AD-FK-04, AD-FK-05)Anhang B 1.2Die Durchsetzbarkeit des Rechts auf freie Arztwahl bzw. Wahldes Leistungserbringers setzt die Möglichkeit der ungerichtetenKommunikation voraus. Die Telematikinfrastruktur wirddiese Kommunikationsform als Regelfall in den Fachprozessenmodellieren sowie technisch realisieren.Konsequenzen:o Die Prozessgestaltung der §291a Anwendungen MUSS diegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 221 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellefreie Wahl des Leistungserbringers ermöglichen.Die Kommunikationsmuster der Telematikinfrastruktur MÜS-SEN eine dienstorientierte ungerichtete Kommunikation alsRegelfall bereitstellen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 222 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB1.2.1 - Anforderungen und Funktionen für PflichtanwendungenDie Anforderungen in Tabelle 30 ergeben sich aus dem Fachkonzepten [gemFK_VSDM] und [gemFK_VODM].Tabelle 30 - Anforderungen und Funktionen für PflichtanwendungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02442 AD-VSDD-01 SA_02443 AD-VODD-01 SA_02444 AD-VODD-02 SA_02445 AD-VODD-03 SA_02446 AD-VODD-04 SA_02447 AD-VODD-05 SDS_Pflicht_AW_VSDD_01: Anzeigen von StammdatenDS_Pflicht_AW_VODD_01: Anzeigen von eVerordnungen.DS_Pflicht_AW_VODD_02: Löschen von eVerordnungen.DS_Pflicht_AW_VODD_03: Einsicht in eVerordnun-gen-DS_Pflicht_AW_VODD_04: Verbergen von eVerordnungen.DS_Pflicht_AW_VODD_05: Einlösen von eVerordnungenVersicherte müssen ihre Stammdaten eigenständig anzeigenkönnen.Versicherte müssen ihre eVerordnungen eigenständig anzeigenlassen können.Versicherte müssen eigenständig einzelne ihrer noch nichteingelösten eVerordnungen löschen können.Kein Unbefugter darf eine eVerordnung einsehen, eine eVerordnungunzulässig kopieren oder den Verlauf der eVerordnungbis zum Einlösen nachvollziehen könnenVersicherte müssen einzelne ihrer eVerordnungen eigenständigverbergen und wieder sichtbar machen könnenVersicherte müssen ausgewählte, nicht verborgene eVerordnungeneinlösen könnenAnhang B 1.2Anhang B 1.2Anhang B 1.2Anhang B 1.2Anhang B 1.2Anhang B 1.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 223 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB1.2.2 - Anforderungen und Funktionen für freiwillige AnwendungenDie Anforderungen in Tabelle 31 ergeben sich aus dem Fachkonzepten [gemFK_VfA], [gemFK_AdV] und dem §291a SGB V.Tabelle 31 - Anforderungen und Funktionen für freiwillige AnwendungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02448 AD-VfA-03SA_02449 AD-VfA-04 SA_02450 AD-VfA-03 SA_02451 AD-VfA-04 SDS_Freiw_AW_Vfa_01:Einwilligung des Versichertenund Widerruf.DS_ Freiw _AW_Vfa_02:Verbergen freiwilliger Anwendungen.DS_ Freiw _AW_Vfa_03:Verbot der Löschungdurch den Versicherten.DS_ Freiw _AW_Vfa_04:Dokumentation eines Widerrufs.Die Einwilligung eines Versicherten zu einer freiwilligen Anwendungist jederzeit widerruflich und MUSS auf einzelne Anwendungenbeschränkt werden können.Der Versicherte MUSS eigenständig einzelne seiner freiwilligenAnwendungen verbergen bzw. wieder sichtbar machen können.[Ein Verbergen von Teilen einer freiwilligen Anwendung ist bishernicht möglich. Der Fokus der freiwilligen Anwendungen liegt bisherauf den Anwendungen NFDM und AMTS. Für die elektronischePatientenakte können jedoch zukünftig differenziertere Möglichkeitendes Verbergens notwendig sein]Eine eigenständige Löschung von einzelnen Datensätzen innerhalbeiner freiwilligen medizinischen Anwendung durch den Versichertenist nicht vorgesehen.Für die Löschung von einzelnen Einträgen in freiwilligen Anwendungenist aufgrund der medizinischen Auswirkungen für jedeLöschung die Beratung eines Heilberuflers vorauszusetzen.Leistungserbringer dokumentieren den Widerruf einer freiwilligenAnwendung durch den Versicherten auf dessen eGK und die gesamtenDaten der widerrufenen freiwilligen Anwendung werdengelöscht.Anhang B 1.2Anhang B 1.2Anhang B 1.2Anhang B 1.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 224 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02452 AD-Pat-01 S DS_ Freiw_AW_PatFach_01: FreiwilligeNutzung des Patientenfachs.A_02453 AD-Pat-02 S DS_ Freiw_AW_PatFach_02: Freiwillligkeitder Datenbereitstellungim Patientenfach.A_02454 AD-Pat-03 S DS_ Freiw_AW_PatFach_03: Zugriffauf im Patientenfach bereitsgestellteDaten.A_02455 AD-Pat-04 S DS_ Freiw_AW_PatFach_04: Zugriffauf Patientenfach mitSiganturkarteDem Versicherten steht die freiwillige Anwendung Patientenfachzur Verfügung.Der Versicherte kann eigene Daten mittels des Patientenfachesbereitstellen.Leistungserbringer können mittels des Patientenfachs Daten fürden Versicherten bereitstellen. Der Versicherte kann auf diesebereitgestellten Daten eigenständig zugreifen.Im Falle des Patientenfaches können Versicherte auch mittelseiner eigenen Signaturkarte zugreifen, die über eine qualifizierteSignatur verfügt.Anhang B 1.2Anhang B 1.2Anhang B 1.2Anhang B 1.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 225 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB1.3 - Anforderungen an die ArchitekturAufgrund des sehr hohen Schutzbedarfs der Daten, die von medizinischen Systemen verarbeitetwerden, ergeben sich spezielle Architekturprinzipien und Sicherheitsmaßnahmen,die aus datenschutzrechtlicher Sicht als unabdingbar anzusehen sind. Dies sind insbesondereKriterien, die die Verlässlichkeit und Beherrschbarkeit von Systemen beschreiben.Kriterien für die Verlässlichkeit (d. h. die Sicherheit des Systems selbst) sind• Verfügbarkeit,• Integrität und• Vertraulichkeit der Daten.Zu den Kriterien für die Beherrschbarkeit (d. h. die Sicherheit vor dem System) zählen:• Nutzungsfestlegung (Zugriffskontrolle)• Zurechenbarkeit (hier: Zurechenbarkeit der Daten)• Nicht-Abstreitbarkeit (hier: von Kommunikationsprozessen)• Revisionsfähigkeit (hier: von Kommunikationsprozessen)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 226 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 32: Anforderungen des Datenschutzes an die GesamtarchitekturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleArchitekturprinzipienA_02456 AD-GA-01A_02457 AD-GA-02A_02083DS_GesamtArchitektur_01: Gebotder Datensparsamkeit undDatentrennung.DS_GesamtArchitektur_02: BerücksichtigungDatenschutz inArchitekturentscheidungenDS_GesamtArchitektur_03: ExterneVerwendung und Speiche-Datensparsamkeit und Datentrennung(siehe AD-GRU-04, AD-GRU-04, auch § 3a, BDSG, § 78b, SGBX)Um u. a. das Erstellen von Bewegungsprofilen und z. B. eine Analysedes Verschreibungsverhaltens, zu verhindern, DÜRFEN nur dieminimal für die Funktionalität notwendigen Daten übertragen werden.Die Daten sind in der Telematikinfrastruktur so zu übertragen bzw. zuspeichern, dass eine Zusammenführung und Profilbildung nicht möglichist.Dies bezieht auch die Identifikationsmerkmale (z. B. Krankenversicherungs-,Kartennummer) ein. Insbesondere ist von den Möglichkeitender Anonymisierung und Pseudonymisierung Gebrauch zu machen,soweit dies möglich ist und der Aufwand in einem angemessenenVerhältnis zu dem angestrebten Schutzzweck steht. Diese Identifikationsmerkmaledürfen außerhalb der medizinischen Anwendungenim Gesundheitswesen nicht verwendet werden. Insbesonderebei einer dualen Nutzung der Gesundheitskarte innerhalb und außerhalbdes Gesundheitswesens ist ein unberechtigter Zugriff aufIdentifikationsdaten durch technische und organisatorische Maßnahmenzu verhindern.Berücksichtigung Datenschutz in Architekturentscheidungen(siehe AD-GRU-01)Die Erfordernisse des Datenschutzes sind bei allen Architekturentscheidungenexplizit zu berücksichtigen und sind stärker zu gewichtenals alle anderen Kriterien. Eine Einschränkung des DatenschutzesDARF NICHT erfolgen. Es MUSS eine aufwendigere und ggf.teurere Option gewählt werden, bevor die Datenschutzgrundsätzeeingeschränkt werden.Externe Verwendung und Speicherung der lebenslang eindeutigenIdentitätsdaten des Versicherten (KVNR)Anhang B1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 227 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturrung der lebenslang eindeutigenIdentitätsdaten des Versicherten(KVNR)Eine externe Verwendung und Speicherung der KVNR SOLL vermiedenwerden.(Die mögliche Verwendung der KVNR als einheitliches Personenkennzeichenin Anwendungen außerhalb des GesundheitswesensSOLL vermieden werden. Die gematik wird eine externe Nutzung derKVNR nicht aktiv unterstützen, sondern durch geeignete organisatorischeMaßnahmen erschweren bzw. technische Maßnahmen unterbinden.Um die Rückwärtskompatibilität und Interoperabilität der eGK zurKVK zu erhalten, ist für die Einführungsphase und die Generation-1-Karten die KVNR ungeschützt durch jede Anwendung auszulesen.Die Zugriffs- und Weitergabemöglichkeiten sind durch die Verwendungder eGK in der Verantwortung des Versicherten. Bei einer flächendeckendenEinführung der Gesundheitstelematik SOLL derZugriff auf die KVNR in der eGK jedoch durch technische Maßnahmenauf die berechtigten Leistungserbringer eingeschränkt werden,um eine Weitergabe dieser Sozialdaten an Unberechtigte technischzu verhindern.)Umgebungen und Schnittstellen für den Versicherten zur Wahrnehmung der VersichertenrechteA_02458 AD-GA-10DS_GesamtArchitektur_04:Schnittstellen und Komponenten zurInteraktion des Versicherten mitder TISchnittstellen und Komponenten zur Interaktion des Versicherten mitder TI(siehe AD-GRU-02)Den Versicherten müssen die zur Wahrnehmung des Auskunftsrechtserforderlichen Geräte oder Einrichtungen in angemessenemUmfang zum unentgeltlichen Gebrauch zur Verfügung gestellt werden.Versicherten werden Umgebungen bzw. Komponenten unentgeltlichzur Verfügung gestellt, in bzw. mit denen sie Funktionen zur Einsichtin ihre Daten, zum „Verbergen/Sichtbarmachen“ bestimmter Datenund freiwilliger Anwendungen sowie zur Verwaltung der Berechtigungenfür die Nutzung ihrer Daten unbeobachtet und eigenständigwahrnehmen können (eKiosk-Umgebungen, Versicherter@home).Konsequenzen:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 228 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturo Versicherten wird eine Fachdienst-übergreifende, logisch einheitlicheSchnittstelle zur Verwaltung von Berechtigungen zur Verfügunggestellt.o Dem Versicherten werden praxistaugliche Verfahren zur Autorisierungdes Zugriffs und zur Verwaltung der dazu notwendigen PIN – z.B. PIN-Änderungen, Rücksetzung Fehlbedienungszähler – angeboteno Anwendungs- und Rechteverwaltung muss in einer handhabbarenAnwendungsverwaltung mit einer einheitlichen, allgemein verständlichenOberflächengestaltung möglich sein.o Die Verwaltung von im Ermessen des Versicherten stehendenRechten ist informationstechnisch von der Nutzung der Anwendungendurch Leistungserbringer zu trennen.Die Trennung der Verwaltung der Versichertenrechte von der Nutzungder § 291a Anwendungen durch die Leistungserbringer MUSSfür den Versicherten deutlich erkenntlich sein.DatensicherheitA_02459 AD-GA-20A_02460 AD-GA-21DS_GesamtArchitektur_05: Verschlüsselungder medizinischenDaten in der TIDS_GesamtArchitektur_06:Zugriff auf medizinische Datennur mittels eGK und HBA/SMCVerschlüsselung der medizinischen Daten in der TI(siehe AD-GRU-04 und AD-GA-01)Medizinische Daten sind in der Telematikinfrastruktur grundsätzlichverschlüsselt (siehe [Grundsatzentscheidung]) und nicht im Klartextverfügbar und bearbeitbar.Die Verschlüsselungsschlüssel sind in der alleinigen Verfügungsgewaltdes Versicherten, damit dieser und nur dieser entscheiden kannwelche Daten welchen dritten Personen zugänglich gemacht werden.Zugriff auf medizinische Daten nur mittels eGK und HBA/SMC(siehe AD-FK-02, §291a, Abs. 5, SGB V)Der Zugriff auf medizinische Daten mittels der elektronischen GesundheitskarteMUSS in Verbindung mit einem elektronischen Heilberufsausweisoder mittels einer SMC erfolgen, die über eine Möglichkeitzur sicheren Authentifizierung verfügen. Der HBA MUSS übereine qualifizierte elektronische Signatur verfügen. Der Zugriff mittelsgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 229 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02461 AD-GA-22A_02462 AD-GA-23DS_GesamtArchitektur_07: Unumgänglichkeitder aktiven Mitwirkungdes VersichertenDS_GesamtArchitektur_08: Sicherheitsdiensteund SicherheitsinfrastrukturenSMC ist nur für die Personengruppe nach §291a Abs. 4 Satz 1 Nr. 1Buchstabe d und e sowie Nr. 2 Buchstabe d und e SGB V möglich.Es MUSS dabei im Primärsystem nachweisbar protokolliert werden,wer auf die Daten zugegriffen hat und von welcher Person die zugreifendePerson autorisiert wurde.Unumgänglichkeit der aktiven Mitwirkung des Versicherten(siehe AD-FK-01)Die Unumgänglichkeit der aktiven Mitwirkung des Versicherten beider Gewährung der Zugriffe, der Verwaltung der Zugriffsrechte undder Verwaltung der medizinischen Informationen (z. B. Patientenfach)für die berechtigten Personengruppen (SGB V § 291 a Absatz4) und innerhalb den gesetzlich festgelegten technischen Zugriffsbedingungen(SGB V § 291a Absatz 5) MUSS technisch – durch Maßnahmenmindestens der Mechanismenstärke „hoch“ – sichergestelltwerdenSicherheitsdienste und Sicherheitsinfrastrukturen(siehe AD-GRU-04)Sicherheitsdienste und Sicherheitsinfrastrukturen der Mechanismenstärke„hoch“ und „sehr hoch“ MÜSSEN von der TI bereitgestelltwerden und MÜSSEN entsprechend der Schutzbedarfsfestlegung fürdie fachlichen und technischen Objekte verwendet werden.Der aktuell gültige Algorithmenkatalog der gematik MUSS verwendetwerden.Zugriffskontrolle und BerechtigungsverwaltungA_02463 AD-GA-30A_02464 AD-GA-31DS_GesamtArchitektur_09: Komponenten und Schnittstellen zur RechteverwaltungKomponenten und Schnittstellen (siehe AD-FK-02, AD-FK-08)zur RechteverwaltungEs MÜSSEN technische Vorkehrungen getroffen und den Versichertenverfügbar gemacht werden, mit welchen sie die Rechte über ihreDaten und ihre Daten selbst aktiv verwalten können.Der Versicherte kann für jeden Leistungserbringer festlegen, welcheInformationen er ihm zur Verfügung stellen willDS_GesamtArchitektur_10:Berechtigungen und ZugriffskontrolleBerechtigungen und Zugriffskontrolle(siehe AD-GRU-04, AD-GA-22)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 230 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02465 AD-GA-32DS_GesamtArchitektur_11:Schutz der Daten vor missbräuchlicherVerwendungDas Autorisierungs- und Berechtigungskonzept und die RechteverwaltungMUSS durch technische Maßnahmen mindestens der Mechanismenstärke„hoch“ die Unumgänglichkeit der aktiven Mitwirkungdes Versicherten gewährleisten.Konsequenzeno Im Konnektor und in Fachdiensten ist zwischen Rechteverwaltungs-und Kerndienst-Schnittstellen zur Nutzung der Anwendungenzu unterscheiden.(Siehe AD-FK-07): Die informationstechnische Trennung der Verwaltungder Versichertenrechte vom Zugriff der Leitungserbringer auf die§291a Anwendungen MUSS für den Versicherten erkennbar sichergestelltwerden.Schutz der Daten vor missbräuchlicher Verwendung(siehe AD-FK-01)Bei allen Geschäftsvorfällen der Telematikinfrastruktur mit Zugriffenauf medizinische und personenbezogene Daten MUSS ein vorbeugenderAusschluss unzulässiger Zugriffe sowie eine nachträglicheErkennung und Verfolgung unzulässiger Zugriffe technisch (AD-GA-40) unterstützt werden.Sicherheitsdienste mit der Mechanismenstärke „hoch“ MÜSSEN inder Sicherheitsinfrastruktur bereitgestellt werden, um alle an der InformationsverarbeitungBeteiligten von missbräuchlicher Benutzungvon Daten und Ressourcen abzuhalten.Nichtabstreitbarkeit der Zugriffe und revisionsfähige ProtokollierungA_02466 AD-GA-40DS_GesamtArchitektur_12:Schutz der Beteiligten vor ungerechtfertigenVerdächtigungenSchutz der Beteiligten vor ungerechtfertigen Verdächtigungen(siehe AD-FK-01, AD-FK-10, Anlage zu § 9, Satz 1, Nummer 5,BDSG)Bei allen Geschäftsvorfällen der Telematikinfrastruktur mit Zugriffenauf medizinische und personenbezogene Daten MUSS ein vorbeugenderAusschluss unzulässiger Zugriffe (AD-GA-32) sowie einenachträgliche Erkennung und Verfolgung unzulässiger Zugriffe technischunterstützt werden.Sicherheitsdienste mit der Mechanismenstärke „hoch“ MÜSSEN ingematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 231 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02467 AD-GA-41DS_GesamtArchitektur_13:Versichertenzentrierte DarstellungProtokollierungder Sicherheitsinfrastruktur bereitgestellt werden, um alle an der InformationsverarbeitungBeteiligten vor ungerechtfertigten Verdächtigungenzu schützen.KonsequenzenFür die Primärsysteme und Fachdienste MUSS eine revisionsfähigeProtokollierung der Zugriffe (Eingabekontrolle) realisiert sein, so dassnachträglich überprüft und festgestellt werden kann, ob und von wempersonenbezogene Daten eingegeben, verändert, gelesen oder entferntworden sind.Versichertenzentrierte Darstellung Protokollierung(siehe AD-FK-10, § 291a, Abs.6, Satz 2, Anlage zu § 9, Satz 1,Nummer 8, BDSG)Es werden folgende Daten im Auditdienst bereitgestellt: „WER“,„WANN“, „WELCHE“ Anwendung genutzt hat. Bei der Bereitstellungdieser Daten MUSS das Prinzip der Datensparsamkeit berücksichtigtwerden (siehe AD-GA-01).Die protokollierten Zugriffe für Datenschutzzwecke werden dem Versichertenunabhängig vom Speicherort in einer allgemein verständlichen,übersichtlichen Form angezeigt. Dazu MÜSSEN die patientenzentriertenAuditinformationen verschiedener Fachdienste für einenVersicherten zusammengeführt werden. Dabei MÜSSEN die zu unterschiedlichenAnwendungen erhobenen Protokolldaten getrenntverarbeitet und dargestellt werden können.Unberechtigte Nutzung (z. B. Profilbildungen) MÜSSEN durch Maßnahmenmit Mechanismenstärke von mindestens „hoch“ verhindertwerden.Dem Versicherten MÜSSEN Möglichkeiten zur unbeobachteten Einsichtnahmein das Zugriffsprotokoll angeboten werden.Verfügbarkeit der Anwendungen und medizinischen Daten bei KartenwechselA_02468 AD-GA-50DS_GesamtArchitektur_14:Verfügbarkeit bei KartenwechselVerfügbarkeit bei Kartenwechsel(siehe AD-GRU-04 und § 291 Abs.4, SGB V)Nach dem Kartenwechsel MUSS gewährleistet werden, dass diefreiwilligen Anwendungen weiterhin genutzt werden könnengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 232 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02469 AD-GA-51A_02470 AD-GA-52DS_GesamtArchitektur_15: DatenerhaltNotfalldaten.DS_GesamtArchitektur_16: Datenerhaltvon Einwilligungen undWiderrufen.Die Daten nach §291a Abs. 3 Satz 1 eines Versicherten werden sogesichert und bereitgestellt, dass sie nach einem Kartenwechsel weiterhinnutzbar sind.Wenn der Versicherte keine Einwilligung zur Notfalldaten-Sicherungin der TI gegeben hat und der Versicherte die Notfalldaten auf dieFolgekarte übernehmen möchte, so MUSS sich der Versicherte imFalle der freiwilligen Anwendung Notfalldaten selbst darum kümmern,dass die Notfalldaten auf die Folgekarte übertragen werden.Es ist sicherzustellen, dass die Informationen der Einwilligung aufFolgekarten übertragen werden können, ohne dass die Einwilligungsdokumentationendurch den Versicherten erneut vorzunehmensind. Die auf der eGK enthaltenen Widerrufsdokumentationen MÜS-SEN ebenso auf die neue Karte übernommen werdenNichtfunktionale AnforderungenA_02471 AD-GA-60DS_GesamtArchitektur_17:Praktikable und handhabbareGestaltung der IT-SystemePraktikable und handhabbare Gestaltung der IT-Systeme(siehe AD-FK-09)Die eingesetzten Systeme MÜSSEN für die Anwender (Versicherte,Heil- und Gesundheitsberufe etc.) praktikabel und handhabbar gestaltetwerden. Insbesondere DARF eine Versichertengruppe (z. B.ältere oder kranke Menschen) NICHT durch die Technisierung benachteiligtwerden und in der Wahrnehmung der Versichertenrechteeingeschränkt werden.Konsequenzen:Dem Versicherten wird über die Anwendungsverwaltung eine einheitlichelogische Sicht auf seine Anwendungen in der Telematikinfrastrukturund die darin vergebenen Rechte gegebengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 233 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB2 - Grundlegende SicherheitsanforderungenDer folgende Abschnitt gibt einen Überblick über grundlegende Sicherheitsanforderungen(auch als Sicherheitsziele bekannt) an die TI, welche dann, durch die entsprechende Umsetzungin der Gesamtarchitektur und durch Festlegungen im Sicherheitskonzept erreichtund eingehalten werden MÜSSEN. Die Anforderungen sind der verbindliche, einzuhaltendeMindeststandard, der neben weiteren technischen und organisatorischen Maßnahmenumgesetzt werden MUSS, um das notwendige Sicherheitsniveau zu gewährleisten. Eineweitergehende Beschreibung von Sicherheitsanforderungen und -maßnahmen MUSSdann in den notwendigen Sicherheitsprofilen (Protection Profiles nach Common Criteria)und Sicherheitspolicies (Betreiberpolicy, PKI-Policy) erfolgen.B2.1 - Sicherheitsziele(-anforderungen)Im Bereich der Informationssicherheit lassen sich bestimmte Sicherheitsziele definieren,die an ein IT-System oder eine IT-Infrastruktur gestellt werden. Diese Sicherheitszielegelten für die TI und die verschiedenen medizinischen Anwendungen. Dazu gehören folgendePunkte:• Vertraulichkeit: Personenbezogene Daten (insbesondere Sozialdaten undmedizinische Daten) im Umfeld der medizinischen Versorgung MÜSSEN inder Regel als streng vertraulich behandelt werden. Dieser Vertraulichkeitsanspruchdes Versicherten ist in verschiedenen Gesetzen festgelegt. Des Weiterenbeinhaltet der Anspruch nach vertraulicher Behandlung von Daten denAnspruch des Versicherten, seine informationelle Selbstbestimmung wahrnehmenzu können, indem er die Daten nur Berechtigten zugänglich macht.Eine Verletzung dieser Sicherheitsanforderung kann für den Versicherten zunicht unerheblichen sozialen oder materiellen Schäden führen. AndererseitsMUSS der Versicherte darüber informiert werden, dass er dieses Recht auf informationelleSelbstbestimmung dem behandelnden Leistungserbringer undsich selbst gegenüber in vertrauenswürdiger Weise nutzen sollte, um Schadensfällezu vermieden. Daraus ergibt sich, dass die personenbezogenen Datenbei der Übertragung und Speicherung (mindestens einmal) verschlüsseltsein MÜSSEN. Das Schlüsselmanagement MUSS nach dem aktuellen Standder Technik und Wissenschaft sicher sein.• Authentizität: Die Authentizität der im medizinischen Umfeld erhobenen, gespeicherten,verarbeiteten und transportierten Daten MUSS gewährleistetsein, d. h. der Autor bzw. der Verantwortliche von patientenbezogenen sowieder Auslöser eines Verarbeitungsganges MÜSSEN jederzeit eindeutig feststellbarsein. Dabei ist es unerheblich, ob es sich dabei um eine natürlichePerson, eine Organisation oder eine technische Komponente handelt. DesWeiteren MUSS die Herkunft (eine natürliche oder juristische Person) der imRahmen der Personalisierung auf eine Karte aufgebrachten Daten aus derSicht der personalisierenden Stelle eindeutig bestimmbar und prüfbar sein.• Integrität: Die Integrität der erhobenen, verarbeiteten, transportierten und gespeichertenDaten MUSS gewährleistet sein. Die Daten DÜRFEN NICHT unbemerktmanipuliert werden. Ihre Korrektheit, Echtheit und Vollständigkeit istfür den Behandlungserfolg außerordentlich wichtig.• Autorisierung: Medizinische Datenverarbeitungssysteme MÜSSEN es ermöglichen,dass der Kreis der Zugriffsberechtigten auf Patientendaten durchgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 234 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturabgestufte Nutzungsrechte exakt bestimmbar und abgrenzbar ist. Durch geeigneteVerfahren ist sicherzustellen, dass ein Zugriff auf die Daten des Versichertennur mit seinem Einverständnis erfolgen KANN. Sollte der Versichertenicht in der Lage sein, diese Rechte wahrnehmen zu können, so ist durch geeigneteorganisatorische wie auch technische Verfahren sicherzustellen, dassentsprechend den gesetzlichen Vorgaben seine medizinische Versorgungnicht beeinträchtigt wird. Die Erteilung von Zugangsberechtigungen DÜRFENbei den medizinischen Pflichtanwendungen nicht zu Diskriminierungen aufGrund der angewandten technischen Verfahren werden.• Nichtabstreitbarkeit: Die Nichtabstreitbarkeit des Sendens und Empfangensvon patientenbezogenen Informationen/Dokumenten MUSS gewährleistetsein. Diese Nichtabstreitbarkeit MUSS sich sowohl auf den Vorgang der Übertragungwie auch auf das Objekt der Übertragung beziehen. Die Nichtabstreitbarkeitist eine Voraussetzung der Revisionsfähigkeit.• Revisionsfähigkeit: Die Revisionsfähigkeit der erhobenen, gespeicherten,übermittelten oder verarbeiteten Daten MUSS gewährleistet sein, damit dieVerarbeitungsprozesse lückenlos nachvollzogen werden können. Für den Arztbzw. das Krankenhaus besteht nach der Berufsordnung die Pflicht zur Dokumentationder Behandlung. Diagnosen und Therapien MÜSSEN zwecks Ausschlussvon Haftungen lückenlos nachvollziehbar sein.• Verfügbarkeit: Die Verfügbarkeit aller erfassten, übermittelten und gespeichertenDaten MUSS gewährleistet sein. Das bedeutet, dass die Daten einesVersicherten immer zeitnah zur Verfügung stehen MÜSSEN, um ordnungsgemäßbe- und verarbeitet werden zu können.Weitere relevante Punkte zu den Sicherheitszielen:Zu Authentizität gilt weiter: Es MUSS gewährleistet sein, dass eine getrennte Authentisierungund Autorisierung auf mehreren Ebenen oder Schichten stattfindet (Netzwerk-,Transport-, Rollen- oder Applikationsebene).Da nach derzeitigem Stand davon ausgegangen wird, dass die Authentisierung und Verschlüsselungauf der Netzwerkebene nicht lückenlos ist, MUSS die Authentisierung undVerschlüsselung auf der Anwendungsebene durchgängig und lückenlos sein.Zu Autorisierung gilt weiter: Wer auf einen Datensatz zugreift, MUSS zum Zeitpunkt desZugriffs Zugriffsberechtigungen besitzen und diesen spezifischen Schlüssel in geeigneterWeise bereitgestellt bekommen.Zur Nichtabstreitbarkeit gilt weiter: Der Entstehungs- und Löschungsprozess des elektronischenAbbildes einer Einverständniserklärung MUSS unabhängig vom tatsächlichenSpeicherort lückenlos anhand revisionsfähiger Protokolle zu einer rechtsgültigen Handlungder ihr Einverständnis bekundenden Person rückführbar sein. Änderungen am elektronischenAbbild einer Einverständniserklärung MÜSSEN unabhängig vom Speicherortlückenlos anhand revisionsfähiger Protokolle zur ändernden Person rückführbar sein. Ü-ber den gesamten Lebenszyklus eines von einer Einverständniserklärung betroffenenInformationsobjektes MUSS lückenlos und revisionsfähig nachvollziehbar sein in welchemZeitraum ein Einverständnis vorgelegen hat.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 235 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

B2.1 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtA_02472STitel Beschreibung Rel. QuelleÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturSicherheitsziel_Vertraulichkeit:Personenbezogene Daten im Umfeld dermedizinischen VersorgungMÜSSEN in der Regel alsstreng vertraulich behandeltwerdenA_02473 S Sicherheitsziel_Integrität: DieIntegrität der erhobenen, verarbeiteten,transportierten undgespeicherten Daten MUSSgewährleistet seinA_02474 S Sicherheitsziel_Authentizität:Die Authentizität der im medizinischenUmfeld erhobenen,gespeicherten, verarbeitetenund transportierten DatenMUSS gewährleistet sein.Personenbezogene Daten (insbesondere Sozialdaten und medizinischeDaten) im Umfeld der medizinischen Versorgung MÜSSEN inder Regel als streng vertraulich behandelt werden. Dieser Vertraulichkeitsanspruchdes Versicherten ist in verschiedenen Gesetzenfestgelegt. Des Weiteren beinhaltet der Anspruch nach vertraulicherBehandlung von Daten den Anspruch des Versicherten, seine informationelleSelbstbestimmung wahrnehmen zu können, indem erdie Daten nur Berechtigten zugänglich macht. Eine Verletzung dieserSicherheitsanforderung kann für den Versicherten zu nicht unerheblichensozialen oder materiellen Schäden führen. AndererseitsMUSS der Versicherte darüber informiert werden, dass er diesesRecht auf informationelle Selbstbestimmung dem behandelndenLeistungserbringer und sich selbst gegenüber in vertrauenswürdigerWeise nutzen sollte, um Schadensfälle zu vermieden. Daraus ergibtsich, dass die personenbezogenen Daten bei der Übertragung undSpeicherung (mindestens einmal) verschlüsselt sein MÜSSEN. DasSchlüsselmanagement MUSS nach dem aktuellen Stand der Technikund Wissenschaft sicher seinDie Integrität der erhobenen, verarbeiteten, transportierten und gespeichertenDaten MUSS gewährleistet sein. Die Daten DÜRFENNICHT unbemerkt manipuliert werden. Ihre Korrektheit, Echtheitund Vollständigkeit ist für den Behandlungserfolg außerordentlichwichtigDie Authentizität der im medizinischen Umfeld erhobenen, gespeicherten,verarbeiteten und transportierten Daten MUSS gewährleistetsein, d. h. der Autor bzw. der Verantwortliche von patientenbezogenensowie der Auslöser eines Verarbeitungsganges MÜSSENjederzeit eindeutig feststellbar sein. Dabei ist es unerheblich, ob essich dabei um eine natürliche Person, eine Organisation oder eineAnhangB 2AnhangB 2AnhangB 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 236 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02475 S Sicherheitsziel_Authentizität_01:Authentisierungund Autorisierung aufmehreren EbenenA_02476 S Sicherheitsziel_Authentizität_02:LückenloseAuthentisierungund Verschlüsselungauf Anwendungsebene.A_02477 S Sicherheitsziel_Autorisierung:Medizinische DatenverarbeitungssystemeMÜSSEN esermöglichen, dass der Kreisder Zugriffsberechtigten aufVersichertendaten durch abgestufteNutzungsrechte exaktbestimmbar und abgrenzbarist.A_02478 S Sicherheitsziel_Autorisierung_01:Zugriffsberechtigungen.A_02479 S Sicherheitsziel_Nichtabstreitbarkeit:DieNichtabstreitbarkeit des Sendensund Empfangens vonpatientenbezogenen Informati-technische Komponente handelt. Des Weiteren MUSS die Herkunft(eine natürliche oder juristische Person) der im Rahmen der Personalisierungauf eine Karte aufgebrachten Daten aus der Sicht derpersonalisierenden Stelle eindeutig bestimmbar und prüfbar seinEs MUSS gewährleistet sein, dass eine getrennte Authentisierungund Autorisierung auf mehreren Ebenen oder Schichten stattfindet(Netzwerk-, Transport-, Rollen- oder Applikationsebene)Die Authentisierung und Verschlüsselung auf der AnwendungsebeneMUSS durchgängig und lückenlos seinMedizinische Datenverarbeitungssysteme MÜSSEN es ermöglichen,dass der Kreis der Zugriffsberechtigten auf Versichertendatendurch abgestufte Nutzungsrechte exakt bestimmbar und abgrenzbarist. Durch geeignete Verfahren ist sicherzustellen, dass einZugriff auf die Daten des Versicherten nur mit seinem Einverständniserfolgen KANN. Sollte der Versicherte nicht in der Lage sein,diese Rechte wahrnehmen zu können, so ist durch geeignete organisatorischewie auch technische Verfahren sicherzustellen, dassentsprechend den gesetzlichen Vorgaben seine medizinische Versorgungnicht beeinträchtigt wird. Die Erteilung von ZugangsberechtigungenDÜRFEN bei den medizinischen Pflichtanwendungen nichtzu Diskriminierungen auf Grund der angewandten technischen VerfahrenwerdenWer auf einen Datensatz zugreift, MUSS zum Zeitpunkt des ZugriffsZugriffsberechtigungen besitzen und diesen spezifischen Schlüsselin geeigneter Weise bereitgestellt bekommenDie Nichtabstreitbarkeit des Sendens und Empfangens von patientenbezogenenInformationen/Dokumenten MUSS gewährleistetsein. Diese Nichtabstreitbarkeit MUSS sich sowohl auf den Vorgangder Übertragung wie auch auf das Objekt der Übertragung beziehen.Die Nichtabstreitbarkeit ist eine Voraussetzung der Revisions-AnhangB 2AnhangB 2AnhangB 2AnhangB 2AnhangB 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 237 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturonen/Dokumenten MUSS gewährleistetsein.A_02480 S Sicherheitsziel_Nichtabstreitbarkeit_01:Rückführbarkeit der Einverständniserklärung.A_02481 S Sicherheitsziel_Revisionsfähigkeit:DieRevisionsfähigkeit der DatenMUSS gewährleistet sein.A_02482 S Sicherheitsziel_Verfügbarkeit:Die Verfügbarkeit der DatenMUSS gewährleistet sein.fähigkeitDer Entstehungs- und Löschungsprozess des elektronischen Abbildeseiner Einverständniserklärung MUSS unabhängig vom tatsächlichenSpeicherort lückenlos anhand revisionsfähiger Protokolle zueiner rechtsgültigen Handlung der ihr Einverständnis bekundendenPerson rückführbar sein. Änderungen am elektronischen Abbildeiner Einverständniserklärung MÜSSEN unabhängig vom Speicherortlückenlos anhand revisionsfähiger Protokolle zur änderndenPerson rückführbar sein. Über den gesamten Lebenszyklus einesvon einer Einverständniserklärung betroffenen InformationsobjektesMUSS lückenlos und revisionsfähig nachvollziehbar sein in welchemZeitraum ein Einverständnis vorgelegen hat.Die Revisionsfähigkeit der erhobenen, gespeicherten, übermitteltenoder verarbeiteten Daten MUSS gewährleistet sein, damit die Verarbeitungsprozesselückenlos nachvollzogen werden können. Fürden Arzt bzw. das Krankenhaus besteht nach der Berufsordnungdie Pflicht zur Dokumentation der Behandlung. Diagnosen und TherapienMÜSSEN zwecks Ausschluss von Haftungen lückenlosnachvollziehbar seinDie Verfügbarkeit aller erfassten, übermittelten und gespeichertenDaten MUSS gewährleistet sein. Das bedeutet, dass die Daten einesVersicherten immer zeitnah zur Verfügung stehen MÜSSEN,um ordnungsgemäß be- und verarbeitet werden zu könnenAnhangB 2AnhangB 2AnhangB 2B3 - Fachliche SicherheitsanforderungenIn diesem Abschnitt werden die Sicherheitsanforderungen an die fachlichen Anwendungen nach § 219a SGB V beschrieben. Dabei werdenzuerst übergreifende Anforderungen, die für alle verbindlich sind und anschließend spezielle Anforderungen aufgeführt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 238 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB3.1 - Anwendungsübergreifende AnforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_02483 AS-AI-10160 SA_02484 AS-AI-10190A_02485A_02486A_02487A_02488A_02489Sec_Anwendungsübergreifend_01: SignaturprüfungS Sec_Anwendungsübergreifend_02: Sicherstellen, dass der BrokerService gegenüber denFachdiensten die einzige vertrauenswürdigeDatenquelle fürAufrufe ist.S Sec_Anwendungsübergreifend_03: Authentizität und Integritätaller relevanten medizinischen/technischenDaten.S Sec_Anwendungsübergreifend_04:Authentizität des VersichertenS Sec_Anwendungsübergreifend_05: Authentizität von LeistungserbringernS Sec_Anwendungsübergreifend_06: Vertrauliche Kommunikationzwischen Leistungserbringer zuden Kostenträgern sowie zuallen relevanten DiensteS Sec_Anwendungsübergreifend_07: Autorisierung und AuthentifizierungDie Fachdienste MÜSSEN vor der Ausführung der gewünschtenOperationen alle Signaturen prüfen, um so Manipulationen an denOperationen zu erkennen.Es MUSS sichergestellt sein, dass der Broker Service gegenüberden Fachdiensten die einzige vertrauenswürdige Datenquelle fürAufrufe ist.Die Authentizität und Integrität aller relevanten medizinischen/technischenDaten MUSS sichergestellt sein.Es MUSS die Authentizität des Versicherten (repräsentiert durch dieeGK) sichergestellt sein.Es MUSS die Authentizität von Leistungserbringern (repräsentiertdurch den HBA) sichergestellt sein.Die vertrauliche Kommunikation zwischen Leistungserbringer zuden Kostenträgern sowie zu allen relevanten Diensten MUSS gewährleistetsein (Einsatz von kryptographischen Verfahren, welchedem aktuellen Stand der Wissenschaft und Technik entsprechen).Für einen Zugriff auf medizinische Daten MUSS zuvor eine erfolgreicheAutorisierung und Authentifizierung stattfinden.Anhang B3.1Anhang B3.1Anhang B3.1Anhang B3.1Anhang B3.1Anhang B3.1Anhang B3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 239 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02490A_02491A_02492A_02493A_02494S Sec_Anwendungsübergreifend_08: Vergabe von Zugriffsberechtigungendurch den Versicherten.S Sec_Anwendungsübergreifend_09: Lesezugriff auf Daten nurunter Mitwirkung des Versicherten.S Sec_Anwendungsübergreifend_10: DatensparsamkeitS Sec_Anwendungsübergreifend_11: Verschlüsselung online gespeicherterDaten.S Sec_Anwendungsübergreifend_12: Umschlüsselung.Der Versicherte MUSS für einzelne oder mehrere Leistungserbringeroder Organisationen Zugriffsberechtigungen in einfacher Weiseunter Verwendung seiner eGK erzeugen, löschen oder verändernbzw. in seiner Anwesenheit Informationen bereitstellen können.Online (in einem Fachdienst) und offline (auf einer eGK) gespeicherteDaten MÜSSEN so gesichert werden, dass nur zum Zugriff berechtigtePersonen sie unter Mitwirkung des Versicherten im Klartextlesen können.Zusätzlich SOLLEN im Zuge des allgemeinen Grundsatzes der Datensparsamkeitalle gespeicherten Daten so abgelegt werden, dassaus dem Datenspeicher heraus keine Zuordnung zu einer Personmöglich ist, auch nicht für administratives Personal.Online gespeicherte medizinische Daten MÜSSEN verschlüsseltwerden. Die Vertraulichkeit der gespeicherten medizinischen DatenMUSS sichergestellt sein. Der Versicherte MUSS selbst bestimmenkönnen, wer außer ihm selbst die in der TI gespeicherten medizinischenDaten entschlüsseln und damit lesen darf.Eine planmäßige (beim Austausch von Chipkarten) oder außerplanmäßige(beim Verlust von Chipkarten) Umschlüsselung für eineneue eGK durch einen vertrauenswürdigen Service MUSS möglichsein, um auf die Daten auch nach dem Verlust der Karte und desSchlüssels wieder zugreifen zu können.Anhang B3.1Anhang B3.1Anhang B3.1Anhang B3.1Anhang B3.1B3.2 - Versichertenstammdaten (VSD)Afo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02495 S Sec_Versichertenstammdaten_01: Anonymisierung desLeistungserbringerbezuges.Der Leistungserbringerbezug MUSS bei der Verbindung zum Kostenträgeranonymisiert werden. Eine Profilbildung durch den KostenträgerDARF NICHT möglich sein. Es DARF NICHT möglichsein, den Leistungserbringer auf Grund der VSD-Anfrage zu identi-AnhangB 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 240 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturfizieren.A_02496 S Sec_Versichertenstammdaten_02: Vertraulichkeit personenbezogenerDaten besondererArtA_02497 S Sec_Versichertenstammdaten_03: eder Zugriff auf die geschütztenVSD MUSS protokolliertwerdenA_02498 S Sec_Versichertenstammdaten_04: Berechtigung der zugreifendenInstitution beim Zugriffauf VSD.A_02499 S Sec_Versichertenstammdaten_05: Der Schutz der VSD vorManipulation.A_02500 S Sec_Versichertenstammdaten_06: Schreibrecht nur für Kostenträger.A_02501 S Sec_Versichertenstammdaten_07: Information des Versichertenund des Leistungserbringers.A_02502 S Sec_Versichertenstammdaten_08: Nachvollziehbarkeit derAktualisierung.Es MUSS die Sicherstellung der Vertraulichkeit personenbezogenerDaten besonderer Art (DMP-Kennzeichen (§ 291 Abs. 2 Nr. 7SGB V), Kennzeichen für besonderen Personengruppen (§ 291Abs. 2 Nr. 7 SGB V), Angaben zum Zuzahlungsstatus (§ 291 Abs.2 Nr. 8 SGB V)) garantiert sein.Jeder Zugriff auf die geschützten VSD MUSS protokolliert werden.Es MUSS protokolliert werden, wer wann auf was zugreift (sieheAbschnitt über Protokollierungskonzept). D. h. insbesondere, dassauch der Zugriff des Versicherten protokolliert werden MUSS.Beim Zugriff auf die geschützten VSD MUSS die Berechtigung derzugreifenden Institution gegenüber der eGK nachgewiesen werden.Der Schutz der VSD vor Manipulation MUSS sichergestellt sein.Es MUSS gewährleistet sein, dass nur der Kostenträger Schreibrechtauf die VSD der eGK besitzt.Es MUSS sichergestellt sein, dass der Versicherte und der Leistungserbringerüber die Aktualisierung informiert werden.Der Kostenträger MUSS nachvollziehen können, ob die Aktualisierungder VSD auf der eGK erfolgreich verlaufen ist.AnhangB 3.2AnhangB 3.2AnhangB 3.2AnhangB 3.2AnhangB 3.2AnhangB 3.2AnhangB 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 241 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB3.3 - Verordnungsdaten (VOD)Afo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02503 S Sec_Verordnungsdaten_01:Verhinderung von Profilbildung.A_02504 S Sec_Verordnungsdaten_02:Entschlüsseln von Daten einerVerordnung nur unter Mitwirkungder eGK des VersichertenA_02505 S Sec_Verordnungsdaten_03:Signatur der Verordnungen.A_02506 S Sec_Verordnungsdaten_04:Sichere SignaturanwendungskomponenteA_02507 S Sec_Verordnungsdaten_05:Manipulationssicheres Verodnungsdatum.A_02508 S Sec_Verordnungsdaten_06:Signaturprüfung vor Dispensierung.A_02509 S Sec_Verordnungsdaten_07:Dispensierte eVerordnungenMÜSSEN vom Apotheker signiertwerdenA_02510 S Sec_Verordnungsdaten_08:Protokollierung der Zugriffeauf eVerordnungen.Die Profilbildung von Leistungserbringern MUSS beim Verordnungsdatendienst(VODD) verhindert werden.Es MUSS sichergestellt sein, dass ein Entschlüsseln von Dateneiner Verordnung nur unter Mitwirkung der eGK des Versicherten(bzw. einer sicheren Ersatzlösung auf Auftrag des Versicherten)möglich ist.Alle Verordnungen MÜSSEN im Rahmen der geltenden Rechtslagerechtsgültig von der verordnenden Stelle mit einer qualifiziertenSignatur digital signiert werden, bevor diese in die Telematikinfrastrukturaufgenommen werden.Für die Signierung der Informationen der eVerordnung MUSS einesichere Signaturanwendungskomponente verwendet werden.Es MUSS ein manipulationssicheres Datum (Tagesdatum) zumZeitpunkt der Signierung als "Verordnungsdatum" generiert werden.Die Signatur des Arztes MUSS beim Einlösen einer eVerordnungvor der Dispensierung geprüft werden.Dispensierte eVerordnungen MÜSSEN vom Apotheker signiertwerden.[ Apotheker steht hier und im weiteren Dokument stellvertretendfür alle Berechtigten gemäß ApBetrO, die Arzneimittel ausgebendürfen. ]Es MUSS sichergestellt werden, dass die Zugriffe auf die eVerordnungenprotokolliert werden.AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 242 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02511 S Sec_Verordnungsdaten_09:Verhinder von Mehrfacheinlösungen.A_02512 S Sec_Verordnungsdaten_10:Zuordnung zum Versicherten.A_02513 S Sec_Verordnungsdaten_11:Verschlüsselte Speicherung.A_02514 S Sec_Verordnungsdaten_12:Datenintegridät beim Signieren.A_02515 S Sec_Verordnungsdaten_13:Nichtabstreitbarkeit einer eVerordnung.A_02516 S Sec_Verordnungsdaten_14:Profilbildung muß verhindertwerden.Es MUSS verhindert werden, dass eVerordnungen mehrfach eingelöstwerden können.Vor der Speicherung einer eVerordnung MUSS sichergestellt werden,dass die Zuordnung zum Versicherten korrekt ist.Eine eVerordnung MUSS in verschlüsselter Form auf den VODDgespeichert sein.Bei der Anzeige und dem Signieren einer eVerordnung MUSS dieIntegrität der Informationen sichergestellt werden.Es DARF NICHT möglich sein, die Ausstellung einer eVerordnungabzustreiten.Die Profilbildung von Leistungserbringern MUSS beim Verordnungsdatendienst(VODD) verhindert werden.AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3AnhangB 3.3B3.4 - Freiwillige AnwendungenIn den folgenden Unterabschnitten werden die Anforderungen an die freiwilligen Anwendungen nach §291a SGB V benannt, obwohl z. Z.noch nicht alle konzeptionell beschrieben oder spezifiziert sind. Daher ist es möglich, dass die Anforderungen sich nach Erstellung der Fachkonzepteändern.B3.4.1 - Anwendung des Versicherten (AdV)Afo-ID Anfo Art Titel Beschreibung Rel. Quellegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 243 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02517 S Sec_Freiwillige_AW_AdV_01:Änderung der Transport-PIN.A_40294A_40294SSec_Freiwillige_AW_AdV_14:Nicht lesbare PIN/PUK EingabeWird auf einer eGK zum ersten Mal eine PIN-geschützte Anwendungverwendet, MUSS der Versicherte aufgefordert werden einevon ihm gewählte PIN einzugeben, wenn das Transport-PIN Verfahreneingesetzt wird und die PIN vorher noch nicht geändert wurde.Ein Sicherheitscode der eGK, wie PIN (Personal Identification Number)und PUK (Personal Unblocking Key), DARF NICHT lesbar angezeigtwerden (Anwendungen des Versicherten)Anhang B3.4.1A_02518 S Sec_Freiwillige_AW_AdV_02:PIN/PUK-Anzeige.A_40442 A_40442A_40283 A_40283SSSec_Freiwillige_AW_AdV_15:Interpretation PIN/PUK Eingabe.Sec_Freiwillige_AW_AdV_16:Authentisierung bei Zugriff aufAdVA_02519 S Sec_Freiwillige_AW_AdV_03:Authentisierung des Versichertendurch PIN.A_02520 S Sec_Freiwillige_AW_AdV_04:Sicherheitsabfrage.Die Eingabe von Sicherheitscodes (z. B. PIN, Transport-PIN, PUK)MUSS durch einheitliche Zeichen angezeigt werden.Die Eingabe sowohl der PIN als auch der PUK (eGK) DARF NICHTbei den Anwendungen des Versicherten interpretiert werden können.(Zeichenart (num/alpha/Sonderzeichen), Dopplung etc.)Der Versicherte MUSS für jeden Zugriff auf die Fachanwendungen(AdV) des Versicherten als Authentisierung die PIN eingeben.Für alle Zugriffe auf die eVerordnung, die Zugriffscodes, dieZugriffsprotokolle und die Verwaltung freiwilliger AnwendungenMUSS der Versicherte als Authentisierung die PIN eingeben.Die Gefahr des unbeabsichtigten Löschens SOLL durch eine Sicherheitsabfragereduziert werden.Anhang B3.4.1Anhang B3.4.1Anhang B3.4.1Anhang B3.4.1Anhang B3.4.1A_02521 S Sec_Freiwillige_AW_AdV_05:Umgebungsstatus.A_02522 S Sec_Freiwillige_AW_AdV_06:Nicht einsehbare Dateneingabe.Die Umgebung zur Wahrung der Rechte der Versicherten MUSSden Status einer berechtigten Institution haben. Der Nachweis einerberechtigten Institution MUSS der eGK gegenüber ausgewiesenwerden können. (Anmerkung: Aktuell wurde Versicherter@Homenicht berücksichtigt.)Wenn Anwendungsfälle des Versicherten in der Umgebung desLeistungserbringers ablaufen, MUSS gewährleistet sein, dass derVersicherte dazu erforderliche Eingaben aktiv und für Dritte nichteinsehbar vornehmen kann.Anhang B3.4.1Anhang B3.4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 244 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02523 S Sec_Freiwillige_AW_AdV_07:Protokollierung aller Zugriffe.Jeder Zugriff (eGK, Zugriffsprotokolle, Liste der freiwilligen Anwendungen,Zugriffsberechtigungen) MUSS protokolliert werden.Anhang B3.4.1A_02524 S Sec_Freiwillige_AW_AdV_08:Schutz des Zugriffsprotokollsvor Manipulation.A_02525 S Sec_Freiwillige_AW_AdV_09:Schutz des Zugriffsprotokollsvor Mißbrauch.A_02526 S Sec_Freiwillige_AW_AdV_10:Schutz des Zugriffsprotokollsdurch Benutzerauthentisierung.A_40317 A_40317SSec_Freiwillige_AW_AdV_17:Protokollierung aller Zugriffe aufdie eGKDas Zugriffsprotokoll MUSS gegen Manipulation geschützt sein.Das Zugriffsprotokoll MUSS gegen zweckfremde Verwendung undsonstigen Missbrauch geschützt sein.Das Zugriffsprotokoll MUSS so geschützt werden, dass nur berechtigteBenutzer (nach entsprechender Authentifizierung) daraufzugreifen können.Ein Zugriff auf Daten auf der eGK MUSS auf der eGK protokolliertwerden.Anhang B3.4.1Anhang B3.4.1Anhang B3.4.1Anhang B3.4.1A_02527 S Sec_Freiwillige_AW_AdV_11:Protokollierung aller Zugriffe inder TI.A_02528 S Sec_Freiwillige_AW_AdV_12:Protokollierung nur zur Unterstützungdes Datenschutzes.A_02529 S Sec_Freiwillige_AW_AdV_13:Verbot der Erstellung von Bewegungsprofilen.Ein Zugriff auf Daten in der Telematikinfrastruktur MUSS in der Telematikinfrastrukturprotokolliert werden.Die Protokollierung MUSS ausschließlich für Datenschutzzweckeverwendet werden können.Eine Protokollierung DARF NICHT Grundlage für Bewegungsprofilesein.Anhang B3.4.1Anhang B3.4.1Anhang B3.4.1B3.4.2 - Verwaltung freiwilliger Anwendungen (VfA)Afo-ID Anfo Art Titel Beschreibung Rel. Quellegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 245 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02530A_02531A_40340 A_40340A_40495 A_40495SSSSSec_Freiwillige_AW_Verwaltung_01: Authentisierung durchPIN.Sec_Freiwillige_AW_Verwaltung_02: Autorisierung des HBA-Inhabers durch des Versicherten.Sec_Freiwillige_AW_Verwaltung_03: Geschützte UmgebungSec_Freiwillige_AW_Verwaltung_04: Geschützte Umgebung/Umgebung des Arztes.Vor jeder Nutzung der Verwaltung freiwilliger Anwendungen MUSSder Versicherte als Authentisierung die PIN eingeben.Der Versicherte MUSS den HBA-Inhaber zur Einrichtung einer freiwilligenAnwendung autorisieren.Sämtliche Funktionalitäten der Verwaltung freiwilliger AnwendungenMÜSSEN in einer geschützten Umgebung zur Verfügung gestelltwerden.Wenn Anwendungsfälle des Versicherten in der Umgebung desArztes ablaufen, MUSS gewährleistet sein, dass der Versichertedazu erforderliche Eingaben aktiv und für Dritte nicht einsehbar vornehmenkann.Anhang B3.4.2Anhang B3.4.2Anhang B3.4.2Anhang B3.4.2B3.4.3 – NotfalldatenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02532 S Sec_Freiwillige_AW_Notfalldaten_01: Einwilligung des Versicherten.A_02533 S Sec_Freiwillige_AW_Notfalldaten_02: Notfalldaten müssensigniert abgelegt werden.A_02534 S Sec_Freiwillige_AW_Notfalldaten_03: Zeitstempel der Notfalldaten-Signatur.A_02535 S Sec_Freiwillige_AW_Notfalldaten_04: Keine PIN-Eingabe beiSicherungskopie.Die Einwilligung, dass Notfalldaten auf der eGK gespeichert werden,MUSS der Versicherte dafür vorher gegeben haben.In der Telematikinfrastruktur (z. B. eGK) gespeicherte NotfalldatenMÜSSEN vom Arzt in ihrer Gesamtheit qualifiziert signiert werden.Die Signatur der Notfalldaten MUSS das Datum und Uhrzeit (Systemzeitkommt vom Konnektor, der sich regelmäßig mit einem vertrauenswürdigenZeitserver in der Telematikinfrastruktur synchronisiert)enthalten.Es DARF NICHT erforderlich sein, dass der Versicherte (nach vorangegangenerAutorisierung des schreibenden Zugriffs auf dieeGK) für die Speicherung der Sicherungskopie erneut seine PINeingeben muss.AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 246 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02536 S Sec_Freiwillige_AW_Notfalldaten_05: Protokollierung desZugriffs.A_02537 S Sec_Freiwillige_AW_Notfalldaten_06: Entschlüsselung nurunter Mitwirkung des Versicherten.A_02538 S Sec_Freiwillige_AW_Notfalldaten_07: Korrekte Zuordnungder Notfalldaten.A_02539 S Sec_Freiwillige_AW_Notfalldaten_08: Löschung nur durchautorisierte Personen.A_02540 S Sec_Freiwillige_AW_Notfalldaten_09: Änderung nur durchautorisierte Ärzte.A_02541 S Sec_Freiwillige_AW_Notfalldaten_10: Integritätsprüfung vorEinlesen bzw. Wiederherstellung.A_02542 S Sec_Freiwillige_AW_Notfalldaten_11: Authentisierung/Autorisierungvor Lesezugrifferforderlich.A_02543 S Sec_Freiwillige_AW_Notfalldaten_12: Schreibender Zugriffnur nach Authentisierung mittelsHBA/SMC und eGK.A_02544 S Sec_Freiwillige_AW_Notfalldaten_13: Vermeidung von Pro-Jeder Zugriff auf die Notfalldaten MUSS auf der eGK protokolliertwerden.Es MUSS sichergestellt werden, dass die in der Telematikinfrastrukturgespeicherte Sicherungskopie der Notfalldaten nurunter Mitwirkung des Versicherten bzw. seiner eGK entschlüsseltwerden kann.Vor dem Schreiben der Notfalldaten (auf der eGK und beim Speicherneiner Sicherungskopie in der Telematikinfrastruktur) MUSSgeprüft werden, ob die Zuordnung der Notfalldaten zum Versichertenbzw. der eGK korrekt ist.Es MUSS sichergestellt sein, dass das Löschen signierter Notfalldatenvon einer eGK nur von autorisierten Personen ausgeführtwerden kann.Es MUSS sichergestellt sein, dass die Notfalldaten nur von autorisiertenÄrzten verändert/erstellt werden können. Sie MÜSSENnach einer Änderung/Erstellung erneut signiert werden (z. B. dürfendie Notfalldaten im Rahmen der Wahrnehmung der Versichertenrechtenicht durch den Versicherten geändert werden).Beim Einlesen bzw. Wiederherstellen MUSS eine Überprüfung derEchtheit und Integrität der auf der eGK bzw. in der Telematikinfrastrukturals Sicherungskopie gespeicherten Notfalldaten erfolgen.Der Arzt MUSS sich für den lesenden Zugriff auf die Notfalldatenautorisieren.Für den schreibenden Zugriff auf die Notfalldaten MUSS sich derArzt autorisieren (mit HBA/SMC gegenüber eGK) und der Versicherteautorisiert den Zugriff mit seiner PIN. Das gilt sowohl für dieNotfalldaten auf der eGK als auch für die Sicherungskopie in derTelematikinfrastruktur.Beim Speichern einer Sicherungskopie MUSS die Verschlüsselungso erfolgen, dass weder beim Speichervorgang noch am Speiche-AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3AnhangB 3.4.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 247 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02545Sfilbildung.Sec_Freiwillige_AW_Notfalldaten_14: Neusignatur bei Wiederherstellungnicht erforderlich.rort in der Telematikinfrastruktur Rückschlüsse auf den Arzt möglichsind.Es MUSS gewährleistet sein, dass die Notfalldaten bei der Wiederherstellungaus der Telematikinfrastruktur nicht neu signiertwerden müssen.AnhangB 3.4.3B3.4.4 - Weitere freiwillige AnwendungenFür weitere, noch nicht beschriebene bzw. spezifizierte freiwillige Anwendungen gelten mindestens die anwendungsübergreifenden Sicherheitsanforderungen.Spezifische Anforderungen werden bei Bedarf ergänzt.B4 - Sicherheitsanforderungen an Komponenten/Dienste/NetzeIn dem folgenden Abschnitt werden die Sicherheitsanforderungen an die Komponenten, Dienste und Netze der Telematikinfrastruktur beschrieben.B4.1 - Übergreifende AnforderungenDie nachfolgend aufgelisteten Anforderungen sind für alle Komponenten, Dienste und/oder Netze bindend und MÜSSEN daher berücksichtigtwerden.Afo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02546 S Sec_Übergreifend_Netz_Komponenten_Dienste_01: Akkreditierungdurch gematik erforderlich.A_02547 S Sec_Übergreifend_Netz_Komponenten_Dienste_02: Zulassungdurch gematik erforderlich.Fachdienste bzw. Infrastrukturdienste MÜSSEN von der gematikakkreditiert werden.Komponenten in der Telematikinfrastruktur im Verantwortungsbereichder gematik MÜSSEN von der gematik zugelassen sein.AnhangB 4.1AnhangB 4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 248 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02548 AS-AI-7100SSec_Übergreifend_Netz_Komponenten_Dienste_03: Zulassungdes Dienstanbietersdurch gematik erforderlich.A_02549 S Sec_Übergreifend_Netz_Komponenten_Dienste_04: Berücksichtigungder ProtectionProfiles.A_02550 S Sec_Übergreifend_Netz_Komponen-ten_Dienste_05:Zugangs-/ZugriffskontrolleA_02551 S Sec_Übergreifend_Netz_Komponenten_Dienste_06: Schutzvon Vertraulichkeit, Authentizitätund Integrität der übertragenenDaten.A_02552 S Sec_Übergreifend_Netz_Komponenten_Dienste_07: Zeitsynchronisationin der TI.A_02553 S Sec_Übergreifend_Netz_Komponenten_Dienste_08: Schutzder Systemuhr vor Manipulationen.A_02554 AS-AI-5100SSec_Übergreifend_Netz_Komponenten_Dienste_09: Organisatorischeund technischeTrennung des Betriebs mehrererDienste.Der Dienstanbieter MUSS eine Zulassung bei der gematik erwerben.Für einige Komponenten (z. B. eGK, Konnektor, eHealth-Kartenterminal…) gibt es ein Protection Profile bzw. es wird eineserstellt. Die Anforderungen, die sich aus diesen Protection Profilesergeben, MÜSSEN berücksichtigt werden.Eine Zugangs-/Zugriffskontrolle MUSS für Komponenten der Telematikinfrastrukturimplementiert sein.Der Schutz der Vertraulichkeit, Authentizität und Integrität der übertragenenDaten MUSS sichergestellt sein. Dabei MUSS derSchutzbedarf der einzelnen Informationsobjekte entsprechend berücksichtigtwerden.Komponenten mit einer eigenen Systemuhr, bei denen eine richtigeSystemzeit sicherheitsrelevant ist (z. B. Konnektor), SOLLENsich in regelmäßigen Abständen sicher mit einem Zeitserver derTelematikinfrastruktur synchronisieren.Die Systemzeit von Komponenten mit einer eigenen Systemuhr,bei denen eine richtige Systemzeit sicherheitsrelevant ist (z. B.Konnektor), SOLL vor Manipulationen geschützt sein.Betreibt ein Dienstanbieter gleichzeitig mehrere Dienste (Fachdienste,Infrastrukturdienste oder Netze), so MUSS der Betriebvollständig organisatorisch, technisch und räumlich getrennt erfolgen:o Organisatorisch getrennt bedeutet, dass eine Person nicht inmehreren Diensten/Netzen Rollen einnehmen kann. Es bedeutetnicht, dass die Dienste/Netze von unterschiedlichen Legal Entitiesbetrieben werden müssen.o Technische Trennung fordert unterschiedliche und logisch ge-AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 249 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02555 AS-AI-10110A_02556 AS-AI-10120A_02558 AS-AI-11110A_02559 AS-AI-11120A_02560 AS-AI-11130SSSSSSec_Übergreifend_Netz_Komponenten_Dienste_10: VerschlüsselteÜbertragung zumFachdienst.Sec_Übergreifend_Netz_Komponenten_Dienste_11: Datenzugriffnur üner explizite Berechtigungen.Sec_Übergreifend_Netz_Komponenten_Dienste_13: Integritätder Infrastrukturdienste .Sec_Übergreifend_Netz_Komponenten_Dienste_14: Loggingvon Fehlern.Sec_Übergreifend_Netz_Komponenten_Dienste_15: EinheitlichesFramework für Loggingund Tracing.trennte Komponenten.o Räumliche Trennung fordert unterschiedliche Orte, also einenseparaten Zutrittsschutz zu den Komponenten.Bei den Netzwerkkomponenten KANN eine lediglich logischeTrennung erfolgen, wenn damit die vollständige Trennung der Netzein einer Qualität erreicht wird, die einer physischen Trennungnahe kommt: Insbesondere MUSS sichergestellt sein, dass auchdann, wenn einfache Fehler in der Konfiguration der Systeme gemachtwerden, weder Daten die Systemgrenzen überschreiten,noch eine gegenseitige Beeinträchtigung der Verfügbarkeit undPerformance möglich ist.Im Sicherheitskonzept des Dienstbetreibers MUSS dokumentiertwerden, welche Maßnahmen umgesetzt werden, um diesen Anforderungengerecht zu werden.Es MUSS sichergestellt sein, dass medizinische Daten in Telematiknachrichtenzwischen dem Primärsystem bzw. dem Konnektorund dem Fachdienst immer nur in verschlüsselter Form übertragenwerden.Ein Zugriff auf medizinische Daten ist nur über explizite Berechtigungen(u.a. ObjektTickets, ServiceTickets) möglich.Objekt- und ServiceTickets DÜRFEN für die InfrastrukturdiensteNICHT ausgestellt werden.Die Integrität der Infrastrukturdienste sowie der sicherheitsrelevantentechnischen Komponenten MUSS gewährleistet werden.Fehler MÜSSEN grundsätzlich geloggt werden.Das Logging und Tracing MUSS über ein einheitliches Frameworknach normativen Regeln erfolgen.Insbesondere MUSS geregeltwerden, wie lange Logs aufzubewahren sind.AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 250 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02561 AS-AI-11140A_02562 AS-AI-9100A_02563 AS-AI-12180A_02564 AS-ZuN-8100A_02565 AS-AI-10170SSSSSSec_Übergreifend_Netz_Komponenten_Dienste_16: Fehlermeldungan aufrufendenProzess.Sec_Übergreifend_Netz_Komponenten_Dienste_17: Betriebder Infrastrukturdienste gemäßdem Abschnitt SicherheitsanforderungenBetrieb.Sec_Übergreifend_Netz_Komponenten_Dienste_18: Einsatzevaluierter und zertifizierterKomponenten.Sec_Übergreifend_Netz_Komponenten_Dienste_19: Einsatzredundanter Systeme.Sec_Übergreifend_Netz_Komponenten_Dienste_20: EindeutigeNachrichtenidentitätund Zeitstempel.A_02566 S Sec_Übergreifend_Netz_Komponenten_Dienste_21: Berücksichtigungdes Sicherheitsprofilsfür InfrastrukturdiensteFehler oder Abbrüche MÜSSEN grundsätzlich den aufrufendenProzessen gemeldet werden.Der Betrieb der Infrastrukturdienste und –netze MUSS als Mindestanforderunggemäß dem Abschnitt SicherheitsanforderungenBetrieb erfolgen.Der Dienstanbieter MUSS, falls in den Sicherheitsanforderungenan den Infrastrukturdienst bzw. das Netz gefordert, technischeKomponenten einsetzen, die über die entsprechende Evaluierungund Zertifizierung gemäß den Anforderungen der gematik verfügen.Falls redundante Systeme gefordert sind, MUSS die erforderlicheRedundanz auch in lokalen Katastrophenfällen (z.B. Brand) gewährleistetwerden (z.B. dadurch, dass die Systeme innerhalb derRechenzentren in verschiedenen Brandabschnitten stehen).Telematiknachrichten MÜSSEN eine „weitgehend“ eindeutigeNachrichtenidentität (Message-ID) und einen Versand-Zeitstempelbesitzen.Die Message-ID MUSS auf Basis von Zufallszahlen bzw. Pseudozufallszahlenerzeugt werden. In seltenen Fällen KÖNNEN daherdoppelte Message-IDs vorkommen.Aus der Kenntnis einer Zufallszahlenteilfolge DARF es dem AngreiferNICHT möglich sein Vorgänger oder Nachfolger zu erhalten.MAC-Adressen DÜRFEN zur Generierung der Message-ID NICHTverwendet werden, um auf dieser Ebene eine Profilbildung auszuschließen.Die Anforderungen aus dem Sicherheitsprofil für Infrastrukturdiensteder Telematikinfrastruktur [gemSProf_ID] MÜSSEN berücksichtigtwerden. Das bedeutet insbesondere, dass der Dienstanbieterein Sicherheitskonzept gemäß den Vorgaben des Sicherheitsprofilsfür Infrastrukturdienste der Telematikinfrastruktur [gemSProf_ID]AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 251 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02567 S Sec_Übergreifend_Netz_Komponenten_Dienste_22:DokumentaionKey Management.A_02570 AS-AI-6100A_02571 AS-AI-6120SSA_02568 S Sec_Übergreifend_Netz_Komponenten_Dienste_23: Schutzder Konfiguration vor unautorisiertenÄnderungen.A_02569 S Sec_Übergreifend_Netz_Komponenten_Dienste_24: Erkennungvon unautorisierten Änderungenan der Konfiguration.Sec_Übergreifend_Netz_Komponenten_Dienste_25: Informationssicherheitssystemnach ISO 27001.Sec_Übergreifend_Netz_Komponenten_Dienste_26: RestrisikoabschätzungdurchDienstanbieter erforderlich.erstellen MUSS.Werden in der Kompontente/im Netz/im Dienst Schlüssel bzw. Zertifikateverwendet, MÜSSEN diese im Spezifischen Sicherheitskonzeptdes Dienstanbieters (Key Management) besonders beachtetund die Umsetzung des jeweiligen Schutzbedarfs dargelegtwerden. Dies gilt auch für Testschlüssel und Testzertifikate.Es MUSS ein Schutz vor unautorisierten Änderungen von Konfigurationsdateiengegeben seinEs MUSS verhindert werden, dass Konfigurationsdateien vonKomponenten und Systemen der Telematikinfrastruktur unautorisiertverändert werden, ohne dass es bemerkt wird.Der Betreiber von Infrastrukturdiensten und -netzen MUSS ein Informationssicherheitssystemmind. nach ISO 27001 implementieren.Anmerkung: Dies bedeutet, dass der Betreiber nach ISO/IEC27001 arbeiten MUSS. Es bedeutet nicht, dass der Betreiber eineZertifizierung nach ISO/IEC 27001 besitzen MUSS.Der Dienstanbieter MUSS eine Restrisikoabschätzung gemäß denVorgaben des Sicherheitsprofils für Infrastrukturdienste der Telematikinfrastruktur[gemSProf_ID] erstellen.AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1AnhangB 4.1B4.1.1 - Technische ProtokollierungAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02572 S Sec_Übergreifend_Protokollierung_01: Nutzung granularerlog-level.Findet eine technische Protokollierung statt, so SOLL es verschiedeneLog-Level für die technische Protokollierung geben. Mindestensin einem Log-Level MÜSSEN die Log-Daten frei von personenbezogenenDaten sein.AnhangB 4.1.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 252 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02573 S Sec_Übergreifend_Protokollierung_02: Separate log-level fürpersonenbezogene Daten.A_02574 S Sec_Übergreifend_Protokollierung_03:Im Normalbetrieb keineNutzung der log-level fürpersonenbezogene Daten.A_02575 S Sec_Übergreifend_Protokollierung_04:Sonderregelung fürLogging personenbezogenerDaten.A_02576 S Sec_Übergreifend_Protokollierung_05: Löschung personenbezogenerLog-Daten.Log-Level, bei denen die Log-Daten auch personenbezogene Datenenthalten, MÜSSEN als personenbezogene Log-Level gekennzeichnetsein.Im Normal-Betrieb MUSS sichergestellt sein, dass nicht personenbezogeneLog-Level genutzt werden.Bei einem vom Normal-Betrieb abweichenden Betrieb KANN einpersonenbezogenens Log-Level genutzt werden. Diese NutzungMUSS dann zeitlich begrenzt sein und der Betreiber MUSS einenProzess für den Umgang mit den Log-Daten definieren, umsetzenund kontrollieren, so dass ein Missbrauch der personenbezogenenDaten ausgeschlossen wird. Der Datenschutzbeauftragte desBetreibers MUSS über die personenbezogene Protokollierung informiertund bei der Verarbeitung der Log-Daten beteiligt werden.Der Betreiber MUSS sicherstellen, dass die personenbezogenenLog-Daten sicher gelöscht werden, sobald sie nicht mehr erforderlichsind. Der Datenschutzbeauftragte des Betreibers MUSS überdas Löschkonzept informiert werden.AnhangB 4.1.1AnhangB 4.1.1AnhangB 4.1.1AnhangB 4.1.1B4.2 - eHealth-KartenterminalB4.2.1 – AllgemeinAfo-ID Anfo ArtA_02577STitel Beschreibung Rel. QuelleSec_eHealth_Kartenterminal_Allg_01: Validierung des e-Health-Kartenterminal.A_02578 S Sec_eHealth_Kartenterminal_Allg_02: Basissicherheitsanforderungengem. SICCT-Das eHealth-Kartenterminal MUSS hinsichtlich der genannten Anforderungenund entsprechend dem Einsatzumfeld und derEinsatzumgebung durch akkreditierte Prüf- oder Zulassungsstellenvalidiert werden.Basissicherheitsanforderungen sind im Kapitel 8 der SICCT-Spezifikation [SICCT] beschrieben. Weitere Sicherheitsanforderungenergeben sich aus den Anforderungen des § 15 ff. der Sig-AnhangB 4.2.1AnhangB 4.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 253 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturSpezifikation.A_02579 S Sec_eHealth_Kartenterminal_Allg_03: Evaluierung gem.SigV durch Bundesnetzagentur.A_02580 S Sec_eHealth_Kartenterminal_Allg_04: Erweiterte Evaluierung.A_02581 S Sec_eHealth_Kartenterminal_Allg_05: Erstellung qualifizierterSignaturen.A_02582 S Sec_eHealth_Kartenterminal_Allg_06: Eignung zur Erstellungqualifizierter Signaturen.A_02583 S Sec_eHealth_Kartenterminal_Allg_07: Erkennung von Manipulationsversuchen.A_02584 S Sec_eHealth_Kartenterminal_Allg_08: Erkennung von Manipulationsversuchenan derHardware.A_02585 S Sec_eHealth_Kartenterminal_Allg_09: Sicherheits in derÜbergangsphase von KVK aufeGK.naturverordnung [SigV01] in Relation zum § 17 Signaturgesetzes[SigG01] an Signaturanwendungskomponenten. Diese AnforderungenMÜSSEN berücksichtigt werden.Werden qualifizierte Signaturen durchgeführt, MÜSSEN die e-Health-Kartenterminals zur Verwendung gemäß den konkretisiertenAnforderungen der Signaturverordnung [SigV01] evaluiert undvon der Bundesnetzagentur für Elektrizität, Gas, Telekommunikation,Post und Eisenbahnen [BNetzA] oder einer akkreditierten Bestätigungsstellebestätigt sein.Weitere Sicherheitsfunktionen von eHealth-Kartenterminals, dieüber die Anforderungen an ein Signaturterminal hinausgehen,MÜSSEN in die anschließende Evaluierung eingebunden werdenoder MÜSSEN zusätzliche Sicherheitsgutachten oder Evaluierungenerfordern.Anforderungen aus der Funktion im Rahmen der qualifizierten SignaturerstellungMÜSSEN berücksichtigt werden.Das eHealth-Kartenterminal MUSS sich in Verbindung mit entsprechenderSoftware als Teil einer Signaturanwendungskomponente(HW und SW) entsprechend den Anforderungen aus SigG undSigV zur Erstellung von qualifizierten elektronischen Signatureneignen.Manipulationsversuche MÜSSEN zuverlässig erkennbar sein.Zur Erkennbarkeit von Hardware-Manipulationen MÜSSEN geeigneteMethoden (z. B. Versiegelung mit fälschungssicherem Sicherheitsaufkleber,welcher sich bei Entfernung zerstört und damitnur einmal verwendbar ist) verwendet werden.Die Sicherheit der Übergangsphase, in der eGK und KVK nebeneinanderexistieren müssen, MUSS gewährleistet werden.AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 254 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02586 S Sec_eHealth_Kartenterminal_Allg_10: Statusanzeige fürvertrauenswürdigen Zustands.A_02587 S Sec_eHealth_Kartenterminal_Allg_11: Statusanzeige fürsichere PIN-Eingabe.A_02588 S Sec_eHealth_Kartenterminal_Allg_12: Identifikation und AuthentifikationA_02589 S Sec_eHealth_Kartenterminal_Allg_13: Technische Funktionenzur Anwenderauthentifizierung.A_02590 S Sec_eHealth_Kartenterminal_Allg_14: Sichere PIN Eingabe.A_02591 S Sec_eHealth_Kartenterminal_Allg_15: Sichere Übertragungder Identifikationsdaten.A_02592 S Sec_eHealth_Kartenterminal_Allg_16: Unbeobachtete PIN-Eingabe muß möglich sein.Im Modus des vertrauenswürdigen Zustands des eHealth-Kartenterminal DARF es NICHT möglich sein das eHealth-Kartenterminal über externe Schnittstellen zu beeinflussen oderInformationen unbefugt auszulesen. Dieser Zustand MUSS demBenutzer über nicht extern zu beeinflussende Signaleinrichtungeneindeutig angezeigt werden. In der Benutzerdokumentation MUSSdie Signalisierung zusätzlich allgemeinverständlich beschriebenwerdenDer Modus der sicheren PIN-Eingabe MUSS dem Anwender optisch(LED oder Display) angezeigt werden.Das eHealth-Kartenterminal MUSS eine Identifikation und Authentifikationdes berechtigten Nutzers unterstützen, um auf gesicherteKartenbereiche zugreifen oder geschützte Kartenapplikationennutzen zu können.Das eHealth-Kartenterminal MUSS technische Funktionen zur Anwenderauthentifizierung(z. B. KeyPad) bieten. AuthentisierungsdatenDÜRFEN vom eHealth-Kartenterminal NICHT an das Host-System weitergegeben, DÜRFEN intern NICHT gespeichert undMÜSSEN fallbezogen angewendet werden.Die Firmware MUSS garantieren, dass die Kommandos zum Verifizierenund Modifizieren der PIN erkannt werden und durch Sicherheitsfunktionenzur „Sicheren PIN-Eingabe“ bearbeitet werden.Diese Sicherheitsfunktionen MÜSSEN gewährleisten, dass diePIN-Eingabe über das Keypad des Chipkartenlesers sicher an dieChipkarte weitergeleitet wird, ohne vom Host ausgespäht werdenzu können.Das Terminal MUSS mittels einer sicheren PIN-Eingabe die Identifikationsdaten(PIN) erfassen und sie auf sicherem Weg an sichereSignaturerstellungseinheiten (Signatur-Chipkarten) gemäß SigG §2 Nummer 10 übermitteln.Die Anforderungen an die Einsatzumgebung MÜSSEN so formuliertund umgesetzt werden, dass der Anwender die Möglichkeithat, seine Identifikationsdaten unbeobachtet einzugeben.AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 255 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02593 S Sec_eHealth_Kartenterminal_Allg_17: Identifikation und Authentisierungdurch kryptographischeIdentität.A_02594 S Sec_eHealth_Kartenterminal_Allg_18: Speicherbereiche derPIN-Daten.A_02595 S Sec_eHealth_Kartenterminal_Allg_19: keine Speicherungpersonenbezogener bzw. medizinischerDaten.A_02596 S Sec_eHealth_Kartenterminal_Allg_20: Verhinderung derManipulation temporär abgelegterDaten.Da das eHealth-Kartenterminal über ein LAN angesprochen wird,MUSS das eHealth-Kartenterminal eine kryptographische Identitätbesitzen, die dem Konnektor eine sichere Identifikation und Authentisierungdes Kommunikationspartners ermöglicht.Die Speicherbereiche der PIN-Daten MÜSSEN so aufbereitet werden,dass kein Angriff auf gespeicherte Daten möglich ist.Personenbezogene und medizinische Daten DÜRFEN NICHT imeHealth-Kartenterminal gespeichert werden können.Die Manipulation von Daten, die im eHealth-Kartenterminal (temporär)abgelegt sind, DARF NICHT möglich sein.AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1AnhangB 4.2.1B4.2.2 - Inbetriebnahme/BetriebAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02597 S Sec_eHealth_Kartenterminal_Betrieb_1: Deregistrierung nurdurch autorisierte Personen.A_02598 S Sec_eHealth_Kartenterminal_Betrieb_2: Registrierung durchAdministrator.A_02599 S Sec_eHealth_Kartenterminal_Betrieb_3: Löschung der Registrierung.A_02600 S Sec_eHealth_Kartenterminal_Betrieb_4:Elektrischer undmechanischer Schutz.Es MUSS sichergestellt sein, dass ein aktives (aus der Sicht desKonnektors über eine beliebige Schnittstelle erreichbares) eHealth-Kartenterminal nur von einer autorisierten Person am Konnektorderegistriert werden kann.Bei der Ersteinrichtung MUSS jedes eHealth-Kartenterminal amKonnektor vom lokalen Administrator des Konnektors am Konnektorangemeldet und registriert werden.Wird ein eHealth-Kartenterminal ausgetauscht (z. B. aufgrund einesDefektes) MUSS dessen Registrierung im Konnektor gelöschtwerden.Das eHealth-Kartenterminal MUSS die Chipkarte(n) elektrisch undmechanisch schützen und einen stabilen, fehlerfreien und unversehrtenBetrieb der Chipkarte(n) gewährleisten.AnhangB 4.2.2AnhangB 4.2.2AnhangB 4.2.2AnhangB 4.2.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 256 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02601 S Sec_eHealth_Kartenterminal_Betrieb_5: Sichere Umgebungund vertrauenswürdiger Betrieb.Das eHealth-Kartenterminal MUSS eine sichere Umgebung fürChipkarten bereitstellen und dem Kartenanwender einen erkennbarsicheren und vertrauenswürdigen Betrieb signalisieren.AnhangB 4.2.2B4.2.3 - Management/AdministrationAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02602 S Sec_eHealth_Kartenterminal_Admin_1: Administration überverschlüsselte Schnittstellen.A_02603 S Sec_eHealth_Kartenterminal_Admin_2: Abfrage und Änderungder Konfiguration nurnach Authentisierung.A_02604 S Sec_eHealth_Kartenterminal_Admin_3: Shcutz vor unbefugtemAuslesen der Konfiguration.A_02605 S Sec_eHealth_Kartenterminal_Admin_4: Passwortschutz desadministrativen Zugangs.A_02606 S Sec_eHealth_Kartenterminal_Admin_5: Autorisierung zuKonfigurationsänderung nurfür Administratoren.Terminalkommandos sowie die Kommunikation zu ManagementschnittstellenMÜSSEN zwischen Konnektor und eHealth-Kartenterminal immer über verschlüsselte Netzwerkverbindungenablaufen.Es DARF NICHT möglich sein, ohne erfolgreiche Authentifizierungdie Konfiguration abzufragen oder zu verändern. Dabei MÜSSENzwei Rollen unterschieden werden: Benutzer, Administrator. DerBenutzer DARF NICHT zu anderen Aktionen berechtigt sein außerdie aktuellen Einstellungen anzuzeigen und sein eigenes Kennwortzu ändern.Das Einsehen der aktuellen Konfiguration MUSS geschützt werden,da die Daten der Terminalkonfiguration Informationen enthaltenkönnen, die für DoS und ähnliche Attacken benutzt werdenkönnen.Der Schutz des Zugangs zu administrativen Einstellungen am e-Health-Kartenterminal mit einem Passwortmechanismus oder höhererSicherheit MUSS sichergestellt sein.Es MUSS sichergestellt sein, dass nur der Administrator Einstellungenzur Benutzerverwaltung, Netzwerkkonfiguration, den Terminal-und Slot-Namen sowie Zertifikate ändern darf.AnhangB 4.2.3AnhangB 4.2.3AnhangB 4.2.3AnhangB 4.2.3AnhangB 4.2.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 257 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.2.4 – SoftwareAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02607 S Sec_eHealth_Kartenterminal_SW_1: Neue Zulassung nachFirmwareaktualisierung.A_02608 S Sec_eHealth_Kartenterminal_SW_2:Freigabe durch CC-Prüfer/BSI/gematik.A_02609 S Sec_eHealth_Kartenterminal_SW_3:Firmwareaktualisierungnur durch autorisierte Personen.A_02610 S Sec_eHealth_Kartenterminal_SW_4: Sicherstellen der Integritätund Authentizität neuerFirmware gemäß BSI Vorgaben.A_02611 S Sec_eHealth_Kartenterminal_SW_5:Sicherstellen von vollständigenUpdate-Vorgängen.A_02612 S Sec_eHealth_Kartenterminal_SW_6: Fallback auf ale Firmware.Eine Veränderung der Firmware MUSS vom Hersteller der Zulassungsstelleschriftlich angezeigt werden. Die Veränderungen derFirmware MÜSSEN bewertet und bei Bedarf MÜSSEN Zusatzprüfungendurchgeführt werden. Die Zulassung wird gegebenenfallserneuert.Technisch/organisatorisch SOLL für jede Firmware-Version dieFreigabe durch Hersteller, CC-Prüfer bzw. BSI und gematik vorliegen.Es MUSS sichergestellt sein, dass die Firmware nur von einer autorisiertenPerson auf das eHealth-Kartenterminal aufgebrachtwird.Es MUSS sichergestellt sein, dass das eHealth-Kartenterminaleine Firmware nur dann als aktive Firmware übernimmt, wenn sieinteger und authentisch ist. Hierzu MÜSSEN Verfahren gemäß deraktuellen Richtlinien des BSI verwendet werden. Das notwendigeSicherheitsattribut MUSS in einem auslesegeschützten Bereichdes Terminals liegen. Das Verwaltungsverfahren MUSS mindestensden Anforderungen entsprechen, die in der Sicherheitsevaluierungund dem zugehörigen Protection Profile sowie den Sicherheitszielenzu Grunde gelegt werden.Es MUSS sichergestellt sein, dass das eHealth-Kartenterminal dieFirmware nur dann als aktive Firmware übernimmt, wenn sie vollständigin den Speicher übernommen wurde.Schlägt ein Firmware-Update fehl, MUSS das eHealth-Kartenterminal mit der vor dem Update-Versuch installierten Firmwarefunktionsfähig bleiben.AmhangB4.2.4AmhangB4.2.4AmhangB4.2.4AmhangB4.2.4AmhangB4.2.4AmhangB4.2.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 258 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02613 S Sec_eHealth_Kartenterminal_SW_7: Sicherstellen der Integritätund Authentizität vonFirmware bei Updates.A_02614 S Sec_eHealth_Kartenterminal_SW_8: Firmware muß währeddes gesamten lifecyle aktualisierbarsein.A_02615 S Sec_eHealth_Kartenterminal_SW_9: Firmware Update nurauf höhere oder gleiche Version.Beim Update der Firmware eines eHealth-Kartenterminals MUSSdie Integrität und Authentizität der eHealth-Kartenterminal Firmwaresichergestellt sein.Die Geräte-Firmware MUSS über die Lebensdauer des eHealth-Kartenterminals sicher aktualisiert werden können, um die Einführungneuer Funktionen, die Beseitigung von erkannten Sicherheitsrisikenund eine generelle Fehlerbehebung vornehmen zu können.Es MUSS sichergestellt sein, dass ein Austausch der Firmware nurgegen höhere oder gleiche Versionen als installiert möglich ist undnur nach Prüfung der Integrität und Authentizität der Firmware.Voraussetzung hierfür ist, dass das Terminal mit der neuen Firmware-Versionbereits validiert ist.AmhangB4.2.4AmhangB4.2.4AmhangB4.2.4B4.2.5 – NetzwerkAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02616 S Sec_eHealth_Kartenterminal_Netz_1:Beschränkung derKommunikationsmöglichkeiten.A_02617 S Sec_eHealth_Kartenterminal_Netz_2: Verschlüsselung derVerbindung zum Konnektor.A_02618 S Sec_eHealth_Kartenterminal_Netz_3: Beidseitige Authenti-Es MUSS sichergestellt sein, dass das eHealth-Kartenterminalaußer zum Zweck der dynamischen Netzwerkkonfiguration (z. B.DHCP) nur mit dem Konnektor und den Karten während des Betriebskommunizieren kann. Für den Fall der Administration KANNeine gesonderte Regelung möglich sein (z. B. Webinterface).Die Verbindung der eHealth-Kartenterminals mit dem KonnektorMUSS innerhalb des LAN beim Leistungserbringer mit einem alsausreichend definierten Verschlüsselungsverfahren verschlüsseltsein, wenn sicherheits-/datenschutzrelevante Daten übertragenwerden.Eine beidseitige Authentisierung MUSS durchgeführt werden.AnhangB 4.2.5AnhangB 4.2.5AnhangB 4.2.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 259 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktursierung.A_02619SSec_eHealth_Kartenterminal_Netz_4: Service DiscoveryKommandos müssen nichtverschlüsselt sein.Die Kommandos zum Auffinden der Terminals (Service Discovery)KÖNNEN im Klartext sein.AnhangB 4.2.5B4.3 - KonnektorB4.3.1 – AllgemeinAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02620 S Sec_Konnektor_Allg_01:Evaluierung nach CommonCriteria/Extended Basic .Der Konnektor MUSS nach CC evaluiert werden. Dies MUSS mindestensnach Extended Basic erfolgen.AnhangB 4.3.1A_02621 S Sec_Konnektor_Allg_02: Vorabprotokollierungerforderlich.A_02622 S Sec_Konnektor_Allg_03:(Konnektoridentität)Der Konnektor MUSS die geforderten Ereignisse vor der Durchführungder jeweiligen Aktion protokollieren. Schlägt die Protokollierungfehl, DARF die entsprechende Aktion NICHT durchgeführtwerden.Die Geräteidentität des Konnektors (Konnektoridentität) bildet denkryptographischen Anker für die In- und Außerbetriebnahme undden Netzzugang zur zentralen Telematikinfrastruktur. GrundsätzlichMUSS der Schlüssel zur Geräteidentität in einem sicherenSchlüsselspeicher hinterlegt sein. Das heißt, der private SchlüsselDARF NICHT ausgelesen werden können oder auf andere Weiseaußerhalb des Schlüsselspeichers bekannt werden. Die Anwendungdes Schlüssels erfolgt somit zwangsläufig innerhalb desSchlüsselspeichers. Der Schlüsselspeicher MUSS physikalischenAnhangB 4.3.1AnhangB 4.3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 260 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02623 S Sec_Konnektor_Allg_04: Erkennungvon Manipulationsversuchen.A_02624 S Sec_Konnektor_Allg_05:Schutz vor Manipulation.Angriffen auf die Vertraulichkeit des Schlüsselmaterials widerstehen(Tamper Resistance des Schlüsselspeichers).Der Konnektor SOLL folgende Manipulationsversuche zuverlässigerkennen:o Karten, die fälschlicherweise vorgeben eine SMC zu seino Aktivierung durch Unberechtigte (Wiederholte Eingabe einer falschenPIN)o Automatische PIN-Eingabe bei SMC-B durch eine Software imPSo Vortäuschen einer falschen Zeito VPN-Konzentratoren, die fälschlicherweise vorgeben ein VPN-Konzentrator der Telematikinfrastruktur zu seino Unberechtigte Weitergabe von eGK oder HBA-Informationenüber die Telematikinfrastrukturo Unberechtigte Weitergabe von Daten aus dem PS über denKonnektoro Manipulationen zwecks unverschlüsselter Weitergabe von Daten,die verschlüsselt sein sollteno Manipulationen zwecks Übernahme nicht vertrauenswürdigerSchlüsselo Geringe Verfügbarkeit durch unberechtigte netzseitige Anfrageno Manipulation der installierten Softwareo Manipulation der Tastatur des KonnektorsDer Konnektor SOLL geschützt sein gegen:o Unsichere Zustände nach Manipulation der Versorgungsspannungo Abstrahlung von sensiblen Informationen[Vom außerhalb des Gebäudes sollen keine Daten mehr funktechnischerfassbar sein. D. h. Vermeidung von Kathodenstrahlröhrenund einfache Abschirmung]o Funktionale Inbetriebnahme nach EntwendungAnhangB 4.3.1AnhangB 4.3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 261 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02625 S Sec_Konnektor_Allg_06:Schutz vor Mißbrauch.A_02626 S Sec_Konnektor_Allg_07:Erkennung von Manipulationsversuchen/Umgebung.A_02627 S Sec_Konnektor_Allg_08: Inaktivierungbei VerbindungsverlustA_02628 S Sec_Konnektor_Allg_09: Aktualisierungbei Ziehen einerKarte.A_02629 S Sec_Konnektor_Allg_10: Statusmeldungan Konnektor.A_02630 S Sec_Konnektor_Allg_11:Erkennugnvon Hardware-Manipulationen.Folgendes DARF NICHT möglich sein:o „Erschleichen“ einer Unterschrift von eGK oder HBA/SMCo Auslesen von privaten und geheimen Schlüsseln aus dem Konnektoro Unkontrolliertes Entschlüsseln von Daten durch den Konnektoro Unkontrolliertes Signieren von Daten durch den Konnektoro Unautorisiertes Einbringen einer Software in den Konnektoro Unautorisiertes Weiterreichen von Daten aus der Kommunikationzum eHealth-Kartenterminal durch den Konnektoro Man-in-the-Middle Attacken bei verschlüsselten Verbindungenzum Konnektoro Erfolgreicher Einsatz von Konnektor-KlonenDer Konnektor oder ggf. die Umgebung SOLL folgende Manipulationsversuchezuverlässig erkennen:o Zuordnung eines falschen eHealth-Kartenterminals zu einemArzt-Arbeitsplatz (Das KANN auch durch organisatorische Maßnahmengeschehen)o Unberechtigtes Öffnen des Gehäuses beim Einbox-Konnektoro Unberechtigter Austausch von Bausteinen oder BausteininhaltenEin zugewiesenes eHealth-Kartenterminal MUSS bei Verbindungsverlustvom Konnektor als inaktiv gekennzeichnet werden.Der eHealth-Kartenterminaldienst MUSS das Ziehen einer Karteerkennen und die Liste der vom Kartendienst verwalteten Kartenumgehend aktualisieren.Dem Konnektor MUSS der Status des eHealth-Kartenterminals(z.B. Karte gesteckt, Kartenterminal aktiv,...) zur Verfügung stehen.Zur Erkennbarkeit von Hardware-Manipulationen MÜSSEN geeigneteMethoden (z.B. Versiegelung mit fälschungssicherem Sicherheitsaufkleber,welcher sich bei Entfernung zerstört und damit nureinmal verwendbar ist) verwendet werden.AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 262 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02631 S Sec_Konnektor_Allg_12:Shcutz gegen Entwendung.A_02632 S Sec_Konnektor_Allg_13: AbgestufteReaktionen bei Sicherheitsverletzungen.A_02633 S Sec_Konnektor_Allg_14: ForwardSecrecybei Kanalverschlüsselung.A_02634 S Sec_Konnektor_Allg_15: Entropieder Zufallsquelle.A_02635 S Sec_Konnektor_Allg_16: Sicherstellender Verschlüsselung.A_02636 S Sec_Konnektor_Allg_17: Datenintegritätbei Datenübertragungzum Trusted ViewerA_02637 S Sec_Konnektor_Allg_18: Einhaltungder Anforderungenaus SigG und SigV.Die Hardware des Konnektors MUSS gegen Entwendung gesichertwerden.Der Konnektor MUSS bei Erkennen einer potentiellen Sicherheitsverletzungeine abgestufte Reaktion auslösen.Bei der Verschlüsselung von Kanälen MUSS sichergestellt werden,dass die Kompromittierung eines Session-Schlüssels nicht für dasAbhören zukünftiger Sessions verwendet werden kann (ForwardSecrecy).Die Zufallsquelle zur Erzeugung der Session Keys MUSS ausreichendgroße Entropie besitzen, um ein Erraten der Schlüssel mitgroßer Wahrscheinlichkeit zu verhindern.Der Konnektor MUSS auf Anwendungsebene sicherstellen, dassmedizinische Daten nur in verschlüsselter Form das Primärsystem-Netz über den Konnektor verlassen können.Bei der Übertragung von Daten an den Trusted Viewer MUSS derenIntegrität sichergestellt sein.Der Konnektor (Anwendungskonnektor und Trusted Viewer) isteine Signaturanwendungskomponente gemäß § 2 Nr. 11 SigG undMUSS deshalb die Anforderungen des Signaturgesetzes (insbesondere§ 17 Abs. 2 SigG, § 15 Abs. 2 SigV und Anlage 1 zu SigV)erfüllen. Durch den Anwendungskonnektor und Trusted ViewerMUSS festgestellt werden können (§ 17 Abs. 2 Satz 2 Nr. 1-5SigG):o auf welche Daten sich die Signatur bezieht,o ob die signierten Daten unverändert sind,o welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist,o welche Inhalte das qualifizierte Zertifikat auf dem die Signaturberuht und qualifizierte Attributzertifikate aufweisen,o zu welchem Ergebnis die Nachprüfung von Zertifikaten geführtAnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1AnhangB 4.3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 263 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02638 S Sec_Konnektor_Allg_19: Statusanzeigefür vertrauenswürdigenModus.A_02639 S Sec_Konnektor_Allg_20: Nutzungvon Stylesheets für dieDokumente der Telematikinfrastruktur.A_02640 S Sec_Konnektor_Allg_21:Schutz bei Entwendung einesKonnektors.hat,o ob der Inhalt der zu signierenden oder signierten Daten hinreichenderkennbar wird (§ 17 Abs. 2 Satz 3 SigG),o ob bei der Erzeugung einer qualifizierten elektronischen Signaturdie Identifikationsdaten nicht preisgegeben werden und diese nurauf der jeweiligen sicheren Signaturerstellungseinheit gespeichertsind (§ 15 Abs. 2 Nr. 1 a) SigV),o ob die Signatur nur durch die berechtigt signierende Person erfolgt(§ 15 Abs. 2 Nr. 1 b) SigV),o ob die Erzeugung von Signaturen vorher eindeutig angezeigtwird (§ 15 Abs. 2 Nr. 1 c) SigV),o ob bei der Prüfung einer qualifizierten elektronischen Signatur dieKorrektheit der Signatur zuverlässig geprüft und zutreffend angezeigtwird (§ 15 Abs. 2 Nr. 2 a) SigV),o ob der Konnektor eindeutig erkennen lässt, dass die nachgeprüftenqualifizierten Zertifikate im jeweiligen Zertifikat-Verzeichnis zumangegebenen Zeitpunkt vorhanden und nicht gesperrt waren (§ 15Abs. 2 Nr. 2 b) SigV),ob sicherheitstechnische Veränderungen am Konnektor für denNutzer erkennbar werden (§ 15 Abs. 4 SigV).Es MUSS vom Benutzer zuverlässig erkannt werden können, obsich eine Bildschirmanzeige in einem vertrauenswürdigen Modusbefindet.Die vertrauenswürdige Anzeigekomponente MUSS in der Lagesein, Daten im XML-Format mit vordefinierten, in die Signatur einbezogenenStylesheets zu unterstützen. Hierbei MÜSSEN mindestensStylesheets für die Dokumente der Telematikinfrastruktur unterstütztwerden.Bei der Auslieferung des Konnektors MUSS dafür gesorgt werden,dass ein Entwenden des Konnektors und weiterer Komponentennicht für Angriffe auf die Telematik-Plattform genutzt werden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 264 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02641 S Sec_Konnektor_Allg_22:Schutz vor manipulierten Aufrufen.A_02642 S Sec_Konnektor_Allg_23:Schutz eingeschleusten Aufru-A_01844A_02082A_01844A_02082SSfen über den Datenpfad.Sec_Konnektor_Allg_24:Anfragean UFS nur beigesteckter eGK.Sec_Konnektor_Allg_25: Sicherertransparenter Zugriffauf Gesundheitsdaten undFunktionen der eGK für diePrimärsysteme.Es MUSS verhindert werden, dass ein Angreifer den Konnektordurch manipulierte Aufrufe – insbesondere aus dem Primärsystemnetz– in einen unsicheren Systemzustand bringen kann.Es MUSS verhindert werden, dass ein Angreifer dem Konnektorüber den Datenpfad – beispielsweise aus dem Primärsystem –Daten zuführen kann, die zur Ausführung gelangen.Der Konnektor MUSS sicherstellen, dass eine Anfrage an den UpdateFlag Service nur dann erfolgen kann, wenn die eGK des Versicherten,zu dem auf vorliegende Updates geprüft werden soll,gesteckt ist.Sicherer transparenter Zugriff auf Gesundheitsdaten und Funktionender eGK für die Primärsysteme:Durch die Primärsystemschnittstelle des Konnektors zum transparentenZugriff auf Daten und Schlüssel der eGK DARF NICHT eineUmgehung der Sicherheitsfunktionalitäten des Anwendungskonnektorserfolgen. (Die zusätzliche Nutzung der eGK für Mehrwertanwendungenwird durch die gematik unterstützt. Die vom Konnektordazu bereitgestellte Schnittstelle zum transparenten Zugriff aufdie Funktionen der eGK DARF jedoch NICHT zu einer Beinträchtigungder Sicherheit der §291a Anwendungen führen. Es MUSSsichergestellt sein, dass durch die Schnittstellenfunktionen desKonnektors keine verborgenen Kanäle zur Umgehung der Sicherheitsfunktionendes Anwendungskonnektors als zugelassenes APIbereitgestellt und zugelassen werden.)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 265 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.3.2 - Inbetriebnahme/BetriebAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02643 S Sec_Konnektor_Betrieb_01:Prüfung der Integrität und Authentizitätdes Konnektors.A_02644 S Sec_Konnektor_Betrieb_02:Inbetriebnahme nur bei Integritätdes Konnektors.A_02645 S Sec_Konnektor_Betrieb_03:Korrektur der Systemuhr.A_02646 S Sec_Konnektor_Betrieb_04:Konfiguration nur durch autorisiertePersonen.A_02647 S Sec_Konnektor_Betrieb_05:Freischaltung der SMC-Bdurch PIN.A_02648 S Sec_Konnektor_Betrieb_06:Authentisierung durch PIN-Abfrage.Die Integrität und Authentizität des Konnektors MUSS vor dessenerstmaliger Inbetriebnahme von einer autorisierten Person geprüftund bestätigt werden.Ein Konnektor DARF NICHT in Betrieb genommen werden, wenner nicht integer ist.Die Systemuhr des Konnektors MUSS bei Bedarf von einer autorisiertenPerson eingestellt/administiert werden.Die Netzwerkschnittstellen des Konnektors MÜSSEN von einerautorisierten Person konfiguriert werden.Wenn der Konnektor eine Verbindung zur Telematikinfrastrukturaufnimmt, MUSS die SMC-B mittels korrekter PIN frei geschaltetworden sein.Der rechtmäßige Konnektor-Benutzer MUSS durch Abfrage derSMC-B-PIN (oder vergleichbares) festgestellt werden.AnhangB 4.3.2AnhangB 4.3.2AnhangB 4.3.2AnhangB 4.3.2AnhangB 4.3.2AnhangB 4.3.2B4.3.3 - Management/AdministrationAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02649 S Sec_Konnektor_Admin_01:Administratoren dürfen medizinischeDaten bzw. vertraulichepersonenbezogene DatenEs DARF für Administratoren und anderes technisches PersonalNICHT die Möglichkeit bestehen über die Management- und Konfigurationsschnittstelledes Konnektors medizinische Daten zu sehen.Im Speziellen DARF der Administrator NICHT die Möglichkei-AnhangB 4.3.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 266 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellenicht einsehen können.ten besitzen, vertrauliche Daten am Konnektor im Klartext abzuhören.A_02650 S Sec_Konnektor_Admin_02:Physischer Zutrittsschutz.A_02651 S Sec_Konnektor_Admin_03:Abgesicherter Zugang zurManagemntschnittstelle.A_02652 S Sec_Konnektor_Admin_04:Änderung von Default Passwörternbei Inbetriebnahme.A_02653 S Sec_Konnektor_Admin_05:Passwörter gemäß BSI-Vorgabe.A_02654 S Sec_Konnektor_Admin_06:Authentisierung des AdministratorsDer physische Zutritt zu Management- oder AdministrationsarbeitsplatzSOLL eingeschränkt sein und sie müssen einer eigenenausreichend definierten Sicherheits-Policy unterliegen.Es MUSS sichergestellt werden, dass der Zugang zur Managementschnittstelledurch sichere Verfahren erfolgt.Es MUSS für den Fall, dass zur Sicherung der Managementschnittstelledie Authentisierungsmethode Benutzername&Passwortverwendet wird, geprüft werden, ob beim Zugangzur Managementschnittstelle bei der Erstinbetriebnahme ein DefaultPasswort existiert. Falls ein solches Default Passwort existiert,MUSS dieses durch ein neues Passwort ausgetauscht werden.Es MUSS geprüft werden, ob der Zugang zur Managementschnittstelledurch Passwörter gemäß den Empfehlungen des BSI (sieheKapitel M 2.11 Regelungen des Passwortgebrauchs der IT-Grundschutzkataloge) gesichert ist.Der Konnektor MUSS den Administrator zuverlässig authentifizieren.Jeder lokale Administrator MUSS eine eigene Zugangskennungbesitzen. Die sicherheitsrelevanten Aktionen des AdministratorsMÜSSEN zuverlässig protokolliert werden.AnhangB 4.3.AnhangB 4.3.AnhangB 4.3.AnhangB 4.3.AnhangB 4.3.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 267 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.3.4 – SoftwareAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02655 S Sec_Konnektor_SW_01: VertrauenswürdigesNachladenvon SoftwareA_02656 S Sec_Konnektor_SW_02: Freigabevon Software-Updates.A_02657 S Sec_Konnektor_SW_03: NurEinsatz evaluierter und zugelassenerSoftware.A_02658 S Sec_Konnektor_SW_04: Re-Evaluierung bei Änderungen.A_02659 S Sec_Konnektor_SW_05:Softwareevaluierung ungültige/überlangeParameterA_02660 S Sec_Konnektor_SW_06: Integritätund Authentizität vonBasis- und Fachmodulen.A_02661 S Sec_Konnektor_SW_07: Einspielenvon Softwarepaketennur duch autorisierte Personen.A_02662 S Sec_Konnektor_SW_08:Aktivierung von SoftwarepaketenDer Konnektor MUSS einen Mechanismus zum vertrauenswürdigenNachladen von Software haben.Technisch/organisatorisch MUSS für jede Software-Version dieFreigabe durch Hersteller, gematik sowie Prüfstelle und Zertifizierungsstelle(BSI) im Rahmen der CommonCriteria Prüfung vorliegen.Freigegebene Software MUSS signiert sein, der KonnektorMUSS diese Signatur beim Update prüfen.Es MUSS sichergestellt sein, dass nur von der gematik zugelasseneund entsprechend dem Protection Profile evaluierte Softwareauf dem Konnektor eingesetzt wird.[Gegebenenfalls ist ein Code Review erforderlich. Diese Anforderungbefindet sich noch in Abstimmung. Das Kapitel wird in einerspäteren Version des Dokumentes ergänzt]Bei sicherheitsrelevanten Änderungen MUSS eine Re-Evaluierungund Zertifizierung stattfindenIm Zuge der Evaluation MÜSSEN alle extern vom Konnektor angebotenenProtokolle auf ungültige/überlange Parameter getestetwerden.Ein Konnektor MUSS vor der Ausführung von Basis- und Fachmodulenderen Integrität und Authentizität sicherstellen.Ein Software-Paket (Basis- oder Fachmodule) MUSS von einerautorisierten Person auf den Konnektor aufgebracht werden.Der Konnektor MUSS sicherstellen, dass ein Software-Paket nurdann als aktives Software-Paket übernommen wird, wenn es voll-AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 268 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellenur, wenn diese vollständigsind.A_02663 S Sec_Konnektor_SW_09:Aktivierung von Softwarepaketennur, wenn diese integer- undauthentisch sind.A_02664 S Sec_Konnektor_SW_10: Reaktivierungdes ursprünglichenSoftwarestandes bei fehlgeschlagenemUpdate.A_02665 S Sec_Konnektor_SW_11: Prüfungdes Update-Server aufAuthentizität.A_02666 S Sec_Konnektor_SW_12: Prüfungder Firmwaresigantur vorInstallation.A_02667 S Sec_Konnektor_SW_13: Prüfungvon Authentizität undIntegrität der installiertenSoftware bei jedem Bootvorgang.A_02668 S Sec_Konnektor_SW_14: Prüfungvon Authentizität undIntegrität der installiertenSoftware im laufenden Betrieb.A_02669 S Sec_Konnektor_SW_15: Privilegienund Prozesskontext.A_02670 S Sec_Konnektor_SW_16: Nutzungeines gehärteten Betriebsystems.ständig in den Konnektorspeicher übernommen wurde.Der Konnektor MUSS sicherstellen, dass ein Software-Paket nurdann als aktives Software- Paket übernommen wird, wenn es integer-und authentisch ist.Schlägt ein Software-Update fehl, MUSS der Konnektor mit demalten Software-Paket funktionsfähig bleiben oder durch einen manuellenEingriff (z. B. Installation der Software vor dem Update-Versuch mittels CD oder USB-Stick) wieder herstellbar sein.Der Update-Server MUSS mittels kryptographischer Mechanismenauf Authentizität geprüft werden.Vor der Inbetriebnahme MUSS die Signatur der vom Werk vorinstalliertenFirmware geprüft werden.Der Konnektor MUSS bei jedem Boot die Authentizität und Integritätder installierten Software des Konnektors prüfen.Der Konnektor MUSS im laufenden Betrieb bei Bedarf eine Prüfungder Authentizität und Integrität der installierten Software desKonnektors durchführen können.Über das LAN zugängliche Dienste MÜSSEN in einem Prozesskontextmit niedrigen Privilegien laufen.Der Konnektor MUSS auf einem für den spezifischen Einsatzzweckgehärteten Betriebssystem betrieben werden.AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 269 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02671 S Sec_Konnektor_SW_17: Offlineprüfungder Software-Integrität.A_02672 S Sec_Konnektor_SW_18:Schutz vor unautorisiertemAustausch von Softwarekomponenten.A_02673 S Sec_Konnektor_SW_19:Speicherschutz des Betriebssystems.A_02674 S Sec_Konnektor_SW_20: Generierungvon Auditdaten.A_02675 S Sec_Konnektor_SW_21:Analyse von Events und Fehlermeldungen.A_02676 S Sec_Konnektor_SW_22: Sicherstellendes sicheren Betriebszustandes.A_02677 S Sec_Konnektor_SW_23: Löschenvon Sicherheitsbeziehungen.A_02678 S Sec_Konnektor_SW_24:Schutzmaßnahmen für Software-Update-Dienste.A_02679 S Sec_Konnektor_SW_25: ZeitnaheSoftwareaktualisierung.Die Prüfung der Integrität des Konnektors SOLL auch offline durchden lokalen Administrator durchgeführt werden können. Falls derTrusted Viewer auch als separates Gerät ausgelegt ist, SOLL sichdie Software selbst prüfen.Das Betriebssystem des Konnektors MUSS den unautorisiertenAustausch von Software-Komponenten verhindern (Normalbetriebund beim Update).Das Betriebssystem des Konnektors MUSS Maßnahmen (Speicherschutz,etc.) ergreifen, um einen Stack-Smashing- oder Heap-Overflow-Angriff zu verhindern.Der Konnektor MUSS entsprechend SGB V §291a Auditdaten fürdie eGK generieren.Der Konnektor MUSS Events und Fehlermeldungen analysieren.Das Betriebssystem des Konnektors DARF (durch Konfigurationeines Administrators oder durch einen Angreifer, der z.B. die Versorgungsspannungmanipuliert) NICHT in einen unsicheren Betriebszustand(z. B. Umgehen von Sicherheitsmechanismen, Nutzungschwacher Algorithmen etc.) versetzt werden können.Alle nicht mehr benötigten Sicherheitsbeziehungen MÜSSEN ausdem Speicher des Konnektors sicher entfernt werden.Für die Software-Update-Dienste MÜSSEN besondere Sicherheitsmaßnahmenvorgesehen werden, durch die die Authentizität,Integrität und Verfügbarkeit des Dienstes und optional die Vertraulichkeitder mit dem Konnektor ausgetauschten Daten sichergestelltist.Es MUSS sichergestellt sein, dass auf den Konnektoren nach einerdefinierten Übergangszeit die aktuellen Software-Stände installiertAnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4AnhangB 4.3.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 270 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02680 S Sec_Konnektor_SW_26: Unterstützungvon Kryptographiealgorithmenund Schlüssellängengemäß Kryptographiekonzept.sind; das gilt insbesondere für Updates.Der Konnektor MUSS alle Kryptographiealgorithmen und Schlüssellängenunterstützen, die gemäß Kryptographiekonzept der gematikund [gemSpecKrypt] vom Konnektor gefordert werden.AnhangB 4.3.4B4.3.5 – NetzwerkAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02681 S Sec_Konnektor_Netz_01:Verschlüsselung Primärsystemzu Konnektor.A_02682 S Sec_Konnektor_Netz_02:Verschlüsselung der VerbindungeHealth-Kartenterminal zuKonnektor.A_02683 S Sec_Konnektor_Netz_03:Verschlüsselung der VerbindungKonnektor zu TI.A_02684 S Sec_Konnektor_Netz_04: Nurzwingend benötigte Ports sindoffen.Die Verbindung des Primärsystems mit dem Konnektor KANN innerhalbdes LAN beim Leistungserbringer mit einem als ausreichenddefinierten Verschlüsselungsverfahren verschlüsselt sein.Die Verbindung der eHealth-Kartenterminals mit dem KonnektorMUSS innerhalb des LAN beim Leistungserbringer mit einem alsausreichend definierten Verschlüsselungsverfahren verschlüsseltsein, wenn sicherheits-/datenschutzrelevante Daten übertragenwerden.Eine beidseitige Authentisierung MUSS durchgeführt werden.Die Kommandos zum Auffinden der Terminals (Service Discovery)KÖNNEN im Klartext sein.Die Datenverbindung zwischen Konnektor und TelematikinfrastrukturMUSS mit einem als ausreichend definierten Verschlüsselungsverfahrenin den verschiedenen Authentifikationslevels verschlüsseltsein.Es MUSS sichergestellt sein, dass der Konnektor auf dem Netzwerkanschlussin Richtung Telematikinfrastruktur nur die für denBetrieb des VPNs benötigten Ports anbietet.AnhangB 4.3.5AnhangB 4.3.5AnhangB 4.3.5AnhangB 4.3.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 271 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02685 S Sec_Konnektor_Netz_05:Ansicherung der über das Netzerreichbaren Dienste.A_02686 S Sec_Konnektor_Netz_06: KeinVerbindungsaufbau aus demInternet.A_02687 S Sec_Konnektor_Netz_07:Schutz der über die ManagementschnittstelleausgetauschtenDaten.A_02688 S Sec_Konnektor_Netz_08:Schutz des Primärsystem-Netzes.A_02689 S Sec_Konnektor_Netz_09:Schutz des TI-Netzes.Zumindest für jene Dienste, die über Netzwerk-Schnittstellen ansprechbarsind, MÜSSEN Vorkehrungen gegen Angriffe getroffenwerden.Einen Verbindungsaufruf aus dem Internet DARF der KonnektorNICHT zulassen. Er ist immer der Initiator.Die Integrität und Vertraulichkeit der Daten, die über die Managementschnittstellezur Konfiguration/Diagnose ausgetauscht werden,MUSS sichergestellt sein.Der Konnektor MUSS verhindern, dass das Primärsystem-Netzaus dem Transportnetz, der Telematik-Plattform oder eventuellvorhandenen Mehrwertdienst-Netzen zugreifbar und angreifbarwird. Der Konnektor MUSS eine vollständige Informationsflusskontrollefür IP-Pakete realisieren. Bei der Paketfilterung des KonnektorsMÜSSEN beispielsweise auch Fragmente von potenziell gefährlichenIP-Paketen gefiltert werden.Der Konnektor MUSS verhindern, dass die Telematik-Plattform ausdem Primärsystem-Netz angreifbar wird. Deshalb MUSS sichergestelltsein, dass die Kommunikation aus dem Primärsystem-Netznur über den als Proxy fungierenden Anwendungskonnektor undden Netzkonnektor in die Telematikinfrastruktur gelangen kann.AnhangB 4.3.5AnhangB 4.3.5AnhangB 4.3.5AnhangB 4.3.5AnhangB 4.3.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 272 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.4 - SmartcardsB4.4.1 – AllgemeinAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02690 S Sec_SmartCards_Allg_01:Authentizität der PersonalisierungsdatenA_02691 S Sec_SmartCards_Allg_02:Vertraulichkeit der PersonalisierungsdatenA_02692 S Sec_SmartCards_Allg_03:Sperrung nicht durch fremdeKartenherausgeber.A_02693 S Sec_SmartCards_Allg_04: Dieeingesetzten SmartcardsMÜSSEN manipulationssichersein.A_02694 S Sec_SmartCards_Allg_05:Konformität mit Standard I-SO7816.A_02695 S Sec_SmartCards_Allg_06:Verarbeitung von CV-Zertifikaten.A_02696 S Sec_SmartCards_Allg_07:Möglichkeit zur qualifiziertenelektronischen Signatur.A_02697 S Sec_SmartCards_Allg_08:Schutz vor invasiven Angriffen.Die Authentizität der Personalisierungsdaten MUSS in allen Prozessschrittenbeim Kartenherausgeber bzw. den von ihm beauftragtenDienstleistern sichergestellt sein.Für einen Teil der Personalisierungsdaten (z. B. Schlüssel) MUSSdie Vertraulichkeit der Daten sichergestellt werden.Es MUSS sichergestellt werden, dass kein fremder Kartenherausgebereine Karte sperren kann.Smartcards gelten aus Sicherheitssicht als die vertrauenswürdigstenKomponenten in der nicht vertrauenswürdigen Zone 1 (DezentralFrontend extern). Die eingesetzten Smartcards MÜSSEN manipulationssichersein.Allgemein MÜSSEN die Chipkarten nach dem Standard ISO7816gestaltet sein.Die Karten (eGK, HBA, SMC) MÜSSEN CV-Zertifikate interpretierenund verarbeiten können.Die Karten (eGK, HBA) MÜSSEN die technischen Möglichkeitenzur qualifizierten elektronischen Signatur bieten.Die Karten (eGK, HBA, SMC) MÜSSEN Schutz gegen invasiveAngriffe bieten.AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 273 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02698 S Sec_SmartCards_Allg_09:Ausstattung mit Sensoren.A_02699 S Sec_SmartCards_Allg_10:Integration in Schutzschicht.A_02700 S Sec_SmartCards_Allg_11:Schutz vor nicht-invasivenAngriffen.A_02701 S Sec_SmartCards_Allg_12:Schutz vor Sidechannel Attacks.A_02702 S Sec_SmartCards_Allg_13:Schutz vor provozierten Chipkartenfehlern.A_02703 S Sec_SmartCards_Allg_14:Schutz vor unkontrollierter/unautorisierterNutzung.Smartcards MÜSSEN mit Temperatur-, Frequenz- und Spannungssensorenausgestattet sein.Es MUSS eine feste Verbindung der Bausteine mit der Schutzschichtgeben, bei deren Entfernung das Bauelement zerstört werdenMUSS.Die Karten (eGK, HBA, SMC) MÜSSEN Schutz gegen nichtinvasiveAngriffe bieten.Die Karten MÜSSEN Schutz gegen Sidechannel Attacks bieten.Die Karten MÜSSEN Schutz gegen durch Stress forcierte Chipkartenfehlerbieten. D. h. die Karte DARF durch falsche Eingaben,Manipulation der Strom- und Taktversorgung, durch Kälte, Hitzeoder Strahlung NICHT in unsichere Zustände geraten oder falscheAusgaben machen.Folgende Punkte DÜRFEN bei Chipkarten NICHT möglich sein:o Automatische maschinelle PIN-Eingabe bei HBA und SMC durchdas System.o Ungeschützte Übertragung der PIN-Eingabe im LAN oder amPC.o Auslesen von privaten und geheimen Schlüsseln aus der Karte(eGK, HBA, SMC).o Unkontrolliertes Entschlüsseln von Daten durch die Karte.o Unkontrolliertes Signieren von Daten durch die Karte.o Unautorisiertes Einbringen einer Karten-Applikation in die Karteüber CAMS.o Unautorisierter Zugriff auf eGK ohne Anwesenheit eines HBA(bzw. Ersatz).o Chance zum Erstellen von Karten-Klonen.AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 274 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02704 S Sec_SmartCards_Allg_15:Entropie der Initial-PINs.A_02705 S Sec_SmartCards_Allg_16:Unabhänigkeit einer Folge vonInitial-PINS.A_02706 S Sec_SmartCards_Allg_17:Ableitung der aus Personenmerkmalendarf nicht möglichsein.A_02707 S Sec_SmartCards_Allg_18:Sichere übermittlung der Initial-PIN.A_02708 S Sec_SmartCards_Allg_19:Aufklärung des Endanwenders.A_02709 S Sec_SmartCards_Allg_20:Unterschiedliche Auth- bzw-Sig-PIN.A_02710 S Sec_SmartCards_Allg_21:Änderung der PIN nur nachvorgeriger Authentisierung.A_02711 S Sec_SmartCards_Allg_22:Medizinische Anwendungsdatennicht im Klartext.A_02712 S Sec_SmartCards_Allg_23:Vernichtung fehlerhafter Chip-Initial erzeugte PINs MÜSSEN eine der verfügbaren Stellenanzahlangemessene maximale Entropie aufweisen.Von einer beliebig langen Folge von initialen Signatur PINs DARFNICHT auf die nächste Signatur-PIN zu schließen sein.Es MUSS sichergestellt sein, dass von keinem Merkmal der Person,die mit einem Signatur-Schlüssel assoziiert ist, auf deren initialePIN zu schließen sein kann.Die initiale PIN MUSS auf einem dem Stand der Technik ausreichendvertrauenswürdigen Weg der mit einem Signatur-Schlüsselassoziierten Person zur Kenntnis gebracht werden. Es MUSS sichergestelltsein, dass kein Dritter gleichzeitig Zugriff auf den Signaturschlüsselund die initiale PIN hat noch die Information darüberbesitzt, mit welcher Person eine konkrete PIN assoziiert ist.Der Endanwender MUSS darüber aufgeklärt werden, welche PINser im Falle änderbarer PINs nicht verwenden sollte.Im Rahmen des Erstellungsprozesses initialer PINs MUSS technischsichergestellt werden, dass die Authentifikations-PIN von derSignatur-PIN verschieden ist. Im Rahmen des ÄnderungsprozessesMUSS darauf hingewiesen werden, dass die PINs verschiedensind.Es MUSS sichergestellt sein, dass die PIN, die einen Authentifikations-Schlüsselschützt, nur über einen wohl definierten Prozessund mindestens nach Eingabe der alten PIN änderbar sein darf.Medizinische Anwendungsdaten DÜRFEN dem KartenherausgeberNICHT als Klartext zur Verfügung stehen.Chipkarten, die vor Ausgabe an den Karteninhaber als fehlerhafterkannt werden, MÜSSEN ordnungsgemäß vernichtet werden.AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1AnhangB 4.4.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 275 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellekarten.A_02713 S Sec_SmartCards_Allg_24:Auslieferung an den Karteninhaber.A_02714 S Sec_SmartCards_Allg_25:Sperrung und Entsperrung vonPIN.Chipkarten, die fehlerfrei produziert wurden, MÜSSEN an den vorgesehenenKarteninhaber übergeben werden.Die durch PIN geschützten Funktionen MÜSSEN gesperrt bleiben,wenn die PIN drei Mal hintereinander falsch eingegeben wurde.Eine weitere Eingabe der PIN DARF dann NICHT mehr möglichsein. Durch die zugehörende PUK MUSS die Sperrung wieder aufgehobenwerden können, wobei die PUK insgesamt maximal 10Mal richtig/falsch eingegeben werden darf. Die PIN MUSS dabeiauf einen neuen Wert gesetzt werden könnenAnhangB 4.4.1AnhangB 4.4.1B4.4.2 – eGKAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02715 S Sec_SmartCards_eGK_01:Beachtung der gesetzlichenBestimmungen bei QES.A_02716 S Sec_SmartCards_eGK_02:Protokollierung eines Statuswechsels.A_02717 S Sec_SmartCards_eGK_04:Authentisierung des Versichertengegenüber eGK.A_02718 S Sec_SmartCards_eGK_04:Vertrauliches Nachladen von An-Bei der Zustellung von eGKs mit qualifizierter elektronischer SignaturMÜSSEN die gesetzlichen Bestimmungen eingehalten werden.Zeitpunkt und Grund eines Statuswechsels einer eGK in der PKI(z. B. Sperrung) MÜSSEN protokolliert werden.Der Versicherte MUSS sich gegenüber der eGK identifizieren.Das eventuelle Nachladen einer Anwendung auf die eGK MUSSvertraulich erfolgen.AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 276 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellewendungen.A_02719 S Sec_SmartCards_eGK_05:Sicherstellen der Integritätbeim Nachladen einer Anwendung.A_02720 S Sec_SmartCards_eGK_06:Zugriffsprotokoll.A_02721 S Sec_SmartCards_eGK_07:Schutz des Zugriffsprotokolls.A_02722 S Sec_SmartCards_eGK_08:Schutz der Integrität desZugriffsprotokolls auf äquivalentenSicherheitsniveau.A_02723 S Sec_SmartCards_eGK_08:Schutz der Einträge imZugriffsprotokoll.A_02724 S Sec_SmartCards_eGK_10:Löschen von Einträgen imZugriffsprotokoll.A_02725 S Sec_SmartCards_eGK_11:Verfügbarkeit des Zugriffsprotokolls.A_02726 S Sec_SmartCards_eGK_12:Authentisierung eGK gegenüberCAMS.Die Integrität von Daten MUSS beim Nachladen einer Anwendungauf eine eGK gewährleistet sein.Es MÜSSEN auf der eGK für Zwecke der Datenschutzkontrolle dieProtokolldaten mindestens der letzten 50 Zugriffe auf Daten desVersicherten abrufbar seinDas Zugriffsprotokoll der letzten 50 Zugriffe auf einer eGK MUSSdurch ein Authentifikationsverfahren, das bei einem Zugriff auf dasProtokoll einen eindeutigen Bezug zum der eGK zugeordnetenVersicherten zulässt, geschützt werden.Es MUSS sichergestellt sein, dass das Zugriffprotokoll einer eGKnur durch Mechanismen verändert werden kann, die kein geringeresSicherheitsniveau als die Karte selbst aufweisen.Ein Eintrag des Zugriffsprotokolls der eGK DARF NICHT geändertwerden.Es MUSS sichergestellt sein, dass ein Eintrag des Zugriffsprotokollsder eGK nur im Rahmen eines Überlaufes des Protokollspeichersdurch Überschreiben mit einem Eintrag jüngeren Datumsmittels eines Mechanismus, der kein geringeres Sicherheitsniveauals die Karte selbst hat, gelöscht werden darf.Das Zugriffsprotokoll einer eGK MUSS mindestens solange verfügbarsein, solange die eGK ausreichend funktionsfähig ist und imRahmen technischer Prozesse zum Bezug medizinischer Leistungenberechtigt.Die eGK MUSS sich gegenüber dem Kartenherausgeber (CAMS)authentifizieren, voro dem Auflisten von Anwendungen,AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2AnhangB 4.4.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 277 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02727 S Sec_SmartCards_eGK_13:Authentisierung CAMS gegenübereGK.A_02728 S Sec_SmartCards_eGK_14:Authentisierung Kartenherausgebergegenüber Anwendungsbetreiber.o dem Nachladen von Anwendungen,o dem Aktivieren einer Anwendung,o dem Aktualisieren einer Anwendung,o dem Deaktivieren einer Anwendung,o dem Löschen einer Anwendung,o dem Ermitteln von Speicherplatz.Der Kartenherausgeber (CAMS) MUSS sich gegenüber der eGKauthentifizieren, voro dem Auflisten von Anwendungen,o dem Nachladen von Anwendungen,o dem Aktivieren einer Anwendung,o dem Aktualisieren einer Anwendung,o dem Deaktivieren einer Anwendung,o dem Löschen einer Anwendung,o dem Ermitteln von Speicherplatz.Der Kartenherausgeber MUSS sich vor dem Aufrechterhalten derZugriffsmöglichkeit auf Online Anwendungsdaten gegenüber demAnwendungsbetreiber authentisieren.AnhangB 4.4.2AnhangB 4.4.2B4.4.3 – HBAAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02729 S Sec_SmartCards_HBA_01:Freischaltung des HBA durchPIN.Der HBA MUSS mittels einer PIN freigeschaltet werden.AnhangB 4.4.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 278 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02730 S Sec_SmartCards_HBA_02:Unbeobachtete PIN-Eingabebei Freischaltung des HBA.A_02731 S Sec_SmartCards_HBA_03:Sperrung nach Fehleingabe.A_02732 S Sec_SmartCards_HBA_04:Freischaltung mittels PUK.A_02733 S Sec_SmartCards_HBA_05:Erneute Freischaltung mittelsPIN.A_02736 S Sec_SmartCards_HBA_08:Nichtveränderbarkeit der Signatur.A_02737 S Sec_SmartCards_HBA_09:Authentizitäts- und Integritätprüfung.A_02738 S Sec_SmartCards_HBA_10:SigG-konformer Zertifizierungsdienstanbieter.Die Einsatzumgebung des HBA MUSS sicherstellen, dass die PIN-Eingabe unbeobachtet erfolgen kann (z. B. Sichtschutz).Nach einer dreimaligen Fehleingabe der PIN MUSS der HBA gesperrtwerden.Ein gesperrter HBA MUSS für eine definierte Anzahl von Anwendungenmittels einer PUK freigeschaltet werden können.Nach der korrekten Eingabe der PUK MUSS die Freischaltung desHBA mittels der PIN wieder möglich sein.Eine HBA-Signatur DARF NICHT in einem technisch oder zeitlichvertretbaren Rahmen derart verändert werden, dass ein anderesals das ursprünglich vom Signierenden unterzeichnete Informationsobjektals rechtsgültiges Informationsobjekt anerkannt wird.Um die Authentizität und Integrität von signierten Informationsobjektenzu überprüfen MUSS, falls notwendig, bei einer Aufteilungsichergestellt werden, dass der ursprüngliche Zustand wiederhergestelltwerden kann.Die zur Erstellung einer Signatur angewendeten privaten SchlüsselMÜSSEN durch einen signaturgesetzkonformen Zertifizierungsdienstanbietererstellt werden.AnhangB 4.4.3AnhangB 4.4.3AnhangB 4.4.3AnhangB 4.4.3AnhangB 4.4.3AnhangB 4.4.3AnhangB 4.4.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 279 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.4.4 – SMCAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02739 S Sec_SmartCards_SMC_01:Freischaltung der SMC-B.Die SMC-B MUSS mittels einer PIN oder einem vorher frei geschaltetenHBA frei geschaltet werden.AnhangB 4.4.4A_02740 S Sec_SmartCards_SMC_02:Sperrung der SMC-B nachFehleingabe der PIN.A_02741 S Sec_SmartCards_SMC_03:Freischaltung der SMC-B mittelsPUK.A_02742 S Sec_SmartCards_SMC_04:Erneute Freischaltung mittelsPIN.Nach einer dreimaligen Fehleingabe der PIN MUSS die SMC-Bglobal (d. h. keine Funktion der SMC kann mehr ausgeführt werden)gesperrt werden.Eine gesperrte SMC-B MUSS für eine definierte Anzahl von Anwendungenmittels einer PUK freigeschaltet werden können.Nach der korrekten Eingabe der PUK MUSS die Freischaltung derSMC-B mittels der PIN wieder möglich sein.AnhangB 4.4.4AnhangB 4.4.4AnhangB 4.4.4B4.5 - PKI und ZertifikateB4.5.1 – AllgemeinAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02744 S Sec_PKI_Zertifikate_Allg_01:Nichtauslesbarkeit von technischenInformationsobjektenTechnische Informationsobjekte (wie private Schlüssel), die in dervirtuellen Welt als einziges Merkmal zur Herstellung von Authentizitätund Nichtabstreitbarkeit herangezogen werden (können), DÜR-AnhangB 4.5.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 280 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellezur Authentisierung.A_02745 S Sec_PKI_Zertifikate_Allg_02:Schutz von technischen Informationsobjektendurch Authentifikationsverfahren,.A_02746 S Sec_PKI_Zertifikate_Allg_03:Zuordnung vom Schlüssel zurerzeugenden Stelle.A_02747 S Sec_PKI_Zertifikate_Allg_04:Robustheit der Trägermedien.A_02748 S Sec_PKI_Zertifikate_Allg_05:Unveränderbarkeit des dezentralenSpeicherortes.A_02749 S Sec_PKI_Zertifikate_Allg_06:Invalidierung privater Schlüssel.A_02750 S Sec_PKI_Zertifikate_Allg_07:Nachvollziehbarkeit von Entstehungund Sperrung.A_02751 S Sec_PKI_Zertifikate_Allg_08:Verfügbarkeit der öffentlichenSchlüssel.A_02752 S Sec_PKI_Zertifikate_Allg_09:Nichtveränderbarkeit der öf-FEN NICHT durch Auslesen der eGK auf andere elektronischeMedien übertragbar sein.Die Nutzung technischer Informationsobjekte, die als einzigesMerkmal zur Herstellung von Authentizität und Nichtabstreitbarkeitherangezogen werden, MUSS durch ein Authentifikationsverfahren,das einen eindeutigen Bezug zum der eGK zugeordneten Versichertenzulässt, geschützt werden.Der Entstehungsprozess eines konkreten privaten Schlüssels inder Telematikinfrastruktur MUSS einer erzeugenden Stelle zuordenbarsein.Es MUSS sichergestellt sein, dass die privaten und öffentlichenSchlüssel sowie Zertifikate auf einem Medium gespeichert sind,das ausreichend robust ist, um mindestens für deren erforderlicheund erlaubte Nutzungsdauer einsetzbar zu sein.Der dezentrale Speicherort privater Schlüssel (in der Regel in derKarte) DARF nach der initialen Aufbringung der privaten SchlüsselNICHT mehr veränderbar sein.Es MUSS möglich sein einen privaten Schlüssel zu jedem beliebigenZeitpunkt nach dessen Erzeugung für ungültig zu erklären undfür sämtliche mit ihm ermöglichten Funktionalitäten zu sperren;falls dies nicht möglich ist, MUSS dargestellt werden, dass die Sicherheitdurch die Nicht-Umsetzung nicht beeinträchtigt wirdDer Entstehungs- und Sperrprozess eines konkreten öffentlichenSchlüssels MUSS lückenlos einer verantwortlichen Stelle zuordenbarund nachvollziehbar sein.Die öffentlichen Schlüssel MÜSSEN zentral derart verfügbar gemachtwerden, dass über den gesamten Lebenszyklus aller miteinem korrespondierenden privaten Schlüssel signierten Informationsobjekteauf deren Authentizität geprüft werden können.Ein öffentlicher Schlüssel DARF am zentralen Speicherort NICHTmehr verändert werden.AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 281 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellefentlichen Schlüssel.A_02753 S Sec_PKI_Zertifikate_Allg_10:Beachtung allgemein gültigenIT Sicherheitsrichtlinien.A_02754 S Sec_PKI_Zertifikate_Allg_11:Nutzung gehärteter Betriebssysteme.A_02755 S Sec_PKI_Zertifikate_Allg_12:Einsatz geeigneter Algorithmenund Parameter.A_02756 S Sec_PKI_Zertifikate_Allg_13:Autausch von Algorithmen undParametern.A_02757 S Sec_PKI_Zertifikate_Allg_14:Jährliche Überprüfung derAlgorithmen.A_02758 S Sec_PKI_Zertifikate_Allg_15:Verhinderung der Nutzung vonnicht mehr freigegebenen Algorithmenund ParameternA_02759 S Sec_PKI_Zertifikate_Allg_16:Migration von Algorithmen undParametern.A_02760 S Sec_PKI_Zertifikate_Allg_17:Nachsignierung und Neuverschlüsselung.Alle IT Komponenten der PKI MÜSSEN den Sicherheitsanforderungender allgemein gültigen IT Sicherheitsrichtlinien (z. B. TKG)unterliegen.Für alle PKI relevanten Anwendungen innerhalb des TSP MÜS-SEN gehärtete Betriebssysteme eingesetzt werden. Darüber hinausMÜSSEN folgende Sicherheitsmaßnahmen umgesetzt werden:o Zugriffskontrolleo BenutzerauthentifizierungFür kryptographische Operationen in der TelematikinfrastrukturMÜSSEN stets nach dem Stand der Wissenschaft und Technikgeeignete Algorithmen und Parameter eingesetzt werden, welcheim Kryptografiekonzept der gematik festgelegt sindDie Hard- und Softwarearchitektur MUSS den Austausch kryptographischerAlgorithmen und Parameter ermöglichenDie Liste der geeigneten Algorithmen MUSS mindestens einmaljährlich und bei Bedarf (z. B. bei neuen wissenschaftlichen Erkenntnissen)überprüft werden.Die Kommunikations-Protokolle bzw. SicherheitskomponentenMÜSSEN so gestaltet sein, dass ein Erzwingen des Einsatzes vonAlgorithmen oder Parametern, deren Sicherheitseignung nichtmehr gegeben ist, nicht möglich ist.Während einer im Anlassfall zu definierenden ÜbergangsphaseMÜSSEN sowohl neue als auch alte Algorithmen und Parameterverarbeitet werden können.Es MUSS sichergestellt sein, dass die Integrität, Vertraulichkeitund Nicht-Abstreitbarkeit durch geeignete Verfahren gewährleistetsind, auch wenn die Lebensdauer kryptographisch behandelterDaten die Dauer der Sicherheitseignung der eingesetzten Algo-AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 282 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02761 S Sec_PKI_Zertifikate_Allg_18:Unterstützung kryptographischunabhängiger Algorithmen.A_02762 S Sec_PKI_Zertifikate_Allg_19:Integritätsprüfung der Sperrliste.A_02763 S Sec_PKI_Zertifikate_Allg_20:Verhalten bei nichtverfügbaren/nichtintegren Sperrlisten.A_02764 S Sec_PKI_Zertifikate_Allg_21:Verhinderung von denial-ofserviceAngriffen.A_02765 S Sec_PKI_Zertifikate_Allg_22:Sperrprüfung während desgesamten lifecycle.A_02766 S Sec_PKI_Zertifikate_Allg_23:Protokollierung von Sperrinformationen.A_02767 S Sec_PKI_Zertifikate_Allg_24:Nachvollziehbarkeit von Sperrinformationen.A_02768 S Sec_PKI_Zertifikate_Allg_25:Identifikation des Sperrenden.A_02769 S Sec_PKI_Zertifikate_Allg_26:Schutz von PIN und PUK währenddes gesamten lifecyle.rithmen und Parameter übersteigt, z. B. durch eine erneute Nachsignaturbzw. Verschlüsselung.Alle Sicherheitskomponenten SOLLEN für jedes kryptographischePrimitiv stets mindestens zwei kryptographische Algorithmen unterstützen,die kryptographisch hinreichend unabhängig sind.Dem Anwender einer Sperrliste MUSS zum Zeitpunkt der Nutzungeine Prüfung der Integrität der Sperrliste möglich sein.Eine nicht verfügbare Sperrliste (identisch mit einer nicht integerenSperrliste) DARF NICHT dazu führen, dass automatisch alle voneiner Sperrliste potentiell adressierten Objekte als gesperrt gelten.Sperrlisten MÜSSEN technisch derart bereitgestellt werden, dassein böswilliges Verhindern ihres Abrufs verhindert wird.Für jeden Zeitpunkt innerhalb des Lebenszyklus eines von einerSperrliste potentiell adressierbaren Objekts MUSS bestimmbarsein, ob dieses Objekt gesperrt gewesen ist.Jede Änderungen von Sperrinformationen MUSS revisionsfähigprotokolliert werden.Jede Sperrinformation MUSS im Rahmen der technischen Möglichkeiteneindeutig auf die ändernde Person rückführbar sein.Der Ersteller einer Sperrinformation muss im Rahmen der technischenMöglichkeit (z. B. mittels kryptographischer Methoden) derarteindeutig bestimmbar sein, dass eine Änderung durch eine anderePerson als höchst unwahrscheinlich gelten kann.PINs und PUKs MÜSSEN entsprechend des Schutzbedarfs währenddes gesamten Lebenszyklus (Erzeugung, Speicherung, Verteilung,Verwendung, Löschung) geschützt werden.AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 283 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02770 S Sec_PKI_Zertifikate_Allg_27:Zugriffsschutz für chützenswerteund PIN-geschützte Datendes Karteninhabers.A_02771 S Sec_PKI_Zertifikate_Allg_28:Es muß sichergestellt werden,daß die PIN nur dem Karteninhaberbekannt ist.A_02772 S Sec_PKI_Zertifikate_Allg_29:Sperrung und Entsperrung vonPIN.A_02773 S Sec_PKI_Zertifikate_Allg_30:Schutz von Integrität und Verteulichkeitder PIN bei der PIN-Verteilung.A_02774 S Sec_PKI_Zertifikate_Allg_31:Keine Speicherung der PINaußerhalb der Karte.A_02775 S Sec_PKI_Zertifikate_Allg_32:Verhinderung einer Kompromittierungder Root-CA.Der Zugriff auf schützenswerte und PIN-geschützte Daten des Karteninhabersdurch Unberechtigte MUSS verhindert werden.Es MUSS durch technische und organisatorische Maßnahmensichergestellt werden, dass die für den Zugriff auf schützenswerteund PIN-geschützte Daten verwendete PIN nur dem Karteninhaberbekannt ist. Die Maßnahmenstärke dieser technischen und organisatorischenSicherheitsmaßnahmen ist für PINs und PUKs sehrhoch.Die durch PIN geschützten Funktionen MÜSSEN gesperrt bleiben,wenn die PIN drei Mal hintereinander falsch eingegeben wurde.Eine weitere Eingabe der PIN DARF dann NICHT mehr möglichsein. Durch die zugehörende PUK MUSS die Sperrung wieder aufgehobenwerden können, wobei die PUK insgesamt maximal 10Mal richtig/falsch eingegeben werden darf. Die PIN MUSS dabeiauf einen neuen Wert gesetzt werden könnenWährend der PIN-Verteilung DARF die PIN NICHT abgehört oderunbemerkt manipuliert werden können. Außerdem MUSS sichergestelltwerden, dass die PIN nicht von Unbefugten dem zugehörigenVersicherten zugeordnet werden kann. Eine unberechtigteZwischenspeicherung und unberechtigte nachträgliche Verwendungauch der verschlüsselten PIN (u. a. Ausdruck eines zweitenPIN-Briefs für anderen Adressaten) MUSS verhindert werden.Es MUSS sichergestellt sein, dass bei der Eingabe durch den Versicherteneine Speicherung der PIN außerhalb der Karte (z. B. ineinem Terminal) nicht erfolgen kann.Eine Kompromittierung der Root-CA einer Karten-PKI könnte dazuführen, dass das Zertifikat der CA für nicht vertrauenswürdig erklärtwird und damit alle abhängigen Karten neu ausgerollt werdenmüssen. Daher MUSS die Kompromittierung einer Root-CA einerAnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 284 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02776 AS-ZuN-8130STitel Beschreibung Rel. QuelleSec_PKI_Zertifikate_Allg_33:Redundanz der Server.A_02777 S Sec_PKI_Zertifikate_Allg_34:Auschluß einer gefälschten/kopiertenPKI.A_02081A_02081SSec_PKI_Zertifikate_Allg_35:Kein externer Zugriff.Karten-PKI verhindert werden.Die Server für PKI Systeme SOLLEN redundant in zwei Brandabschnittenaufgestellt sein.Das Betreiben einer gefälschten/kopierten PKI MUSS innerhalb derTelematikinfrastruktur geeignet unterbunden werden.Externer Zugriff auf PKI der eGKEin externer Zugriff auf die PKI der eGK Schlüssel DARF NICHTerfolgen.Für die Schlüssel, die der Regelungshoheit der gematik unterliegen,DARF NICHT von Anwendungen außerhalb der Telematikinfrastrukturauf die PKI zugegriffen werden.(Zusätzlich kann der Kartenherausgeber für eigene Anwendungenden Zugriff auf die eigene PKI der Authentisierungsschlüssel nutzen.PKI-Dienste wie Zertifikatsstatusabfragen (z.B. ocsp), Directoryzugriffe(z.B. ldap, …) sind durch technische Maßnahmen gegenexterne Zugriffe zu schützen.Die Nutzung einer optionalen PKI füreine qualifizierten Signatur auf der eGK wird durch diese Entscheidungnicht beeinflusst. Alle anderen PKI der eGK unterliegen dieserAnforderung. Eine Mehrwertanwendung, die Dienste der TInutzen darf, ist für diese Anforderung wie eine Anwendung derTelematikinfrastruktur zu betrachten und der Zugriff MUSS ermöglichtwerden.)AnhangB 4.5.1AnhangB 4.5.1AnhangB 4.5.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 285 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.5.2 - X.509 ZertifikateAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02778 S Sec_PKI_X.509_Zertifikate_01: Betrieb gemäß SigG fürHBAA_02779 S Sec_PKI_X.509_Zertifikate_02: Betrieb gemäß SigG füreGKA_02780 S Sec_PKI_X.509_Zertifikate_03: Vernichtung von Schlüsselnund Trägermedium.Da der HBA qualifizierte elektronische Signaturen durchführenkönnen muss, MUSS der Betrieb einer PKI nach X.509 zur Ausstellungvon Schlüsseln und Zertifikaten für eine qualifizierte elektronischeSignatur entsprechend den Anforderungen des Signaturgesetzeserfolgen.Da die eGK die Fähigkeit zur qualifizierten elektronischen Signaturtechnisch haben muss und die erforderlichen Zertifikate nachladenkann, MUSS der Betrieb einer PKI nach X.509 zur Ausstellung vonSchlüsseln und Zertifikaten für eine qualifizierte elektronische Signaturentsprechend den Anforderungen des Signaturgesetzes erfolgen.Nicht mehr gültige private X.509-Schlüssel MÜSSEN dauerhaftund nachweislich vom weiteren Gebrauch ausgeschlossen werden(z. B. durch dokumentierte Vernichtung des Trägermediums). 23AnhangB 4.5.2AnhangB 4.5.2AnhangB 4.5.2B4.5.3 - CV ZertifikateAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02781 S Sec_PKI_CV_Zertifikate_01:PKI für CV_Zertifikate.A_02782 S Sec_PKI_CV_Zertifikate_02:Nachvollziehbarkeit desEntstehungs- und SperrprozessesEs MUSS für HBA und eGK eine PKI für CV-Zertifikate betriebenwerden.Der Entstehungs- und Sperrprozess eines konkreten CV-ZertifikatsMUSS lückenlos einer verantwortlichen Stelle zuordenbar undnachvollziehbar sein.AnhangB 4.5.3AnhangB 4.5.323 Diese Anforderung wird in einer Folgeversion noch detailliert. Die Anforderung wird sich daher noch ändern.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 286 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02783 S Sec_PKI_CV_Zertifikate_03:Unveränderlichkeit des CV-Zertifikats.A_02784 S Sec_PKI_CV_Zertifikate_04:Unveränderbarkeit des dezentralenSpeicherortesA_02785 S Sec_PKI_CV_Zertifikate_05:Verhinderung der Nutzungungültiger Schlüssel.A_02786 S Sec_PKI_CV_Zertifikate_06:Generierung eines Zertifikatesnur auf Antrag eines Berechtigten.A_02787 S Sec_PKI_CV_Zertifikate_07:Produktion einer Chipkarte nurauf Antrag eines berechtigtenKartenherausgebers.A_02788 S Sec_PKI_CV_Zertifikate_08:Zuordnung zum codiertenZugriffsprofil.A_02789 S Sec_PKI_CV_Zertifikate_09:Codierung der ICSSN.A_02790 S Sec_PKI_CV_Zertifikate_10:Zuordnung privater Schlüsselzu CV-Zertifikat/öffentlichemSchlüssel.A_02791 S Sec_PKI_CV_Zertifikate_11:Korrekter öffentlicher Schlüsselder relevanten Root-CVC_CA.Ein CV-Zertifikat DARF am zentralen Speicherort NICHT mehrverändert werden.Der dezentrale Speicherort privater Schlüssel DARF nach der initialenAufbringung der CV-Zertifikate NICHT mehr veränderbar sein.Nicht mehr gültige private CVC-Schlüssel MÜSSEN dauerhaft undnachweislich vom weiteren Gebrauch ausgeschlossen werden.Vor dem Generieren eines CV-Zertifikates MUSS sichergestelltsein, dass die Generierung auf Antrag eines hierfür Berechtigtenerfolgt.Vor der Produktion einer Chipkarte mit zugehörigem CV-ZertifikatMUSS sichergestellt sein, dass die Produktion nur im Auftrag einesberechtigten Kartenherausgebers erfolgt.Es MUSS sichergestellt sein, dass in dem CV-Zertifikat einer Chipkartenur ein für den Karteninhaber der Chipkarte zugelassenesZugriffprofil kodiert ist.In dem CV-Zertifikat einer Chipkarte MUSS die korrekte ICCSN derChipkarte kodiert sein.Nach Produktion MUSS in der Chipkarte der private Schlüssel enthaltensein, der zu dem durch das enthaltene CV-Zertifikat zertifiziertenöffentlichen Schlüssel gehört.In die Chipkarte MUSS der korrekte aktuelle öffentliche Schlüsselder relevanten Root-CVC-CA eingebracht werden.AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 287 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02792 S Sec_PKI_CV_Zertifikate_12:Korrektes CA-CV-Zertifikat.A_02793 S Sec_PKI_CV_Zertifikate_13:Invalidierung des Sub-)CVC-CA Schlüsselpaars.A_02794 S Sec_PKI_CV_Zertifikate_14:Authentizität des öffentlichenSchlüssels bei Beantragungund Generierung.A_02795 S Sec_PKI_CV_Zertifikate_15:Revisionsfähige Protokollierung.In die Chipkarte MUSS das korrekte CA-CV-Zertifikat der CVC-CAeingebracht werden, die das enthaltene CV-Zertifikat erzeugt hat.Das (Sub-)CVC-CA Schlüsselpaar MUSS seine Gültigkeit verlieren,falls für seine Aufgaben ein neues Schlüsselpaar generiertwurde oder falls die Registrierung der CVC-CA durch die gematikwiderrufen wurde. In diesem Fall MUSS das Schlüsselpaar vernichtetwerden. Dies MUSS durch eine der folgenden Maßnahmenrealisiert werden:o Physikalisches Zerstören des HSM (ggf. aller Klone), in dem derprivate Schlüssel gespeichert ist. Diese Maßnahme MUSS zwingenderfolgen, falls das HSM keine der beiden folgenden Möglichkeitenunterstützt.o Physikalisches Löschen des privaten Schlüssels innerhalb desHSM (ggf. innerhalb aller Klone), falls das HSM diese Funktionalitätunterstützt.o Dauerhaftes Sperren aller möglichen Zugriffe auf den privatenSchlüssel innerhalb des HSM (ggf. innerhalb aller Klone), falls dasHSM diese Funktionalität unterstützt.Bei der Beantragung und Generierung des CA-CV-ZertifikatesMUSS die Authentizität des öffentlichen Schlüssels sichergestelltwerden.Die Arbeit der CVC-CA MUSS revisionsfähig protokolliert werden.Folgende Ereignisse MÜSSEN dabei mindestens protokolliert werden:o Generierung eines neuen Schlüsselpaares im HSM,o Löschung eines privaten Schlüssels im HSM,o Export des privaten Schlüssels,o Import des privaten Schlüssels,o Sperrung der Zugriffe auf einen privaten Schlüssel im HSM,o Erzeugen eines CV-Zertifikats mit einem Profil ungleich 0,AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 288 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02796 S Sec_PKI_CV_Zertifikate_16:Umfang der revisionsfähigenProtokollierung.A_02797 S Sec_PKI_CV_Zertifikate_17:Umfang der revisionsfähigenProtokollierung Profil_ungleich_NullA_02798 S Sec_PKI_CV_Zertifikate_18:Umfang der revisionsfähigenProtokollierung Profil_gleich_NullA_02799 S Sec_PKI_CV_Zertifikate_19:Protokollierung pro Produktionslauf.A_02800 S Sec_PKI_CV_Zertifikate_20:Schutz der Protokolldaten vorManipulation.A_02801 S Sec_PKI_CV_Zertifikate_21:Einsicht in Protokolldaten.A_02802 S Sec_PKI_CV_Zertifikate_22:Organisationskonzept und Rol-o Erzeugen einer Menge von CV-Zertifikaten mit Profil 0Bei jedem Ereignis, welches durch eine CVC-CA revisionsfähigprotokolliert werden muss, MÜSSEN die folgenden Werte protokolliertwerden:o Datum und Uhrzeit,o Typ des Ereignisses,o Namen der beiden Mitarbeiter der CVC-CA, die das HSM freigeschaltethaben.Beim Erzeugen eines CV-Zertifikates mit einem Profil ungleich 0MÜSSEN zusätzlich die folgenden Werte protokolliert werden:o Name des zuständigen Kartenherausgebers,o Inhalt der Felder CHR und CHA,o das erstellte CV-Zertifikat selberBeim Erzeugen eines CV-Zertifikates mit einem Profil gleich 0MÜSSEN zusätzlich die folgenden Werte protokolliert werden:o Name des zuständigen Kartenherausgebers,o Anzahl der erzeugten CV-ZertifikateDie Protokollierung bei dem Erzeugen von CV-Zertifikaten mit Profilgleich 0 SOLL pro Bestellung/Produktionslauf geschehen. EsMUSS dabei nachträglich anhand der Protokolle nachvollzogenwerden können, wann wie viele CV-Zertifikate mit einem Profilgleich 0 für wen erzeugt wurden.Alle Protokolldaten MÜSSEN bei ihrer Erstellung, Verarbeitung undSpeicherung gegen mögliche Manipulationen geeignet geschütztwerden.Auf Antrag MUSS Vertretern der gematik Einblick in die Protokollegewährt werden. Die Protokolldaten MÜSSEN dazu in einfacherverständlicher Form interpretierbar sein.Die CVC-CA MUSS in ihrem Organisationskonzept (als Teil desSicherheitskonzepts) mindestens die folgenden Rollen unterschei-AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 289 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellelen.A_02803 S Sec_PKI_CV_Zertifikate_23:Physische Lokation.A_02804 S Sec_PKI_CV_Zertifikate_24:Betrieb innerhalb der EuropäischenUnion.A_02805 S Sec_PKI_CV_Zertifikate_25:CA-Hierarchie im Wirkbetrieb.A_02806 S Sec_PKI_CV_Zertifikate_26:Flache CA-Hierarchie.A_02807 S Sec_PKI_CV_Zertifikate_27:Genehmigung durchden:o Leiter CVC-CA,o Sicherheitsbeauftragter CVC-CA,o Antragsteller CA-CV-Zertifikat,o Zertifizierer.Das die CVC-CA realisierende Kernsystem (insbesondere dasHSM) MUSS in einem geschützten Bereich der Betriebsstätte untergebrachtsein. Für diesen Bereich MUSS gelten:o Falls zur CVC-CA gehörende Arbeitsplatz-Rechner oder Systemeaußerhalb des geschützten Bereichs Zugriffe auf das Kernsystemin dem geschützten Bereich haben, MÜSSEN alle Zugriffeüber diese Arbeitsplatz-Rechner bzw. Systeme auf das Kernsystemsowie die Kommunikation zwischen den Arbeitsplatz-Rechnern, den Systemen und dem Kernsystem gegen Manipulationenund unautorisierte Nutzung geeignet geschützt werden.o Ist die CVC-CA in ein Netzwerk eingebunden, MUSS sichergestelltwerden, dass über das Netzwerk nicht auf die CVC-CA zugegriffenwerden kann und dass keine Informationen der CVC-CAüber das Netzwerk weitergegeben werden können.Alle zu der CVC-CA gehörenden Systeme MÜSSEN in Betriebsstättenbetrieben werden, die konkret in einem Land der EuropäischenUnion liegen.Es wird im Regelbetrieb eine PKI mit einer CA-Hierarchie realisiert,d.h. es gibt untergeordnete CAs (im Folgenden immer nur CA genannt),die die Karten für den Wirkbetrieb ausgeben (eGK, HBA,SMC). Es MUSS sichergestellt sein, dass nur die Karten für denWirkbetrieb mit medizinischen Echt-Daten in Kontakt kommen.Es SOLL eine flache CA-Hierarchie eingesetzt werden.Alle CAs MÜSSEN von der Telematikinfrastruktur genehmigt werden.AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3AnhangB 4.5.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 290 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleTI/gematik.B4.5.4 - Private Schlüssel in HSMsAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02808 S Sec_PKI_Private_Schlüssel_HSM_01: Klon-Erlaubnis fürHSMs.Falls notwendig KANN aus Gründen der Hochverfügbarkeit bzw.hoher Performanzanforderungen (Möglichkeit zur Lastverteilung)ein HSM "geklont" werden, indem der private Schlüssel aus demHSM (kryptographisch abgesichert) exportiert und in ein weiteresHSM importiert wird. Dabei MÜSSEN die folgenden Punkte berücksichtigtwerden:o Falls das Klonen eines HSM technisch möglich ist, MUSS derVorgang in dem Sicherheitskonzept gesondert beschrieben und indem Sicherheitsgutachten gesondert bewertet werden. DabeiMÜSSEN insbesondere die Maßnahmen für die Gewährleistungder Sicherheit des privaten Schlüssels als auch die (technischenund/oder organisatorischen) Maßnahmen für die Verhinderung desunautorisierten Erstellens von Klonen beschrieben (Sicherheitskonzept)und bewertet (Sicherheitsgutachten) werden.o Es MUSS sichergestellt sein, dass das Klonen eines HSM nurdurch zwei Mitarbeiter (Vier-Augen-Prinzip) möglich ist.o Das Klonen eines HSM MUSS protokolliert werden.o Zu jeder Zeit MUSS einfach nachvollziehbar sein, wie viele Klonedes HSM existieren.o Alle Klone eines HSM (d. h. alle HSM mit dem gleichen privatenSchlüssel) werden im Sinne dieses Dokuments logisch als einHSM betrachtet, d.h. alle Anforderungen an ein HSM gelten fürAnhangB 4.5.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 291 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02809 S Sec_PKI_Private_Schlüssel_HSM_02: Schlüsseloperationenim HSM nur nach Authentisierungin 4-Augen-Prinzip.jeden Klon.o Alle Klone eines HSM (d. h. alle HSM mit dem gleichen privatenSchlüssel) MÜSSEN in einem geschützten Bereich der Betriebsstätteeingesetzt werden.Es MUSS sichergestellt sein, dass folgende Funktionen des HSMnur nach einer Benutzerauthentikation zweier hierfür autorisierterNutzer (Vier-Augen-Prinzip) möglich ist:o Generieren eines neuen Schlüsselpaares,o Berechnung einer Signatur mit dem privaten Schlüssel,o (kryptographisch abgesicherter) Export des privaten Schlüssels,o (kryptographisch abgesicherter) Import eines privaten Schlüssels,o Löschen des privaten Schlüssels (falls dies durch das HSM unterstütztwird),o Sperren der Zugriffe auf den privaten Schlüssel (falls dies durchdas HSM unterstützt wird)AnhangB 4.5.4B4.6 - Dienste und NetzeB4.6.1 - Verzeichnisdienst/NameserverAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02810 S Sec_Verzeichnisdienst_01:Split-Horizon Konfiguration fürden Nameservers.A_02811 S Sec_Verzeichnisdienst_02:Verhinderung unautorisierterEs MUSS eine Split-Horizon Konfiguration für den Nameserververwendet werden.Unkontrollierte und unautorisierte Zonetransfers MÜSSEN unterbundenwerden. Die Authentizität und Integrität MUSS beim Trans-AnhangB 4.6.1AnhangB 4.6.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 292 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleZonentransfers.A_02812 S Sec_Verzeichnisdienst_03:Nutzung transaktionssichererZonentransfers.A_02813 S Sec_Verzeichnisdienst_04:Monitoring und Alerting.A_02814 S Sec_Verzeichnisdienst_05:Einrichten von IP-Filtern.A_02815 S Sec_Verzeichnisdienst_06:Authentizität und Integrität derNameserver.A_02816A_02817AS-ND-8100AS-ND-5100SSSec_Verzeichnisdienst_07:Nutzung eines speziell für Nameservergehärteten Betriebssystems.Sec_Verzeichnisdienst_08:Administration der Nameserver-Instanz.A_02818 S Sec_Verzeichnisdienst_09:Robuste Implementierung mitMißbrauchsschutz.port von Zonefiles sichergestellt sein.Es MÜSSEN transaktionssichere Zonentransfers verwendet werden.Es MUSS ein Monitoring der DNS-Abfragen und ein Alerting beiÜberschreiten eines definierten Schwellwertes erfolgen.Es MÜSSEN IP-Netze festgelegt werden, die interne DNS-Serverabfragen dürfen. Es MUSS eine Einschränkung auf Zones durchgeführtwerden.Die Authentizität und Integrität der Nameserver MUSS sichergestelltsein.Der Nameserver MUSS auf einem für den spezifischen Einsatzzweckgehärtetem Betriebssystem betrieben werden.Die Möglichkeit der Online-Administration der Name-Server-InstanzSOLL auf das lokale System beschränkt werden.Der Domain Name Service wird aufgrund seiner zentralen Funktionfür die Identifikation von Zielsystemen als sicherheitskritisch undrisikobehaftet eingestuft. Für Design und Betrieb des DienstesMÜSSEN deshalb Mechanismen vorgesehen werden, die eine robusteImplementierung gewährleisten und die die folgenden Sicherheitsanforderungenerfüllen:o Organisatorische und betriebliche Maßnahmen zum Schutz gegenunbefugten physikalischen Zugriff auf die Name Server HostsystemeMÜSSEN festgelegt und eingehalten werden.o Es MUSS ein Schutz vor Übernahme des jeweiligen NameserverHostsystems durch unberechtigte Dritte festgelegt und eingehaltenwerden.AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 293 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02819 S Sec_Verzeichnisdienst_10:Authentizitäts- und Integritätsprüfung.A_02820AS-ND-6100SSec_Verzeichnisdienst_11:Sicherung des Transaktionskanalszu Servern des Namensdienstes.A_02821 S Sec_Verzeichnisdienst_12:Sicherung des Transaktionskanalszu Server Dritter.A_02822AS-ND-6110SSec_Verzeichnisdienst_13:Schutzmaßnahmen_UDDI Registry.o Es MUSS sichergestellt sein, dass es keine (uneingeschränkte)Nutzung des Dienstes durch unberechtigte Dritte gibt.o Die Sicherheit der Transaktionskanäle zwischen assoziierten NameServer Instanzen MUSS sichergestellt sein.Es MUSS eine Authentizitäts- und Integritätsprüfung der vom Dienstzur Verfügung gestellten Daten zur Vermeidung von inhaltlichenManipulationen (Cache Poisoning durch Data Spoofing, usw.) erfolgen.Der Transaktionskanal zwischen den Bastion Host Name Servernund beliebigen Name Servern des Namensdienstes MUSS gesichertwerden (Authentizität, Integrität), sofern die Bastion Host ServerInstanz nach außen als (Fake) Primary Master auftritt, tatsächlichaber die Zonendaten von dem Name Server des Namensdienstesbezieht.Der Transaktionskanal zwischen Bastion Host Name Servern desNamensdienstes und Name Servern Dritter SOLL gesichert werden(Authentizität, Integrität).Der Dienstanbieter MUSS sich darauf einstellen, dass die gematikin Zukunft ein Dokument erstellt und pflegt, mit welchen Dritten derTransaktionskanal zwischen Bastion Host Name Servern des Namensdienstesund Name Servern Dritter gesichert werden muss.Ein solcher Dritter könnte z. B. ein Internet Service Provider sein.Die gematik wird hierbei die Kooperationsverhandlungen mit demDritten führen, während das Key Management durch den Dienstanbieterdurchzuführen ist.Folgende Anforderungen bei der Auswahl eines UDDI RegistryProdukts MÜSSEN berücksichtigt werden:o Benutzerauthentisierung (auf Nachrichtenebene) erfolgt zertifikatsbasiert.o Granulare Benutzerautorisierungsmechanismen sind vorhanden(z. B. ACLs. o. ä.)AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 294 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo ArtA_02823A_02824Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAS-SDS-5100AS-SDS-5110SSTitel Beschreibung Rel. QuelleSec_Verzeichnisdienst_14:SSL/TLS-Verschlüsselung mitbeidseitiger Authentisierung.Sec_Verzeichnisdienst_15:Kummunikationsrestriktion aufdie Zonen 3.4 und 3.A_02825 S Sec_Verzeichnisdienst_16:Registrierung eines Fach- bzw.Infrastrukturdienstes.A_02826A_02827o Verschlüsselung von Netzwerkverbindungen auf Basis vonSSL/TLS ist möglich.o Client Authentisierung (auf Verbindungsebene) im Rahmen desSSL/TLS Handshakes ist möglich.o Der Namensdienst MUSS auf einem für den spezifischenEinsatzzweck gehärtetem Betriebssystem betrieben werden.Der Registrierungsdienst verfügt über Schlüsselpaare und Zertifikatezur sicheren Kommunikation (TLS/SSL) mit den Kommunikationspartnern.Bei Einsatz dieser Zertifikate MÜSSEN die übertragenen Datenmittels SSL/TLS und beiderseitiger Authentifizierung über ClientundServer-Zertifikate geschützt werden.Dies gilt insbesondere für die Kommunikation zwischen Broker Serviceund Registrierungsdienst sowie für die Kommunikation zwischengematik und Registrierungsdienst.Der Registrierungsdienst DARF nur mit den Zonen 3 und 2.4 kommunizieren.AS-SDS-6100AS-SDSSSSec_Verzeichnisdienst_17:Dokumentenprüfung vor Registrierung.Sec_Verzeichnisdienst_18:Zugriff nur durch autorisierteEs MUSS sichergestellt werden, dass eine Registrierung einesFach- bzw. Infrastrukturdienstes nach erfolgreicher Akkreditierungbzw. eine Löschung einer bereits erfolgten Registrierung nur durcheinen hierzu befugten Systemadministrator des DienstanbietersRegistrierungsdienst oder durch einen hierzu befugten Mitarbeiterder gematik vorgenommen werden kann.Die zur Registrierung bzw. zum Anlegen der Benutzerkonten erforderlichenDokumente MÜSSEN vor der Registrierung gemäß denVorgaben der gematik geprüft werden. Dieser Vorgang MUSS protokolliertwerden.Es MUSS sichergestellt sein, dass der Zugriff (lesen, schreiben,ändern, löschen) auf die Registrierungsdaten nur durch hierzu spe-AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 295 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo ArtA_02828A_02829A_02830A_02831A_02832A_02833A_02834Übergreifendes Sicherheitskonzept der Telematikinfrastruktur-6110AS-SDS-6120AS-SDS-6130AS-SDS-6140AS-SDS-6150AS-SDS-6160AS-SDS-6170AS-SDS-6180SSSSSSSTitel Beschreibung Rel. QuellePersonen.Sec_Verzeichnisdienst_19:Überprüfung der Akkreditierung.Sec_Verzeichnisdienst_20:Kanonische Dienstnamen.Sec_Verzeichnisdienst_21:Programmgestüzte Registrierung.Sec_Verzeichnisdienst_22:Aufruf der Publishing API nurnach Authorisierung.Sec_Verzeichnisdienst_23:User-ID&Passwort-basierteAuthentisierung nur für SystemadministratorendesDienstbetreibers erlaubt.Sec_Verzeichnisdienst_24:Authentisierung von Systemadministratorendes Dienstbetreibers.Sec_Verzeichnisdienst_25:Verwendung von Zertifikatenzur Authentisierung.ziell autorisierte Personen erfolgen kann.Die Akkreditierung MUSS vor der Registrierung überprüft werden.EsMUSS sichergestellt sein, dass nur akkreditierte Dienstbetreiberund Dienste beim Registrierungsdienst registriert werden.Die Dienste MÜSSEN über kanonische Dienstnamen (A-Records)identifizierbar sein.Um Anwendungsfehler zu vermeiden und/oder eine einheitlicheVorgehensweise sicherzustellen, MUSS der Prozess zur Registrierungvon Telematik-Diensten in dem Registrierungsdienst programmgestützterfolgen.Es MUSS sichergestellt sein, dass der Aufruf der Publishing API nurnach einer Authentisierung mittels User-ID&Passwort bzw. mittelsZertifikaten gegenüber dem Registrierungsdienst möglich ist.Es MUSS sichergestellt sein, dass eine User-ID&Passwort-basierteAuthentisierung nur für die Systemadministratoren des Dienstbetreiberserfolgen kann. Alle anderen Parteien MÜSSEN eine zertifikatsbasierteAuthentisierung durchführen.Die Authentisierung von Systemadministratoren des DienstbetreibersSOLL auf Grundlage eines X.509-Zertifikats erfolgen.Bei Verwendung von Zertifikaten MUSSo der im Zertifikat angegebene Subject Distinguished Name (DN)auf ein entsprechendes UDDI-Benutzerkonto abgebildet werdenkönnen undAnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 296 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02835AS-SDS-6190STitel Beschreibung Rel. QuelleSec_Verzeichnisdienst_26:Verwendung von User-ID&Passwort zur Authentisierung.A_02836 S Sec_Verzeichnisdienst_27:Lokales Login mittels User-ID&Passwort.A_02837A_02838A_02839A_02840AS-SDS-6200AS-SDS-6210AS-SDS-7100AS-ND-8130SSSSSec_Verzeichnisdienst_28:Nutzung der UDDI Benutzerkontenzur Authentisierung.Sec_Verzeichnisdienst_29:Zugriffsbeschränkungen beiDatenspeicherung auf externenSystemen.Sec_Verzeichnisdienst_30:Rollenkonzept ist verpflichtend.Sec_Verzeichnisdienst_31:Abarbeitung rekursiver Anfragen.o seitens des Registrierungsdienstes die Gültigkeit des Benutzerzertifikatsverifiziert werden.Bei Verwendung von User-ID&Passwort MUSSo sich die User-ID auf ein entsprechendes UDDI-Benutzerkontoabbilden lassen undo das übergebene Passwort als gültig anerkannt werden.Es MUSS sichergestellt sein, dass ein Login mittels User-ID&Passwort nur lokal auf dem Host des Registrierungsdienstesoder dem lokalen Netz des Betreibers durchgeführt werden kann.Die Authentisierung MUSS sich auf die UDDI Benutzerkonten stützen,die vom Betreiber der UDDI Operator Site innerhalb der Telematikinfrastrukturangelegt und verwaltet werden.Werden Registrierungsdaten auf externen Systemen gespeichert,so MUSS der Zugriff (lesen schreiben, ändern, löschen) auf dieseDaten auf die hierfür befugten Personen beschränkt bleiben.Die Netzwerkverbindung zu solchen entfernten Systemen MUSSmittels Zertifikaten (SSL, TLS) geschützt werden.Der Dienstanbieter MUSS ein Rollenkonzept erstellen, in dem dieRollen, die damit verbundenen Berechtigungen und ggf. die Benutzerkontenbeschrieben werden.Mittels entsprechender Konfigurationsparameter ist server- (allowrecursion,allow-query) und client-seitig (nameserver) folgende Logikzu implementieren:(Internal) Root Name Server erlauben keine rekursiven Anfragen.Name Server innerhalb der Parent oder der Subdomains akzeptierenrekursive Anfragen nur von (Stub) Resolvern ihrer jeweiligenDomain (allow-recursion).Einzige Ausnahme von dieser Regel: Name Server, die ForwardZones Konfigurationen zur Auflösung von Namen und IP-AdressenAnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1AnhangB 4.6.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 297 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02841AS-ND-8140STitel Beschreibung Rel. QuelleSec_Verzeichnisdienst_32:Redundanz der Serversysteme.A_02842 S Sec_Verzeichnisdienst_33:Unterbinden von Zonentransfers.des Internet-Namespace bereitstellen, erlauben domainübergreifenderekursive Anfragen (allow-query), allerdings nur von einerdefinierten Menge von privilegierten (Proxy) Systemen.Nicht privilegierte (Stub) Resolver Clients stellen ihre (rekursiven)Anfragen ausschließlich an die Name Server (nameserver) ihrerjeweiligen Domain.Bastion Host Name Server Instanzen erlauben rekursive Anfragennur von Systemen der DMZ und von den T0 Forward Zones NameServern.Die Server für den Namensdienst MÜSSEN redundant in zweiBrandabschnitten aufgestellt sein.Da ein Angreifer mit Hilfe von DNS Zonetransfers und/oder DNSZonewalks umfangreiche Informationen über die Struktur von Netzwerkenerhalten kann, DÜRFEN Zonetransfers/Zonewalks für unberechtigteAnwender NICHT durchführbar sein.AnhangB 4.6.1AnhangB 4.6.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 298 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.6.2 - Zeitdienst/NTPAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02843 S Sec_Zeitdienst_01: Sicherstellender temporalen Ordnung.A_02844 S Sec_Zeitdienst_02: Schutz vorReplay-Angriffen.A_02845 S Sec_Zeitdienst_03: Schutz vorunbefugtem Zugriff.A_02846 S Sec_Zeitdienst_04: Schutz vorManipulation der Systemzeit.A_02847 S Sec_Zeitdienst_05: Sicherstellenkorrekter NTP-Antworten.A_02848 AS- S Sec_Zeitdienst_06: MaßnahmenZD-zur Abwehr von DoS und6100 DDoS-Angriffen.A_02849A_02850A_02851AS-ZD-6110AS-ZD-6150AS-ZD-6160SSSSec_Zeitdienst_07: Betriebsart:Client/Server.Sec_Zeitdienst_08: MindestanzahlServer ist 4.Sec_Zeitdienst_09: Schutz derZeitquelle vor Angriffen.Es MÜSSEN Mechanismen zur Ermittlung der temporalen Ordnungim Rahmen der technischen Betriebsführung z. B. zur Protokollierungund Auswertung technischer Ereignisse, beispielsweise umFehlermeldungen, die auf einen Angriff über das Netz hindeuten,richtig korrelieren zu können, eingesetzt werden.Die Zeitserver MÜSSEN Schutzmechanismen gegen Replay-Angriffe zur Vermeidung des „Zurückdrehens“ der Systemzeit bieten.Alle NTP Server MÜSSEN gegen unbefugten Zugang und Zugriffgesichert werden.Das Verändern der Systemzeit der gesamten Telematikinfrastrukturetwa zur Nutzung von Replay Attacken gegen Systeme der TelematikinfrastrukturMUSS unterbunden werden.Es MUSS sichergestellt sein, dass die Antworten auf NTP Anfragenkorrekt sind.Der Anbieter MUSS entsprechende Maßnahmen treffen, um NTP-DoS und NTP-DDoS Angriffe abzuwehren.Es MUSS sichergestellt sein, dass ausschließlich die Betriebsart„Client – Server“ zum Einsatz kommt.Es MÜSSEN mindestens vier Server für den NTP Dienst eingesetztwerden. Dies stellt die Mindestanforderung zur Erkennung vonTruechimer-, Falseticker- und Falsespeaker-Systemen dar.Es MUSS sichergestellt sein, dass die Zeitquelle für die Telematikinfrastrukturausreichend vor Angriffen geschützt ist.AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2Da die Verfügbarkeit des Zeitdienstes für die Sicherheit des Gesamtsystems eine besondere Rolle spielt, werden in diesem Kapitel einige be-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 299 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellesonders wichtige Sicherheitsanforderungen an die Verfügbarkeit gestellt. Dennoch sind die Verfügbarkeitsanforderungen Gegenstand der nichtfunktionalenAnforderungen.A_02852A_02853A_02854AS-ZD-7100AS-ZD-7110AS-ZD-7120SSSSec_Zeitdienst_10: Unterbringungin zwei unabhängigenRechenzentren.Sec_Zeitdienst_11: Unterbringungin unterschiedlichenBrandabschnitten.Sec_Zeitdienst_12: Zutrittsschutz.Die Systeme MÜSSEN in zwei unabhängigen Rechenzentren stehen,die eine zur Abwehr von Elementarschäden geeignete Entfernungvoneinander aufweisen. Hierdurch soll das SicherheitszielVerfügbarkeit garantiert werden, da der Ausfall eines Rechenzentrums,beispielsweise durch höhere Gewalt, nicht zum Ausfall derInfrastruktur führt.Innerhalb der Rechenzentren MÜSSEN die NTP-Systeme in verschiedenenBrandabschnitten stehen.Hierdurch wird verhindert, dass beispielsweise durch ein Feuer dieVerfügbarkeit des Rechenzentrums beeinträchtigt wird.Es MUSS sichergestellt sein, dass nur autorisiertes Personal Zutrittzu Rechenzentrumsräumen hat.AnhangB 4.6.2AnhangB 4.6.2AnhangB 4.6.2B4.6.3 - Netzwerksicherheit allgemeinAfo-ID Anfo ArtA_02855 AS-AI-10100STitel Beschreibung Rel. QuelleSec_Netzwerk_Allg_01: VerschlüsselungmedizinsicherAnwendungsdaten.A_02856 S Sec_Netzwerk_Allg_02: SichereAblage von Zugangskennungenund Passwörtern.Alle medizinischen Anwendungsdaten MÜSSEN bei den Infrastrukturdienstenund den Netzen (Zugangsnetz und Zentrales Netz)ausschließlich verschlüsselt vorliegen.Zugangskennungen und Passwörter MÜSSEN auf Systemen undKomponenten der Telematikinfrastruktur derart gespeichert werden,dass die Kennungen und Passwörter nicht auslesbar sind.AnhangB 4.6.3AnhangB 4.6.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 300 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02857 S Sec_Netzwerk_Allg_03: Nutzungund Weitergabe administrativerZugangskennungenund Passwörter.A_02858 S Sec_Netzwerk_Allg_04:Schutz vor Datenverlust.A_02859 S Sec_Netzwerk_Allg_05:Schutz vor Malware.A_02860 S Sec_Netzwerk_Allg_06: Policyfür den Einsatz von Anti-Malicious-Software.A_02861 S Sec_Netzwerk_Allg_07:Schutz vor Modifikation undLöschen von Auditaufzeichnungen.A_02862 S Sec_Netzwerk_Allg_08:Schutz vor Modifikation undLöschen von Logdaten durchunautorisierte Benutzer.A_02863 S Sec_Netzwerk_Allg_09:Schutz vor Verlust von Auditdaten.Dies kann beispielsweise dadurch erreicht werden, dass nur derHashwert einer Zugangskennung gespeichert wird, auf den derLogin Prozess dann referenziert, und nur autorisierte Benutzerdiese Informationen lesen dürfen.Es MUSS sichergestellt sein, dass administrative Zugangskennungenund Passwörter für Systeme, Dienste und Komponenten derTelematikinfrastruktur nur autorisierten Personen bekannt gegebenwerden. Diese Kennungen und Passwörter DÜRFEN NICHT anweitere Personen weitergegeben werden!Es MUSS verhindert werden, dass bei Komponenten und Systemender Telematikinfrastruktur ein Datenverlust aufgrund erschöpfterSpeicherkapazität eintritt. Dies kann etwa durch ein ContinuityManagement (z. B. nach ITIL) realisiert werden.Es MUSS ein Schutz vor Zerstörung oder Manipulation von Datenbeständendurch allgemeine (nicht individuell für einen konkretenAngriff auf die Telematikinfrastruktur entwickelte) Viren/Trojaner/Würmerimplementiert werden.Es MUSS eine Policy für den Einsatz von Anti-Malicious-Software(d. h. Antiviren-, Anti-Trojaner-, Anti-Backdoor-Software etc.) geben.Die entsprechende Software MUSS installiert und zeitnah aufdem aktuellen Stand gehalten werden.Es MUSS ein Schutz vor Modifikation und unberechtigtem Löschenvon Auditaufzeichnungen implementiert sein.Das Modifizieren oder Löschen von Logdaten durch unautorisierteBenutzer MUSS verhindert werden.Es MUSS unterbunden werden, dass eine unautorisierte Personverursachen kann, dass Audit-Aufzeichnungen verloren gehenoder zukünftige Aufzeichnungen durch Überschreiten der Audit-Speicherkapazität verhindert werden, und dadurch Angriffe unerkanntbleiben.AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 301 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02864 S Sec_Netzwerk_Allg_10: Verhinderungvon fake-Einträgen.A_02865 S Sec_Netzwerk_Allg_11:Schutz vor Verteilung bösartigerSoftware.A_02866 S Sec_Netzwerk_Allg_12: Verhinderungdes unerlaubtenZugriffs auf andere Sicherheitszonen.A_02867 S Sec_Netzwerk_Allg_13:Schutz vor Ausfall des Transportnetzesaufgrund von Elementarereignissen.A_02868 S Sec_Netzwerk_Allg_14:Schutz vor Ausfall zentralertechnischer Komponentenaufgrund von Elementarereignissen.A_02869 S Sec_Netzwerk_Allg_15: Erreichbarkeitder VPN Gatewaysder ZugangsknotenA_02870 S Sec_Netzwerk_Allg_16:Bounds Checking am externenVPN-Gateway.A_02871 S Sec_Netzwerk_Allg_17:Ingress- und Egress Filteringan FirewallsA_02872 S Sec_Netzwerk_Allg_18: Anti-Spoofing Maßnahmen an Firewalls.Es MUSS unterbunden werden, dass Audit-Aufzeichnungen fürnicht stattgefundene Ereignisse (Protokolle, Audit Trails, Logs)erstellt werden.Es MUSS ein Schutz vor Verteilung bösartiger Software durchMissbrauch von Zugriffsrechten implementiert sein.Es MUSS verhindert werden, dass Benutzer und/oder Administratoreneiner Sicherheitszone unerlaubt Zugriff auf Dienste eineranderen Sicherheitszone der Telematikinfrastruktur erlangen.Es MUSS ein Schutz vor dem Ausfall von zentralen Komponentenund zentralen Diensten des Transportnetzes durch Elementarereignisseimplementiert werden.Es MUSS verhindert werden, dass durch Ausfall einer zentralentechnischen Komponente aufgrund eines Elementarereignisses (z.B. Feuer, Wasser, Blitz, Ausfall/Beeinträchtigung der Stromversorgung,Sabotage, Diebstahl) der Betrieb der Telematikinfrastrukturgrundlegend beeinträchtigt wird.Es SOLL sichergestellt sein, dass es durch den Ausfall von zentralenDiensten des Transportnetzes (etwa DNS Rootserver im Internet)nicht zu einer massiven Beeinträchtigung der Erreichbarkeitder VPN Gateways der Zugangsknoten kommt.Das externe VPN-Gateway MUSS Bounds Checking unterstützen.Firewalls MÜSSEN Ingress- und Egress Filtering unterstützen.Firewalls MÜSSEN Spoofing verhindern.AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 302 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02873 S Sec_Netzwerk_Allg_19: Anwehrbekannter Angriffstypen.A_02874 S Sec_Netzwerk_Allg_20: Verhinderungvon Source-Address Spoofing.A_02875 S Sec_Netzwerk_Allg_21: KeinRouting zwischen Primärsystemnetzund TI.A_02876 S Sec_Netzwerk_Allg_22: Konnektorist Applikationsproxy.A_02877 S Sec_Netzwerk_Allg_23: ARP-Level Security ist verpflichtend.A_02878 S Sec_Netzwerk_Allg_24: Ausfallsicherheitvon Firewalls.A_02879 S Sec_Netzwerk_Allg_25: Einsatzvon DMZs,Firewalls MÜSSEN so betrieben werden, dass bekannte Angriffe(z.B. Tiny-Fragment-Attack oder UDP-Punching) abgewehrt werdenund dadurch nicht erfolgreich sindDie Angriffsmöglichkeit des Source-Address Spoofing MUSS innerhalbder Telematikinfrastruktur unterbunden werden.Es MUSS sichergestellt sein, dass es kein Routing zwischen Primärsystemnetzund Telematikinfrastruktur gibt. Jegliche KommunikationMUSS über den Anwendungskonnektor stattfinden.Der Konnektor MUSS für §291a-Anwendungen gegenüber denPrimärsystemen (AVS, PVS, KIS) als Applikations-Proxy auftreten.ARP-Level Security (Address Resolution Protocol) MUSS berücksichtigtwerden.Die Ausfallsicherheit von Firewalls MUSS gewährleistet sein.Eine demilitarisierte Zone (DMZ) SOLL eingesetzt werden.AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3A_02880 AS-AI-12130A_02881 AS-AI-12140A_02882 AS-AI-12150SSSSec_Netzwerk_Allg_26: StatefulInspection verpflichtend.Sec_Netzwerk_Allg_27: ApplicationLevel Firewall optional.Sec_Netzwerk_Allg_28: Einsatzvon IPS optional.Die Firewalls MÜSSEN über die Funktionalität „Stateful Inspection“verfügen.Die Firewalls KÖNNEN mit einer Application Layer Firewall ausgestattetsein.Intrusion Prevention Systeme (IPS) KÖNNEN eingesetzt werden.AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 303 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_02883 AS-AI-12160A_02884 AS-AI-12170A_02885 AS-ZD-5110A_02886 AS-ZD-5120A_02887 AS-ZD-5130A_02888 AS-ZD-5140SSSSSSSec_Netzwerk_Allg_29: KeineKlartextprotokolle.Sec_Netzwerk_Allg_30: MinimalePortkonfiguration.Sec_Netzwerk_Allg_31: Abwehrvon DoS sowie DDoSAngriffen.Sec_Netzwerk_Allg_32: Administrationüber gesicherteVerbindung.Sec_Netzwerk_Allg_33: RedundanteAuslegung der Infrastruktur.Sec_Netzwerk_Allg_34: Verhinderungdes dauerhaftenVerbindungsabbruchs.Klartextprotokolle wie Telnet oder FTP DÜRFEN bei einer FirewallNICHT eingesetzt werden.Es MUSS sichergestellt sein, dass bei einer Firewall nur die unbedingtfür die erforderliche Aufgabe gebrauchten Ports geöffnetsind.Der Anbieter MUSS entsprechende Maßnahmen treffen, umDoS/DDoS abzuwehren.Die Administration der Systeme MUSS über eine gesicherte Verbindung(VPN, SSL, SSH etc.) erfolgen, falls diese nicht lokal vorgenommenwird.Hierbei MÜSSEN geeignete Kryptografieverfahren lt. den gematikVorgaben eingesetzt werdenUm die Anforderungen an das Sicherheitsziel Verfügbarkeit zugewährleisten, MUSS die Infrastruktur redundant ausgelegt sein.Die Infrastruktur MUSS so ausgelegt sein, dass ein Ausfall derKomponente nicht zum dauerhaften Abbruch aller Verbindungenführt.AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3AnhangB 4.6.3B4.6.4 - Schutz der VPN-ZugangsdatenAfo-ID Anfo ArtA_02889STitel Beschreibung Rel. QuelleSec_VPN_Zugangsdaten_01:Unberechtigtes Auslesen /Manipulation der VPN-Das unberechtigte Auslesen/die Manipulation der VPN-Zugangsdaten des Konnektors MUSS verhindert werden.AnhangB 4.6.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 304 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZugangsdaten.A_02890A_02891SSSec_VPN_Zugangsdaten_02:Schutz administrativer Verbindungen.Sec_VPN_Zugangsdaten_03:Verschlüsselung administrativerNetzwerkkommunikation.Administrative Verbindungen zum Konnektor MÜSSEN geschütztwerden. Es MUSSS unterbunden werden, daß administrative Daten(Kennwörter etc.) im Klartext abgehört werden können.Die administrative Netzwerkkommunikation zwischen allen beteiligtenSystemen MUSS verschlüsselt erfolgen.AnhangB 4.6.4AnhangB 4.6.4B4.6.5 - Sichere Verbindung zwischen Konnektor und TelematikAfo-ID Anfo ArtA_02892 AS-AI-10180STitel Beschreibung Rel. QuelleSec_Verbindung_Konnektor_TI_01: Absicherung der Verbindungzwischen Konnektor undZugangsnetz.Die Kommunikation zwischen Konnektor und Zugangsnetz MUSSabgesichert werden.AnhangB 4.6.5A_02893 S Sec_Verbindung_Konnektor_TI_02: Anti SniffingA_02894 S Sec_Verbindung_Konnektor_TI_03: Verhinderung von DoSund Ddos an zentralen Systemenund Komponenten.A_02895 S Sec_Verbindung_Konnektor_TI_04: Vermeidung von allge-Das Abhören (Sniffen) des Netzwerkverkehrs zwischen Konnektorund Telematikinfrastruktur DARF NICHT dazu führen, dass dieVertraulichkeit der unverschlüsselten Daten verletzt wird, beziehungsweiseeine Verkehrsflussanalyse erfolgreich durchgeführtwird.Eine Diensteverweigerung (DoS – Denial of Service, DDoS –Distributed Denial of Service) MUSS an zentralen Systemen undKomponenten verhindert werden.Neben möglichen DoS-Angriffen aus den Primärnetzen besteht dieMöglichkeit von Angriffen auf den zentralen Zugangsknoten ausAnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 305 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellemeinen Angriffen aus den Netzenvon Dienstanbietern.A_02896 S Sec_Verbindung_Konnektor_TI_05: Resistent gegen DNS-Cache-Poisoning.A_02897 S Sec_Verbindung_Konnektor_TI_06: Schutz vor DNS Clientflooding Attacken.A_02898 S Sec_Verbindung_Konnektor_TI_07: Verhinderung von logischemsowie physischem Abhörenvon medizinischen sowieadministrativen Daten.A_02899 S Sec_Verbindung_Konnektor_TI_08: Maßnahmen gegen Abhörenvon Authentifikationsgeheimnissen.A_02900 S Sec_Verbindung_Konnektor_TI_09: Maßnahmen gegen Abhörenvon sicherheits-/datenschutzrelevanten Informationen(Authentifikationsdienst).A_02901 S Sec_Verbindung_Konnektor_TI_10: Maßnahmen gegen Abhörenvon sicherheits-/datenschutzrelevanten Infor-mationen(Software-Updatedienst).den Netzen von Dienstanbietern (VSDD, VODD oder Mehrwertdiensteanbieter).Alle Formen derartiger Angriffe MÜSSEN vermiedenwerden.Die in der Telematikinfrastruktur verwendeten DNS-Server MÜS-SEN gegen DNS-Cache-Poisoning Attacken resistent sein.DNS Client flooding Attacken SOLLEN verhindert werden. DieserSchutz MUSS stets in Verbindung mit Address Spoofing betrachtetwerden.Sowohl das logische als auch das physische Abhören (Sniffen) vonmedizinischen als auch administrativen Informationen über Verbindungenzwischen Zugangsknoten (VPN-Konzentratoren, Routern)und Datendiensten (Fachdiensten) DÜRFEN NICHT stattfinden.Das Abhören von unverschlüsselten Authentifikationsgeheimnissenzwischen Konnektor und VPN-Konzentrator MUSS durch geeigneteMaßnahmen unterbunden werden.Das Abhören von sicherheits-/datenschutzrelevanten Informationen,die zwischen dem VPN-Konzentrator und einem Authentifikationsdienstausgetauscht werden, MUSS geeignet unterbundenwerden.Das Abhören von sicherheits-/datenschutzrelevanten Informationen,die zwischen dem Konnektor und dem Software-Updatedienstausgetauscht werden, MUSS geeignet unterbunden werden.AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 306 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02902 S Sec_Verbindung_Konnektor_TI_11: Maßnahmen gegen Abhörenvon sicherheits-/datenschutzrelevanten Informationen(CA)A_02903 S Sec_Verbindung_Konnektor_TI_12: Maßnahmen gegen Abhörenvon Versicherteninformationen.A_02904 S Sec_Verbindung_Konnektor_TI_13 :Maßnahmen gegen Abhörenvon eVerordnungsdaten.A_02905 S Sec_Verbindung_Konnektor_TI_14: Unterbinden einer Verbindungmit einem nicht autorisierenVPN-Gateway.A_02906 S Sec_Verbindung_Konnektor_TI_15: :Maßnahmen gegen Abhörenvon Protokollierungsdaten.A_02907 S Sec_Verbindung_Konnektor_TI_16: Maßnahmen gegen Abhörenvon Card-IDs und NutzerinformationenA_02908 S Sec_Verbindung_Konnektor_TI_17: Maßnahmen gegenmaskieren des VPN-Konzentrators.A_02909 S Sec_Verbindung_Konnektor_TI_18: Kommunikationsein-Das Abhören von sicherheits-/datenschutzrelevanten Informationen(z. B. OCSP, LDAP) zwischen einer CA und einem KonnektorSOLL geeignet unterbunden werden.Das Abhören von Versicherteninformationen zwischen Konnektorund Telematikinfrastruktur MUSS geeignet unterbunden werden.Das Abhören von eVerordnungs-Daten zwischen Konnektor undTelematikinfrastruktur MUSS geeignet unterbunden werden.Die Möglichkeit, dass ein Konnektor sich mit einem nicht autorisiertenVPN-Gateway verbindet MUSS geeignet unterbunden werden.Das Abhören einer Verbindung zwischen Konnektor und einer dezentralen,technischen Protokollierungskomponente (Logserver)SOLL auf geeignete Weise unterbunden werden.Das Abhören von Card-IDs und Nutzerinformationen auf der Verbindungzwischen Konnektor und CAMS MUSS geeignet unterbundenwerden.Es MUSS unterbunden werden, dass ein Angreifer den VPN-Konzentrator (VPN-Gateway-Telematik-Zugangsprovider) maskierenkann, um unautorisierten Zugriff auf vom Primärsystem übertrageneDaten zu erhalten.Das Primärsystem DARF NICHT direkt mit der Telematikinfrastrukturkommunizieren. Als Absender MUSS für die Telemati-AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5AnhangB 4.6.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 307 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelleschränkung der Primärsysteme.A_02910 S Sec_Verbindung_Konnektor_TI_19: Maßnahmen gegen Dateneinleitungin ungeschützteNetze.A_02911 S Sec_Verbindung_Konnektor_TI_20: OrdnungsgemäßeDurchführbarkeit von Updates.kinfrastruktur immer der Anwendungskonnektor auftreten. (Für denSonderfall der Mehrwertdienste gibt es u. U. an anderer StelleAusnahmeregelungen.)Es MUSS unterbunden werden, dass ein Angreifer personenbezogeneunverschlüsselte Daten über den Konnektor in ungeschützteNetze leiten kann. (Für den Sonderfall der Mehrwertdienste gibt esu. U. an anderer Stelle Ausnahmeregelungen.)Es MUSS verhindert werden, dass ein Angreifer die Übertragungund Aktivierung eines Updates der Konnektorsoftware stört, umdas Einspielen eines sicherheitsrelevanten Updates der Konnektorsoftwarezu verhindern und so für einen längeren Zeitraum unautorisiertauf Daten und Systeme zugreifen zu können.AnhangB 4.6.5AnhangB 4.6.5B4.6.6 – BrokerAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_02912 S Sec_Broker_01: Validierungund Signierung von Telematiknachrichten.A_02913 S Sec_Broker_02: Integrität derKomponenten.A_02914 S Sec_Broker_03: Integrität derübertragenen Daten.Durch Implementation der dem Trusted Service nachgeordnetenSecurity Services SVS und SCS MÜSSEN Telematiknachrichtenabhängig vom Use Case validiert und signiert werden.Die Integrität aller Komponenten und Dienste innerhalb der SystemgrenzenMUSS gewährleistet werden. Dies gilt insbesonderefür den BrokerService und KANN durch die Definition von Anforderungenan die Betriebsumgebung (physikalischer Schutz) oderdurch eine Prüfung zur Laufzeit erfolgen.Bei der Kommunikation des Brokers mit anderen Diensten undKomponenten MUSS sichergestellt werden, dass die zu übertragendenDaten in unveränderter Form beim Empfänger ankommen.AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 308 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleDies MUSS durch geeignete Mechanismen sichergestellt werden.A_02915 S Sec_Broker_04: Nutzung vonZertifikaten für Authentisierung/Autorisierung.A_02916 AS-BS-5100A_02917 AS-BS-5110A_02918 AS-BS-5120A_02919 AS-BS-5130A_02920 AS-BS-5140SSSSSSec_Broker_05: Zulassungvon Broker-Sequenzen.Sec_Broker_06: TtechnischenMechanismus zur Prüfung derAbnahme/Zulassung von Broker-Sequenzen.Sec_Broker_07: Dokumetationvon Konfigurationsänderungenbei Neustart.Sec_Broker_08: Hinterlegungvon Broker-Sequenzen.Sec_Broker_09:DynamischeKonfiguration von Broker-Sequenzen ist nicht erlaubt.Alle mit dem BrokerService kommunizierenden Dienste und Komponenten,wie auch der BrokerService selbst, MÜSSEN über Zertifikateverfügen, mit denen die Kommunikationspartner währendeines Verbindungsaufbaus prüfen können, ob diese Komponenteüber eine Betriebszulassung im Kontext der Telematikinfrastrukturverfügt. Insbesondere MUSS mittels Zertifikaten die Überprüfungder Identität (Authentifizierung) und die Berechtigung (Autorisierung)der kommunizierenden Dienste gewährleistet werden.Broker-Sequenzen MÜSSEN vor Verwendung durch die gematikabgenommen (zugelassen) werden.Die erfolgte Abnahme einer Broker-Sequenz MUSS durch einegeeignete technische Maßnahme (z. B. fortgeschrittene Signatur)von der gematik dokumentiert werden.Die Broker-Instanz MUSS über einen technischen Mechanismuszur Prüfung der Abnahme/Zulassung der Broker-Sequenzen durchdie gematik verfügen. Bei negativem Ergebnis dieser Prüfung (z.B. fortgeschrittene Signatur) DARF die Broker-Instanz die Broker-Sequenz NICHT verwenden.Der Betreiber MUSS dokumentieren, wann er eine geänderte Konfigurationvon Broker Sequenzen durch Neustart der logischenInstanz aktiviert.Die Hinterlegung konkreter Broker-Sequenzen MUSS im Rahmender Konfiguration der Broker-Instanz möglich sein. Eine Hinterlegungvon Broker-Sequenzen durch Software-Änderungen DARFNICHT erfolgreich erfolgen.Die Konfiguration der Broker-Sequenzen DARF aus SicherheitsgründenNICHT dynamisch möglich sein, sondern MUSS ausschließlicheinmalig beim Start einer Broker-Instanz gelesen werden.AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 309 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02921 AS-BS-5160A_02922 AS-BS-5210A_02923 AS-BS-5220A_02924 AS-BS-5240A_02925 AS-BS-6100A_02926 AS-BS-6110SSSSSSTitel Beschreibung Rel. QuelleSec_Broker_10: Feherbehandlungbei der Ermittlungvon Broker-Sequenzen.Sec_Broker_11: Rückgabe derTelematikCoreMessage anden Primärsystem-Konnektor.Sec_Broker_12: Logging vonFehlern.Sec_Broker_13: Behandlungnicht behebbarer Fehlerzustände.Sec_Broker_14: Kommunikationmit Konnektoren.Sec_Broker_15: VerschlüsselteKommunikation mit beidseitigerAuthentisierung.Der Broker leitet aus der Telematiknachricht eine Broker-Sequenzab und arbeitet diese ab.Kann für eine Kombination von Werten keine (oder keine eindeutige)Broker-Sequenz ermittelt werden, so MUSS eine Fehlermeldungan den Konnektor zurückgegeben und ein Alarmereignis überdas System Management ausgelöst werden. Die Broker-SequenzDARF in so einem Fehlerfall NICHT ausgeführt werdenDie vom Fachdienst zurückgegebene TelematikCoreMessageMUSS am Ende der Broker-Sequenz von der Broker-Instanz anden Primärsystem-Konnektor zurückgegeben werden.Treten Fehler während der Ausführung der Broker-Sequenzen auf,so MÜSSEN diese so detailliert wie erforderlich und erlaubt überdas Logging-Framework geloggt werden.Die Verarbeitungssteuerung des Brokers MUSS sicherstellen, dassnicht behebbare Fehlerzustände bei der Verarbeitung einer Broker-Sequenz zu einem Abbruch der Verarbeitung der kompletten Sequenzführen. Änderungen bei den Fachdiensten können allerdingsüber die Broker-Instanz nicht rückgängig gemacht werden.Die Kommunikation des Konnektors mit den Brokerdiensten (d. h.der Broker-Instanz) MUSS über das VPN-Zugangsnetz und dasFrontend VPN der Telematik erfolgen.Die Broker verfügt über Schlüsselpaare und Zertifikate zur sicherenKommunikation (TLS/SSL) mit den Kommunikationspartnern.Alle übertragenen Daten MÜSSEN verschlüsselt werden. BeideKommunikationspartner MÜSSEN sich mittels SSL/TLS überClient- und Server-Zertifikate gegenseitig authentisieren.Das Zertifikat des jeweiligen Kommunikationspartners MUSS währenddes SSL-Handshakes über OCSP geprüft werden. GeeigneteCaching-Strategien sind möglich. 24AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.624 Diese Anforderung wird in einer Folgeversion des Übergreifenden Sicherheitskonzepts noch detailliert.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 310 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02927 AS-BS-6120A_02928 AS-BS-6130A_02929 AS-BS-6150A_02930 AS-BS-6160A_02931 AS-BS-6170SSSSSTitel Beschreibung Rel. QuelleSec_Broker_16: VerschlüsselteKommunikation mit beidseitigerAuthentisierung / AusnahmenSec_Broker_17: VerschlüsselteKommunikation innerhalbder Betreibergrenzen.Sec_Broker_18: VerschlüsselteKommunikation mit beidseitigerAuthentisierung zumRegistrierungsdienst.Sec_Broker_19: VerschlüsselteKommunikation mit beidseitigerAuthentisierung zuden Fachdiensten.Sec_Broker_20: GetrennterBetrieb für Broker- und Audit-Instanz.Für sämtliche Kommunikation zwischen den Brokerdiensten undden Services in anderen Sicherheitszonen der SicherheitsarchitekturMUSS auf der Transportebene eine Absicherung über TLS/SSLerfolgen.Hierbei MÜSSEN sich die Kommunikationspartner gegenseitigauthentisieren.Für die Kommunikation zwischen Diensten innerhalb einer SicherheitszoneKANN in begründeten Fällen von diesem Schema abgewichenwerden. Dann MUSS allerdings nachgewiesen werden,dass über geeignete Maßnahmen ein mindestens äquivalenterGrad an Sicherheit erreicht wird (siehe nachfolgende Anforderungen).Innerhalb der Betreibergrenzen und somit innerhalb des Netzwerksder Brokerdienste MUSS die Kommunikation verschlüsselt überSSL/TLS erfolgen, sofern sie nicht innerhalb eines gesichertenRechners erfolgt. Das betrifft in erster Linie die Kommunikationzwischen dem Broker Service (i. e. S.) und dem Trusted Service,aber auch eine mögliche Kommunikation zwischen dem BrokerService und einer optionalen Broker-Datenbank.Die Kommunikation zwischen der Broker-Instanz und dem RegistrierungsdienstMUSS über das Backend-Netzwerk per SSL/TLSabgesichert werden. Die Absicherung MUSS eine gegenseitigeAuthentisierung umfassenDie Kommunikation zwischen dem Konnektor und der Broker-Instanz sowie zwischen der Broker-Instanz und den FachdienstenMUSS per SSL/TLS abgesichert werden. Die Absicherung MUSSeine gegenseitige Authentisierung umfassenBroker-Instanz und Audit-Instanz MÜSSEN bei verschiedenen Anbieternbetrieben werden können.AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 311 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02932 AS-BS-6180A_02933 AS-BS-6200A_02934 AS-BS-6210SSSTitel Beschreibung Rel. QuelleSec_Broker_21: GetrennterBetrieb für Brokerinstanz Registrierungsdienst.Sec_Broker_22: Initiierung derBroker-Konnektor Kommunikation.Sec_Broker_23: Initiierung derBroker-Fachdienst Kommunikation.Broker-Instanz und Registrierungsdienst MÜSSEN bei verschiedenenAnbietern betrieben werden können.Die Kommunikation zwischen Konnektor und Broker-InstanzMUSS von dem Konnektor initiiert werden.Die Kommunikation zwischen Broker-Instanz und FachdienstMUSS von der Broker-Instanz initiiert werden.Ist einer der aufzurufenden Dienste nicht verfügbar, MUSS dieSequenz abgebrochen, eine Fehlermeldung generiert und an denaufrufenden Konnektor als Response zurückgesendet werden.AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6Die Broker-Instanz MUSS die nachfolgenden Sicherheitsanforderungen zum internen Workflow (den durch die Broker-Instanz gesteuertenWorkflow), zum Datenfluss (z. B. Prüfung von Eingangsdaten) sowie zur internen Verarbeitung von Konfigurations- und Adressdaten umsetzenA_02935 AS-BS-9100S Sec_Broker_24: EindeutigeMessage-IDAnhangB 4.6.6A_02936 AS-BS-SSec_Broker_25: Fehlerbehandlungbei fehlgeschlagenerTelematiknachrichten besitzen eine eindeutige Nachrichtenidentität(Message-ID) und einen Versand-Zeitstempel.Broker MÜSSEN Replay-Attacken verhindern.Eine Nachricht, die nach einer definierten Zeitspanne nach derErstellung der Nachricht vom Broker empfangen wird, DARFNICHT durch die Broker-Instanz verarbeitet werden.Eine Nachricht, die zum zweiten bzw. wiederholten Mal empfangenwird, DARF NICHT mehrfach durch die Broker-Instanz verarbeitetwerden.Parameter eines Filters MÜSSEN konfigurierbar sein.Broker KÖNNEN diese Filterung und weitere Sicherheitsmerkmaleggf. in einen eigenständigen Broker-Application-Proxy auslagern.Bemerkung: Da basierend auf dem Erstellungszeitpunkt einerNachricht zu spät beim Broker eingehende Nachrichten grundsätzlichnicht verarbeitet werden dürfen, müssen nur die Message-IDsin dem zulässigen Zeitraum gespeichert und überprüft werden.Schlägt die Validierung (bzgl. Message-ID oder Zeitstempel) fehl,so MUSS der Fehler so detailliert wie möglich und erlaubt über dasAnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 312 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02937 AS-BS-9120A_02938 AS-BS-9130A_02939 AS-BS-9140A_02940 AS-BS-9160A_02941 AS-BS-9170Titel Beschreibung Rel. Quelle9110 Validierung. Logging-Framework als Fehler geloggt werden. Ferner MUSS einAlarmereignis über das System Management ausgelöst werden.S Sec_Broker_26: Unveränderte Die Broker-Instanz MUSS die von Fachdienst zurückgegebeneWeitergabe der TelematikCoreMessage.TelematikCoreMessage unverändert an den Konnektor zurückgeben.SSSSSec_Broker_27: Konfigurationder Broker Service.Sec_Broker_28: Broker-Instanzen haben statische IP-Adressen.Sec_Broker_29: Lokalisationder Fachdienste über den Registrierungsdienst.Sec_Broker_30: StatischeAdresse des Web ServiceEndpoints für den TrustedService.Die Konfiguration des Broker Service i. e. S. MUSS mindestensfolgende Elemente beinhalten:o Adressen (URIs) der dem Broker zugeordneten Service DirectoryService-, Security Services- (bzw. Trusted Service-) Instanzen,o Definition der Broker-Sequenzen,o Zeitspanne, während der Telematiknachrichten in Relation zuihrem Erzeugungszeitpunkt als gültig betrachtet werden sollen.o Policy für SDS Registry Cache Refresh (nächster Refresh-Zeitpunkt und Refresh-Intervall),o Default-Level für das Logging-Framework.Darüber hinaus KÖNNEN weitere Parameter konfigurierbar gehaltenwerden.Die logischen Broker-Instanzen MÜSSEN statische IP-Adressenerhalten.Die Lokalisation der Fachdienste MUSS über den Registrierungsdiensterfolgen, wobei eine vom Registrierungsdienst zurückgegebeneZieladresse (URI) ebenfalls wieder über DNS aufgelöst wird.Die Adresse (URI) des Web Service Endpoints für den TrustedService MUSS statisch, aber konfigurierbar in der Broker-Instanzhinterlegt sein und wird über DNS aufgelöst. Dynamische Änderungender Trusted Service-Adresse während des laufenden Betriebsdes Brokers SOLLEN durch Umkonfiguration im DNS Serverfür die Broker-Instanz transparent durchgeführt werden und bedingendadurch keine Änderung an der Broker-Instanz.AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 313 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02942 AS-BS-9190A_02943 AS-BS-9200A_02944 AS-BS-9210A_02945 AS-BS-11100A_02946 AS-BS-11110A_02947 AS-BS-11120A_02948 AS-BS-1113SSSSSSSTitel Beschreibung Rel. QuelleSec_Broker_31: SparsameDatenspeicherung.Sec_Broker_32:Aktualisierung des SDS RegistryCache.Sec_Broker_33: Fehlerbehandlungbei fehlschlagen derCache-Aktualisierung.Sec_Broker_34: Management-API zur Änderung von Laufzeitparameterndurch das SystemManagementSec_Broker_35: Monitoring-API zur Abfrage von SystemzuständenSec_Broker_36: Überwachungdurch System-ManagementSysteme.Sec_Broker_37: Keine Erfassungpersonenbezogener Datenbeim Monitoring.Es MUSS sichergestellt sein, dass die Broker-Instanz im Zuge desdefinierten Monitorings, Daten oder Statistiken über in der Vergangenheitverarbeitete Requests nur in dem durch das Gebot derDatensparsamkeit vorgegebenem Umfang speichern kann.Der SDS Registry Cache MUSS in regelmäßigen Intervallen aktualisiertwerden. Die Zeitabstände MÜSSEN konfigurierbar sein.Schlägt eine Cache-Aktualisierung fehl, wird über das Fehler- undLogging-Framework eine entsprechende Nachricht generiert undder bisherige Cache-Inhalt unverändert weiter verwendet. EsMUSS sichergestellt werden, dass der Registrierungsdienst fürfolgende Aktualisierungen wieder zur Verfügung steht. Dazu KANNes, falls der Fehler beim Registrierungsdienst liegt, erforderlichsein, dass der Betreiber des Registrierungsdienstes informiert wird.Dieser MUSS dann sicherstellten, dass der Registrierungsdienstfür folgende Aktualisierungen wieder zur Verfügung steht.Die Brokerdienste MÜSSEN ein Management-API zur Änderungvon Laufzeitparametern durch das System Management bereitstellen.Die Brokerdienste MÜSSEN ein Monitoring-API zur Abfrage vonSystemzuständen bereitstellen.Die Broker- und Security-Instanzen MÜSSEN durch entsprechendeSystem-Management Systeme überwacht werden. Bei Ausfalleiner Instanz MÜSSEN geeignete technische und organisatorischeMaßnahmen für den Wiederanlauf eingeleitet werden.Es MUSS sichergestellt sein, dass über die System-ManagementSysteme und das Monitoring-API keine personenbezogenen Datenabgefragt werden können. Es gelten dieselben Regeln wie für Log-AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 314 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02949 AS-BS-11140A_02950 AS-BS-12100A_02951 AS-BS-12110A_02952 AS-BS-12120Titel Beschreibung Rel. Quelle0 Meldungen (siehe Sicherheitsanforderungen zum Fehlermanagement).S Sec_Broker_38: Lokale ZugriffeDer lokale Zugriff der Brokerdienste auf die dezentralen Monito-auf dezentrale Monitoring- ring- und System-Management-Schnittstellen eines Dienstesund System-Management- MUSS lokal über das Netzwerk des jeweiligen Betreibers erfolgen.Schnittstellen.SSSSec_Broker_39:Reaktion beiaußergewöhnlichen Ereignissen.Sec_Broker_40: Erstellungvon Logeinträgen.Sec_Broker_41: Fehlerbehandlungbei nicht zu ermittelndemVerzeichniseintrag.Bei außergewöhnlichen Ereignissen, die auf sicherheitsrelevanteFehler in Komponenten der Telematik oder Einbruchsversucheschließen lassen, z. B. Fehler bei der Schemavalidierung von Telematiknachrichtenoder Fehler des Security Validation Service beider Signaturprüfung, MUSS das System-Management alarmiertwerden.Bei folgenden Fehlern MUSS ein Log-Eintrag erzeugt werden, derdazu führen MUSS, dass ein Alarm im System-Management desBetreibers erzeugt wird:o Feststellung von Verletzungen der Nachrichtenintegrität durchden SVSo Feststellung von Nichterreichbarkeit von Services oder Server-Instanzeno Feststellung der Nichtverfügbarkeit der Kryptoboxen (HSM)o Feststellung von Fehlern, die zur Nichtverfügbarkeit von Service-Instanzen führen.Ist durch eine aktuelle Abfrage an den Registrierungsdienst keinVerzeichniseintrag zu ermitteln, MUSS der Broker die Sequenzabbrechen, einen SOAP-Fehler an den aufrufenden Konnektorzurückmelden und einen Fehler über das Logging-Framework loggen.Ferner MUSS ein Alarmereignis über das System Managementausgelöst werden.Bei sonstigen Verarbeitungsfehlern des RegistrierungsdienstMUSS die Broker-Instanz die Broker-Sequenz ebenfalls abbrechen,den Fehler loggen und einen SOAP-Fehler zurückmelden.AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 315 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02953 AS-BS-12130A_02954 AS-BS-12140A_02955 AS-BS-12150A_02956 AS-BS-12180A_02957 AS-BS-SSSSSTitel Beschreibung Rel. QuelleSec_Broker_42: Abbruch dersynchronen Verarbeitung imFehlerfall.Sec_Broker_43: Verhinderungvon mehrfacher Verarbeitungeiner Nachricht.Sec_Broker_44 :Auschlüssefür Logmeldungen.Sec_Broker_45: Vorhalten,Auswerten und Löschen vonLogdaten.Sec_Broker_46: Terminierungder TLS/SSL-Verbindung.Fehler, die ein Alarmereignis über das System Management auslösen,MÜSSEN bei synchroner Verarbeitung zu einem Abbruchder Verarbeitung führen. Die aktuelle Nachricht MUSS nach Speicherungder Fehlerdetails für die weitere Verarbeitung verworfenwerden. Eine spätere Wiederaufnahme der Verarbeitung ist nichtzulässig.Im Falle der Verwendung automatisierter Retry-MechanismenMUSS durch die Verwendung idempotenter Algorithmen sichergestelltwerden, dass in keinem Falle eine zweimalige Verarbeitungder Nachricht erfolgen DARF. Dies gilt insbesondere bei der Verarbeitungüber Tier-Grenzen hinaus: Wenn die aufgerufene Tierkeine Idempotenz sicherstellen kann, DARF kein Retry-Versucherfolgen.Regeln für Log-Meldungen:Es DÜRFEN keine personenbezogenen Daten im Zusammenhangmit der aktuellen Nachricht geloggt werden.Es DÜRFEN keine Informationen über die Identitäten und Zertifikatesowie keine Informationen aus den Common Names der Zertifikatefür die Zuweisung von Rollen an die Benutzer geloggt werden.Die Nachrichten selbst DÜRFEN ebenfalls NICHT geloggt werden,auch wenn es sich dabei nur um einen verschlüsselten Datenstromhandelt.Die Nachrichten-ID, Zeitstempel und Servicetyp sowie andere unverschlüsselteAngaben aus der Nachricht mit Ausnahme der o. a.Datenelemente KÖNNEN geloggt werden.Alle geloggten Daten MÜSSEN für einen definierten Zeitraum vorgehaltenwerden und MÜSSEN nach ihrer Auswertung gelöschtwerden.Auf einem Broker-Applikationsproxy KANN die TLS/SSL-Verbindung für den Zugriff auf den Broker Service i. e. S. bereits inAnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 316 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelle13100A_02958 AS- S Sec_Broker_47: FirewallarchitekturBS-gemäß Zonenkonzept.13110A_02959 S Sec_Broker_48: Begutachtungder Brokerdienste ist erforderlich.A_02960 S Sec_Broker_49: Schutz desprivaten Schlüssels.A_02961SSec_Broker_50: Sicherheitsfunktionalitätder Broker-Instanz.der demilitarisierten Zone in Form eines Reverse-Proxy-Serverterminiert werden.Die Firewall Architektur MUSS gemäß dem Zonenkonzept eingerichtetwerden.Die technischen Komponenten der Brokerdienste MÜSSEN bzgl.ihrer Sicherheitsfunktionalität durch ein anerkanntes Begutachtungsverfahrenbegutachtet werden.Der Schutz des privaten Schlüssels (Speicherung, Anwendung,etc.) MUSS durch eine Begutachtung nachgewiesen werden. Zulässigsind eine Evaluierung nach FIPS Level 3, nach CommonCriteria; EAL4 oder nach ITSEC E3 „hoch“.Die Broker-Instanz MUSS folgende Sicherheitsfunktionalität umsetzen:o Auditierungo Abfragen an Service Directory Serviceo Anonymisierung der Nachrichteno Validierung der Telematiknachrichten durch den Security ValidationServiceo Signatur der Telematiknachrichten durch den Security ConfirmationServiceo Schutz der Konfigurationsdaten (einschließlich Adressdaten)o Prüfung der Eingangsdateno Schutz der übertragenen Metadaten (Informationsflusskontrolle,keine Speicherung)o Key ManagementAnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6AnhangB 4.6.6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 317 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.6.7 - System ManagementAfo-ID Anfo ArtA_02962STitel Beschreibung Rel. QuelleSec_SystemManagement_01:Authentizität und Integrität derDaten bei administrativenAufgaben.Die Authentizität und Integrität der Daten MUSS bei administrativenAufgaben gewährleistet sein. Des Weiteren MUSS gewährleistetsein, dass nur autorisierte Benutzer Änderungen vornehmenkönnen.AnhangB 4.6.7B4.6.8 – AuditAfo-ID Anfo ArtA_02963 AS-AI-5110A_02964 AS-BS-8100A_02965 AS-BS-8110A_02966 AS-BS-8120A_02967 AS-BS-8130SSSSSTitel Beschreibung Rel. QuelleSec_Audit_01 : GetrennterBetrieb von Audit-Instanz undFachdiensten.Sec_Audit_02: GegenseitigeAuthentisierung AuditService /Versicherter.Sec_Audit_03 :Nur Lesezugrifffür den Versicherten.Sec_Audit_04: Zugriff desVersicherten nur auf die eigenenDatenSec_Audit_05: Anlaufstelle fürVersicherte.Audit-Instanz und Fachdienste MÜSSEN bei verschiedenen Anbieternbetrieben werden.Versicherter und Audit Service MÜSSEN sich gegenseitig authentisieren.Es MUSS sichergestellt sein, dass der Versicherte ausschließlichlesenden Zugriff hat.Es MUSS sichergestellt sein, dass der Versicherte ausschließlichZugriff auf seine eigenen Daten hat.Der Versicherte MUSS die Möglichkeit haben, eine zuständigeStelle über mutmaßliche Unstimmigkeiten in den Daten zu informieren.AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8Die Audit-Service MUSS die nachfolgenden Sicherheitsanforderungen zum internen Workflow umsetzengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 318 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02968 AS-BS-10110A_02969 AS-BS-10120A_00957 AS-BS-10130A_02970 AS-BS-10140A_02971 AS-BS-10150SSSSSTitel Beschreibung Rel. QuelleSec_Audit_06: Zeitstempel derAuditeinträge.Sec_Audit_07: Schreiben vonAuditeinträgen.Sec_Audit_08: Verhinderungdes Verlustes von Auditeinträgen.Sec_Audit_09: Auffindbarkeitvon Audit-Eintägen.Sec_Audit_10: Löschen vonAuditeinträgen.Der Audit Service ergänzt die übergebenen Protokollierungsinformationenum die aktuelle Uhrzeit. Jeder Audit-Eintrag besitzt deshalbeinen Zeitstempel für das WriteAudit [Diese Anforderung wirdin der nächsten Version des Übergreifenden Sicherheitskonzeptsnoch detailliert ]Das Schreiben von Audit-Einträgen MUSS immer möglich sein.Falls das Schreiben eines Audit Eintrags nicht möglich ist, MUSSsichergestellt sein, dass die auszuführende Aktion nicht ausgeführtwird.Ein Auditeintrag DARF NICHT auf dem Weg ins Auditprotokoll verlorengehen.Jeder Audit-Eintrag MUSS zeitnah wieder gefunden werden können.Es MUSS möglich sein, Audit-Einträge eines Versicherten zu löschen,wenn eine konfigurierbare Anzahl von Audit-Einträgen fürdiesen Versicherten überschritten ist und die Audit-Einträge älterals eine bestimmte Zeitspanne sind.Das Löschen MUSS von der „House-Keeping-Routine“ übernommenwerden.Sofern zum Zwecke der Datensicherung Audit-Einträge an anderenStellen gespeichert werden, MUSS das Löschen der Datenauch an diesen Stellen zuverlässig erfolgen; sollte diese Löschungaus technischen Gründen nicht möglich sein, MUSS nach jedemEinspielen eines Backups die House-Keeping-Routine ausgeführtwerden. Die notwendigen Maßnahmen MÜSSEN im Sicherheitskonzeptbeschrieben werden.AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 319 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02972 AS-BS-10160A_02973 AS-BS-10170A_02974 AS-BS-10180A_02975 AS-BS-10190A_02976 AS-BS-10200A_02977 AS-BS-10210SSSSSSTitel Beschreibung Rel. QuelleSec_Audit_11: Konfigurationdes Audit Service.Sec_Audit_12: Löschen vonAuditeinträgen durchÜberschreiben..Sec_Audit_13: Abrufbarkeitder letzten 50 Einträge.Sec_Audit_14: Verfügbarkeitvon Auditeinträgen.Sec_Audit_15: Protokollierungvon Löschvorgängen.Sec_Audit_16: In AuditServiceerfasste/Bereitgestellte Daten.Die Konfiguration des Audit Service MUSS mindestens folgendeElemente beinhalten:1. Maximale Anzahl der Audit-Einträge eines einzelnen Versicherten2. Maximales Alter von Audit-Einträgen eines einzelnen Versicherten3. Default-Level für das Logging-Framework4. Datenbank-Verbindungs-Informationen.Darüber hinaus KÖNNEN weitere Parameter konfigurierbar gehaltenwerden.Audit-Einträge im Audit Service DÜRFEN nur gelöscht werden,wenn durch Schreiben neuer Einträge die konfigurierte Maximalanzahlvon Einträgen überschritten wird und die Länge derZeitspanne der Mindestspeicherdauer überschritten ist.Im AuditS MÜSSEN für Zwecke der Datenschutzkontrolle die Protokolldatender Zugriffe auf Daten von Versicherten 1 Jahr langabrufbar seinDie Audit-Einträge DÜRFEN während ihrer vorgesehenen LebenszeitNICHT zerstört werden können. Das planmäßige Löschen mittelsder „House-Keeping-Routine“ wird hierdurch nicht eingeschränkt.Die Routine für das Löschen alter Audit-Einträge MUSS revisionsfähigprotokolliert werden.Es dürfen ausschließlich folgende Daten im versichertenzentriertenAuditdienst bereitgestellt werden:o WERo WANNo WAS (im Sinne: welche Anwendung)AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 320 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02978 AS-BS-10220A_02979 AS-BS-10230SSTitel Beschreibung Rel. QuelleSec_Audit_17 :Versicherter isteinziger Berechtigter für Lesezugriff.Sec_Audit_18: Integrität derAudit-Einträge.A_02980 S Sec_Audit_19: Schutz derAudit-Einträge.A_02981 S Sec_Audit_20: VerschlüsselteKommunikation mit beidseitigerAuthentisierung.A_02982 AS-BS-12170SSec_Audit_21: DetailliertesLogging im Fehlerfall.genutzt hat. Dies sind die Identität des Leistungserbringers, derZeitpunkt und der Typ des Fachdienstes.Eine unberechtigte Nutzung der Auditdaten (z. B. Profilbildungenüber Versicherte) MUSS durch Maßnahmen der Mechanismenstärkevon mindestens „hoch“ verhindert werden.Der Audit Service MUSS sicherstellen, dass der lesende Zugriff aufdas Audit-Log nur dem Versicherten selbst als einzig Berechtigtemmöglich ist.Die Modifikation oder das unautorisierte Löschen von Audit- EinträgenMUSS verhindert werden.Die Audit-Instanz MUSS den Schutz der Audit-Einträge sicherstellen.Der Audit verfügt über Schlüsselpaare und Zertifikate zur sicherenKommunikation (TLS/SSL) mit den Kommunikationspartnern.Alle übertragenen Daten MÜSSEN verschlüsselt werden. BeideKommunikationspartner MÜSSEN sich mittels SSL/TLS überClient- und Server-Zertifikate gegenseitig authentisieren.Das Zertifikat des jeweiligen Kommunikationspartners MUSS währenddes SSL-Handshakes über OCSP geprüft werden.Treten Fehler während der Ausführung des Audit Service auf, soMÜSSEN diese so detailliert wie erforderlich und erlaubt über dasLogging-Framework geloggt werden. Es MUSS sichergestellt sein,dass diese Logging-Daten nur zur Fehleranalyse verwendet werden.Im Fehlerfall MUSS die aktuelle Datenbank-Transaktion zurückgesetztwerden, so dass alle Änderungen des fehlgeschlagenen Audit-Requestszurückgesetzt werden.AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8AnhangB 4.6.8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 321 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.6.9 – VPN-KonzentratorAfo-ID Anfo ArtA_02983 AS-ZuN-7100A_02984 AS-ZuN-7110A_02985 AS-ZuN-7130A_02986 AS-ZuN-SSSSTitel Beschreibung Rel. QuelleSec_VPN_Konzentrator_01:Verhinderung des Abhörensvon Authentifizierungsgeheimnissen.Sec_VPN_Konzentrator_02:Verhinderung der Nutzungeines nicht autorisierten VPN-Gateways.Sec_VPN_Konzentrator_03:Keine Klartextprotokolle.Sec_VPN_Konzentrator_04:Keine Verbindungsanfragen inRichtung Konnektor.7140A_02987 S Sec_VPN_Konzentrator_05:Authentizität und Integrität derVPN Verbindungen.A_02988 S Sec_VPN_Konzentrator_06:Schutz der Konfigurationsdaten.A_02989 S Sec_VPN_Konzentrator_07:Prüfung der EingangsdatenA_02990 S Sec_VPN_Konzentrator_08:Key Management gemäßden gematik Richtlinien.A_02991 AS-ZuN-SSec_VPN_Konzentrator_09:Implementierung von Paketfil-Das Abhören von Authentifizierungsgeheimnissen zwischen Konnektorund VPN-Konzentrator MUSS durch geeignete Maßnahmenunterbunden werden.Die Verwendung eines nicht autorisierten VPN-Gateways MUSSgeeignet unterbunden werden.Klartextprotokolle wie Telnet oder FTP DÜRFEN NICHT eingesetztwerden.Alle Verbindungsanfragen in Richtung Konnektor MÜSSEN verhindertwerden. Die Verbindungsanfragen MÜSSEN immer vom Konnektoraus kommen.Es MUSS sichergestellt sein, dass die VPN Verbindungen authentischund integer sind.Der Schutz der Konfigurationsdaten (einschließlich Adressdaten)des VPN-Konzentrators MUSS berücksichtigt werden.Die Prüfung der Eingangsdaten beim VPN-Konzentrator MUSSberücksichtigt werden.Das Key Management beim VPN-Konzentrator MUSS gemäß dengematik Richtlinien erfolgen.Ein VPN-Konzentrator KANN eine Paketfilter-Funktionalität beinhalten.Es SOLL jedoch vor dem VPN-Konzentrator eine dedizierteAnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 322 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_02992 AS-ZuN-7210Titel Beschreibung Rel. Quelle7200 tern Firewall verwendet werden.SSec_VPN_Konzentrator_10:Schutz des VPN-Konzentrators vor physischenAngriffen.A_02993 S Sec_VPN_Konzentrator_11:Sichere Verwahrung vonSchlüsselmaterial.A_02994 AS-ZuN-7300A_02995 AS-ZuN-7310A_02996 AS-ZuN-7320A_02997 AS-ZuN-7330A_02998 AS-ZuN-7400A_02999 AS-ZuN-7500SSSSSSSec_VPN_Konzentrator_12:Remote Software Updatesüber sichere Verbindung.Sec_VPN_Konzentrator_13:Software Updates.Sec_VPN_Konzentrator_14:Sequenzkontrolle bei UpdatesSec_VPN_Konzentrator_15:Ausschluß von Backdoors.Sec_VPN_Konzentrator_16:Sichere Administration.Sec_VPN_Konzentrator_17:Beidseitige Authentisierung.Die Umgebung des VPN-Konzentrators MUSS physische Angriffevollständig abwehren.Es MUSS sichergestellt sein, dass das Schlüsselmaterial desVPN-Konzentrators sicher verwahrt ist. Des Weiteren MUSS gewährleistetsein, dass der VPN-Konzentrator in einer geschütztenUmgebung betrieben wird.Remote Software Updates des VPN-Konzentrators MÜSSEN übereine sichere Verbindung eingebracht werden.Die Quellen für ein Software Update des VPN-KonzentratorsMÜSSEN aus einer vertrauenswürdigen Quelle stammen und dieIntegrität MUSS vor dem Update erfolgreich geprüft werden.Der VPN-Konzentrator MUSS über eine Sequenzkontrolle (Aktivierungder neuen Software erst nach erfolgreicher Integritätsprüfungund erfolgreicher Installation) verfügen und die Wiederherstellungeines sicheren Zustands ermöglichen, falls es im Rahmen des Update-Prozesseszu Fehlern kommen sollte.Es MUSS sichergestellt sein, dass die Software über keine Backdoorsverfügt.Die Administration des VPN-Konzentrators MUSS sicher erfolgen.Der VPN-Konzentrator erzwingt eine sichere Authentisierung desAdministrators vor der Durchführung von administrativen Tätigkeitenund Wartungsarbeiten.Der VPN-Konzentrator MUSS eine gegenseitige Authentisierungder Endpunkte (VPN-Client im Netzkonnektor und VPN-Konzentrator) mit geeigneten Maßnahmen durchführen.AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 323 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03000 AS-ZuN-7520A_03001 AS-ZuN-7600A_03002 AS-ZuN-7610A_03003 AS-ZuN-7700A_03004 AS-ZuN-7710A_03005 AS-ZuN-7800A_03006 AS-ZuN-7810A_03007 AS-ZuN-7820SSSSSSSSTitel Beschreibung Rel. QuelleSec_VPN_Konzentrator_18:Sicherstellen von Vertraulichkeitund Integrität.Sec_VPN_Konzentrator_19:Echtzeituhr ist erforderlich.Sec_VPN_Konzentrator_20:Online-Prüfung von ZertifikatenSec_VPN_Konzentrator_21:Generierung von Log-Daten.Sec_VPN_Konzentrator_22:Logging von betriebsrelevantenDaten.Sec_VPN_Konzentrator_23:Erschweren von Manipulationenund Angriffen.Sec_VPN_Konzentrator_24:Löschen nicht mehr benötigterkryptographische Schlüssel.Sec_VPN_Konzentrator_25:Schutz von geheimen Datenvor unbefugter Kenntnisnahme.Die Nutzdaten, die über das VPN übertragen werden, MÜSSENhinsichtlich ihrer Vertraulichkeit und Integrität geschützt werden.Die Anforderungen des Kryptographiekonzepts der gematik MÜS-SEN berücksichtigt werden.Der VPN-Konzentrator MUSS über eine Echtzeituhr mit einer zuspezifizierenden Freilaufgenauigkeit verfügen.Online-Prüfung von Zertifikaten: Der VPN-Konzentrator MUSS dieGültigkeit von Zertifikaten aktuell überprüfen.Der VPN-Konzentrator MUSS erforderliche Log-Daten für einespätere Auswertung generieren.Der VPN-Konzentrator MUSS ein weiteres Logging von Ereignissen(z. B. Aufbau und Abbau von VPN-Verbindungen) durchführen,die für die Betriebsführung von Bedeutung sind.Der VPN-Konzentrator MUSS sich selbst und die ihm anvertrautenDaten durch Mechanismen schützen, die Manipulationen und Angriffeerschweren.Der VPN-Konzentrator MUSS nicht mehr benötigte kryptographischeSchlüssel (insbesondere Session Keys für die VPN-Verbindung) nach ihrer Verwendung durch aktives Überschreibenlöschen.Der VPN-Konzentrator MUSS Geheimnisse (insbesondere Schlüssel)während ihrer Verarbeitung gegen unbefugte Kenntnisnahmeschützen.AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9AnhangB 4.6.9gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 324 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturB4.6.10 – Trusted ServiceAfo-ID Anfo ArtA_03008 AS-BS-14100A_03009 AS-BS-14110A_03010 AS-BS-14130A_03011 AS-BS-14140A_03012 AS-BS-14150A_03013 AS-BS-1416SSSSSSTitel Beschreibung Rel. QuelleSec_VPN_Trusted_Service_01: Anonymisierung des HeilberuflersSec_VPN_Trusted_Service_02: Prüfung der Identität desHeilberuflers.Sec_VPN_Trusted_Service_03 :Fehlerbehandlung bei Anonymisieren/ Validieren.Sec_VPN_Trusted_Service_04: Kommunikation zwischenBroker Core-Instanz und BrokerSecurity-Instanz.Sec_VPN_Trusted_Service_05: Nutzung gemeinsamerHardware für SVS und SCS.Sec_VPN_Trusted_Service_06: Einschränkung der KommunikationTrustedService /Für Dienste, die eine Anonymisierung verlangen (z. B. VSDD),MUSS der Broker Service eine Anonymisierung des Heilberuflersdurchführen.Bei Anonymisierung des Heilberuflers MUSS der Trusted Servicedie Identität eines Heilberuflers anhand dessen Signatur, die Gültigkeitder kryptographischen Identität und seine Rolle überprüfenund die erfolgreiche Überprüfung bestätigen (Authentizität). Nacherfolgreicher Prüfung MÜSSEN die Signatur und das Zertifikat desHeilberuflers entfernt werden. Der Broker Service MUSS eine erfolgreicheValidierung des Security Validation Service (SVS) durcheine Signatur des Security Confirmation Service (SCS) bestätigenund die ursprüngliche Signatur entfernen.Treten Fehler beim Anonymisieren, beim Validieren der Nachrichtdurch den SVS oder dem Signieren durch den SCS auf, so MUSSder Trusted Service einen SOAP-Fehler an den aufrufenden BrokerService zurückgeben.Zusätzlich MUSS ein Logging-Eintrag erfolgen und Alarm ausgelöstwerden.Der Broker Service i. e. S. (d. h. die Broker Core-Instanz) MUSSmit der Broker Security-Instanz (d. h. dem Trusted Service) direktüber das lokale Netzwerk des Betreibers der Broker-Instanz kommunizieren.SVS und SCS KÖNNEN auf derselben Hardware-Instanz (SecurityServer) wie der Trusted Service betrieben werden, dabei MUSSallerdings die Einstufung der Services in Sicherheitszonen beachtetwerden.Es MUSS sichergestellt sein, dass der Trusted Service ausschließlichvom Broker Service aufgerufen werden kann. Der BetreiberMUSS Vorkehrungen treffen, dass die Service-Instanzen nur in-AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 325 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelle0 BrokerService nerhalb der Betreibernetze erreichbar sind und hier ausschließlichvon den Broker Service-Instanzen.A_03014 AS-BS-14170S Sec_VPN_Trusted_Service_07: Einschränkung der KommunikationTrustedService /SVS, SCS .Es MUSS sichergestellt sein, dass der Security Validation Service(SVS) und der Security Confirmation Service (SCS) nur vomTrusted Service erreichbar sind bzw. aufgerufen werden können,um Telematiknachrichten zu validieren bzw. zu signieren; SVS undSCS agieren dabei aus Sicht des Trusted Service als Service Provider.A_03015 AS-BS-14180A_03016 AS-BS-14190A_03017 AS-BS-14210A_03018 AS-BS-14220SSSSSec_VPN_Trusted_Service_08: Nutzung einer statischenService-URL für TrustedServiceSec_VPN_Trusted_Service_09: Nutzung einer statischenService-URL für SVS undSCS.Sec_VPN_Trusted_Service_10: Verschlüsselte Kommunikation.Sec_VPN_Trusted_Service_11: Nutzung eines speziell fürden TrustetService gehärtetenBetriebsystems.Die Adressierung des Trusted Service MUSS durch eine statischkonfigurierbare Service-URL unter Verwendung eines DNS-Namens, d. h. insbesondere, der Trusted Service wird nicht imRegistrierungsdienst (SDS) registriert, erfolgen. Dynamische Änderungender Adresse des Trusted Service während des laufendenBetriebs des Brokers SOLLEN durch Umkonfiguration im DNSServer für den Broker Service transparent durchgeführt werdenund bedingen dadurch keine Änderung am Broker Service.Wie der Trusted Service DÜRFEN auch SVS und SCS NICHT imRegistrierungsdienst (SDS) registriert werden, sondern MÜSSENggf. (d. h. bei Verwendung eines Web Service-Interface überHTTPS) nur über statisch konfigurierbare Service-URLs lokalisiertwerden. Alternativ KÖNNEN die Dienste auch lokal auf der gleichenMaschine betrieben und über andere Kommunikationsprotokolleangesprochen werden.Die Kommunikation zum Trusted Service MUSS verschlüsselt überHTTPS (TLS/SSL) erfolgen.Das Trusted Service MUSS auf einem für den spezifischenEinsatzzweck gehärtetem Betriebssystem betrieben werden.AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 326 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03019 AS-BS-14230A_03020 AS-BS-14250A_03021 AS-BS-14260A_03022 AS-BS-14270A_03023 AS-BS-14280A_03024 AS-BS-14290SSSSSSTitel Beschreibung Rel. QuelleSec_VPN_Trusted_Service_12: IntegritätsprüfungSec_VPN_Trusted_Service_13: Prüfung der Identität.Sec_VPN_Trusted_Service_14: Prüfung der Rolle.Sec_VPN_Trusted_Service_15: Online Prüfung der Zertifikate.Sec_VPN_Trusted_Service_16: Zertifikatsprüfung gemäßKettenmodel.Sec_VPN_Trusted_Service_17: Schutz der Integrität öffentlicherSchlüssel.A_03025 S Sec_VPN_Trusted_Service_18 :Signierung der Antwortenauf OCSP-Anfragen.Der Security Validation Service (SVS) MUSS die Integrität vonNachrichten durch Überprüfung der in ihnen enthaltenen Signaturenund Korrelation der durch die Signaturen bestätigten Informationenzueinander überprüfen.Es MUSS sichergestellt werden, dass der in der Telematiknachrichtgespeicherte Datenbearbeiter mit der im Zertifikat gespeichertenIdentität übereinstimmt.Es MUSS sichergestellt werden, dass die in der Telematiknachrichtgespeicherte Rolle des Datenbearbeiters mit der im Zertifikat gespeichertenRolle übereinstimmt.Es MUSS sichergestellt sein, dass vor der Anonymisierung dieSignatur des Datenbearbeiters in der Nachricht enthalten ist. Dadurchkann u. a. überprüft werden, dass die Anfrage von einemberechtigten Akteur stammt.Zur Validierung der sicherheitsrelevanten Informationen innerhalbeiner Telematiknachricht MUSS der SVS die Gültigkeit von Zertifikatenonline gegen die PKI-Infrastruktur der Telematik validieren.Die Zertifikatsprüfung MUSS nach dem Kettenmodell erfolgen.Der SVS setzt öffentliche Root-Schlüssel zur Prüfung von Signaturenund Zertifikaten ein. Die Integrität dieser Schlüssel MUSS geschütztwerden.Antworten auf OCSP-Anfragen MÜSSEN vom OCSP-Respondersigniert werden. Diese signierten Antworten MÜSSEN dann geprüftwerden.AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 327 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03026 AS-BS-14300A_03027 AS-BS-14310SSTitel Beschreibung Rel. QuelleSec_VPN_Trusted_Service_19 :Bestätigung von Authentizitätund Integrität.Sec_VPN_Trusted_Service_20: Signatur nur nach vorherigerValidierung.A_03028 S Sec_VPN_Trusted_Service_21: Schutz des privaten Schlüssels.Der Security Confirmation Service MUSS die Authentizität undIntegrität einer Telematiknachricht dadurch bestätigen, indem dieNachricht mit der Identität bzw. dem privaten Schlüssel „des Brokers“(des SCS als Teil der Brokerdienste) signiert wird.Der Security Confirmation Service (SCS) MUSS sicherstellen, dasser im Zuge der Anonymisierung der Heilberufler nur solche Nachrichtenmit der Signatur des Brokers versieht (und dadurch demFachdienst als authentisch markiert), die der SVS zuvor erfolgreichvalidiert hat.Der private Signatur-Schlüssel des SCS SOLL durch ein HardwareSicherheitsmodul (HSM) geschützt werden.AnhangB 4.6.10AnhangB 4.6.10AnhangB 4.6.10B4.6.11 – MPLS-BackboneAfo-ID Anfo ArtA_03029 AS-ZeN-5100A_03030 AS-ZeN-5110A_03031 AS-ZeN-5120SSSTitel Beschreibung Rel. QuelleSec_MPLS_Backbone_01:Verschlüsselte Kommunikation.Sec_ MPLS_Backbone _02:Sicherstellen von Vertraulichkeit.Sec_ MPLS_Backbone _03:Firewalls an externen Interfaces.Die Kommunikation der MPLS-Netz-Provider untereinander in e-lektronischer Form SOLL verschlüsselt übertragen geschehen.Falls die CE Router keine sichere Verbindung für administrativeZugriffe unterstützen, MÜSSEN Maßnahmen getroffen werden,welche Sicherheitsprobleme durch die unverschlüsselte Verbindungverhindern.Eingesetzte Firewalls SOLLEN an den externen Interfaces implementiertwerden.AnhangB 4.6.11AnhangB 4.6.11AnhangB 4.6.11gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 328 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturA_03032 AS-ZeN-5130SSec_ MPLS_Backbone _04:Firewalls MÜSSEN StatefulInspection unterstützenDie Firewalls MÜSSEN Stateful Inspection unterstützen.AnhangB 4.6.11B4.6.12 - Update Flag Service (UFS)/VSDDAfo-ID Anfo ArtA_01843 A_01843 SA_01845 A_01845 SA_01846 A_01846 STitel Beschreibung Rel. QuelleSec_ UpdateFlag_Service_01: Verbindungsaufbau nurüber sicheren Kanal.Sec_ UpdateFlag_Service_02: Sicherheitsalarm bei gescheiterterAuthentisierungSec_ UpdateFlag_Service_03: Bearbeitung von Sicherheitsalarmen.Es MUSS sichergestellt sein, dass bei einer Anfrage an den UpdateFlag Service nur ein Aufbauversuch für den sicheren Kanalzugelassen wird.Bei jeder gescheiterten Authentisierung durch Aufbau des sicherenKanals MUSS vom VSDD ein Sicherheitsalarm erzeugt und für dasSecurity-Incident-Management-System des Betreibers bereitgestelltwerden.Die durch gescheiterte Authentifikation bei Aufbau des sicherenKanals erzeugten Sicherheitsalarme MÜSSEN durch den Betreiberzeitnah untersucht, bei Häufungen den Ursachen dieser Vorfällenachgegangen und die gematik darüber informiert werden.AnhangB 4.6.12AnhangB 4.6.12AnhangB 4.6.12gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 329 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang C – SchutzbedarfsanalyseC1 - EinführungDie vorliegende Schutzbedarfsdarstellung bietet einen Überblick über die sicherheitstechnischeKritikalität von Informationsobjekten der neu zu schaffenden Telematikinfrastruktur.Diese allgemeine Abschätzung der Kritikalität dient als Hilfestellung zur Entscheidungüber grundlegende Sicherheitsanforderungen bzw. als Motivation für globale Anforderungenwie z. B. die Erstellung von Protection Profiles für bestimmte Schutzobjekte (z. B.eGK). Des Weiteren erfolgt eine Zuordnung der identifizierten Informationsobjekte zu Datenklassen,um einen sicherheitstechnischen effizienten Umgang bei einer späteren Bearbeitungzu ermöglichen (zur weiteren Information siehe auch Kapitel 5.3 und 7.3).C1.1 - Zielsetzung und EinordnungDas vorliegende Teildokument dient der Identifikation des Schutzbedarfes von fachlichenals auch technischen Informationsobjekten (siehe dazu Kapitel Informationsobjekte undDatenklassen) gem. der Definition der Schutzbedarfsdarstellung des IT-Grundschutzhandbuches des BSI:„Ziel der Schutzbedarfsfeststellung ist es, für jede erfasste IT-Anwendung einschließlichihrer Daten zu entscheiden, welchen Schutzbedarf sie bezüglich Vertraulichkeit, Integritätund Verfügbarkeit besitzt. Dieser Schutzbedarf orientiert sich an den möglichen Schäden,die mit einer Beeinträchtigung der betroffenen IT-Anwendung verbunden sind.“ (Anm.: dieListe der Schutzziele wurde für die Telematikinfrastruktur um Authentizität und Nichtabstreitbarkeiterweitert).Die Schutzbedarfsdarstellung der gematik wird in einem iterativen Prozess kontinuierlichauf Basis neuer fachlicher (z. B. neue Anwendungen/Informationsobjekte, rechtlicheRahmenbedingungen) oder grundlegender technischer Festlegungen (z. B. Einsatz einesKonnektors, Spezifikation eines Lokalisierungsdienstes, technischer Speicherort für fachlicheInformationsobjekte) angepasst bzw. erweitert.Eine Orientierung an den möglichen Schäden erfolgt in Übereinstimmung mit der in C1.3aufgeführten Tabelle.C1.2 - AbgrenzungDie vorliegende Schutzbedarfsdarstellung ist die Obermenge aller im Rahmen von vorangegangenenProjekten (b4h, protego.net, Telematik Referenzimplementierung etc.) erstelltenSchutzbedarfsdarstellungen.Die Schutzbedarfsdarstellung bezieht sich auf die im nachfolgenden Kapitel dargelegtenSchutzziele. Aus fachlicher Sicht besteht darüber hinaus ein Anspruch auf die Validität derverarbeiteten Daten sowie der Rechtssicherheit im Rahmen der Nutzung der Telematikinfrastruktur.Beide Aspekte können im Rahmen dieser Schutzbedarfsdarstellung nichtbehandelt werden. Die Validität erhobener bzw. verarbeiteter Daten muss im Rahmen derFachanwendungen bearbeitet werden und stellt keinen sicherheitstechnischen Aspektdar. Die Rechtssicherheit muss durch die Gestaltung von Geschäftsprozessen hergestelltgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 330 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturwerden, die im Rahmen der Schutzbedarfsdarstellung nicht behandelt werden. DieRechtssicherheit setzt allerdings die Revisionsfähigkeit voraus. Diese wird in der Schutzbedarfsdarstellungindirekt durch die Festlegung der Schutzziele Integrität, Authentizitätund Nichtabstreitbarkeit für Informationsobjekte (z. B. Audittrails) behandelt.C1.3 - Methodik der SchutzbedarfsfeststellungDer Schutzbedarf einzelner Informationsobjekte wird mit Hilfe einer Klassifizierung nachNiedrig, Mittel, Hoch und Sehr Hoch bzgl. der Schutzziele:festgelegt.• Vertraulichkeit (schließt Nutzungsfestlegung, Zugriffskontrolle bzw. Autorisierungmit ein)• Integrität,• Verfügbarkeit,• Authentizität (schließt Zurechenbarkeit bzw. Authentifizierung mit ein) und• NichtabstreitbarkeitFür das Schutzziel Verfügbarkeit wird je nach Typ des Objektes zwischen zwei Typenunterschieden:• Typ 1: Objekte deren Anforderungen an den Wiederherstellungszeitraum zwischeneiner Minute und maximal 6 Stunden liegen.• Typ 2: Objekte deren Anforderungen an den Wiederherstellungszeitraum zwischen6 Stunden und 14 Tagen liegen.Der Typ des jeweiligen Schutzbedarfes ist in Klammer angefügt (z. B. Verfügbarkeit (2)). 25Der für die einzelnen Schutzziele identifizierte Schutzbedarf formuliert allgemeine Anforderungenan die Qualität der Verarbeitungsprozesse des jeweils betroffenen Informationsobjektsfür die Schutzbedarfsklassen:• Niedrig• Mittel• Hoch• Sehr hochIm weiteren Verlauf dieses Dokuments wird für die Qualität der Verarbeitungsprozesseder Begriff Prozessqualität verwendet. Die Prozessqualität ist eine informelle Festlegungeines Qualitätsmerkmales des Verarbeitungsprozesses wobei keine Aussage über diedetaillierte Ausgestaltung (z. B. technische oder organisatorische Mechanismen) des Prozessesgetroffen wird.25 Ausblick: Im Rahmen der Verfeinerung des Sicherheitskonzepts ist geplant, dass Anforderungen an dieVerfügbarkeit nur noch in Ausnahmefällen im Siko formuliert werden, sondern in den Fachdokumenten weiterpräzisiert werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 331 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturEin Beispiel für eine Prozessqualität ist für das Schutzziel Integrität bei einem identifiziertenSchutzbedarf von „niedrig“: „Die Integritätsprüfung erfolgt nach Ermessen, Integritätsverletzungkönnen nicht eindeutig und zweifelsfrei erkannt werden“.Die als Grundlage zur Abschätzung des Schutzbedarfs herangezogenen Schadenskategoriensind in den nachfolgenden Tabelle aufgeführt. Sie basieren auf den in den IT-Grundschutzkatalogen des BSI und anderen Best Practices Sammlungen verwendetenSchadenkategorien.Tabelle 33: SchadenskategorierenSchutzbedarfsklassenSchaden niedrig mittel hoch sehr hochVerstoß gegen Verstöße gegenGesetze/Vorschriften/VGesetze sind nichtVorschriften underträge zu erwartenBeeinträchtigungdes informationellenSelbstbestimmungsrechtsBeeinträchtigungder persönlichenUnversehrtheitBeeinträchtigungder AufgabenerfüllungFundamentalerVerstoß gegen Vorschriftenund Gesetze.Vertragsverletzungensind nicht zuerwartenEs ist keine BeeinträchtigungdesinformationellenSelbstbestimmungsrechteszu erwartenEin MissbrauchpersonenbezogenerDaten erscheintnicht möglichEine Beeinträchtigungerscheint nichtmöglich.Eine Beeinträchtigungder Aufgabenerfüllungist nicht zuerwartenVerstöße gegenVorschriften undGesetze mit geringfügigenKonsequenzen.GeringfügigeVertragsverletzungenmit maximalgeringen Konventionalstrafen.Eine Beeinträchtigungdes informationellenSelbstbestimmungsrechtswürde durchden Einzelnen alstolerabel eingeschätztwerden.Ein möglicher MissbrauchpersonenbezogenerDatenhat nur geringfügigeAuswirkungen aufdie gesellschaftlicheStellung oder diewirtschaftlichenVerhältnisse desBetroffenen.Eine Beeinträchtigungerscheint nichtmöglich.Die Beeinträchtigungwürde von denBetroffenen alstolerabel eingeschätztwerden.Die maximal tolerierbareAusfallzeitist größer als 24Stunden.Verstöße gegenVorschriften undGesetze mit erheblichenKonsequenzen.Eine erheblicheBeeinträchtigungdes informationellenSelbstbestimmungsrechtsdes Einzelnenerscheint möglich.Ein möglicher MissbrauchpersonenbezogenerDatenhat erhebliche Auswirkungenauf diegesellschaftlicheStellung oder diewirtschaftlichenVerhältnisse desBetroffenen.Eine Beeinträchtigungder persönlichenUnversehrtheitkann nicht absolutausgeschlossenwerden.Die Beeinträchtigungwürde voneinzelnen Betroffenenals nicht tolerabeleingeschätzt.Die maximal tolerierbareAusfallzeitliegt zwischen einerund 24 Stunden.Vertragsverletzungenmit hohen Konventionalstrafen.Vertragsverletzungen,deren Haftungsschädenruinössind.Eine besondersbedeutende BeeinträchtigungdesinformationellenSelbstbestimmungsrechtsdes Einzelnenerscheint möglich.Ein möglicher MissbrauchpersonenbezogenerDatenwürde für den Betroffenenden gesellschaftlichenoderwirtschaftlichenRuin bedeuten.Gravierende Beeinträchtigungenderpersönlichen Unversehrtheitsindmöglich.Gefahr für Leib undLeben.Die Beeinträchtigungwird von denmeisten Betroffenenals nicht tolerabeleingeschätzt.Die maximal tolerierbareAusfallzeitliegt unter einerStunde.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 332 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturSchutzbedarfsklassenSchaden niedrig mittel hoch sehr hochNegative Außenwirkungen(Imageschaden)Finanzielle AuswirkungenEin Imageschadenist weder internnoch extern zu erwarten.Es sind keine finanziellenSchäden zuerwarten.Eine geringe bzw.nur interne Ansehens-oder Vertrauensbeeinträchtigungist zuerwarten.Der finanzielleSchaden bleibt fürdie Institution tolerabel.Eine breite Ansehens-oder Vertrauensbeeinträchtigungist zuerwarten.Eine landesweiteAnsehens- oderVertrauensbeeinträchtigung,evtl.sogar existenzgefährdenderArt, istdenkbar.Der Schaden bewirktbeachtliche Schaden ist für dieDer finanziellefinanzielle Verluste, Institution existenzbedrohend.ist jedoch nicht existenzbedrohend.Schutzobjekte können in anderen Schutzobjekten enthalten sein (Container). Dies führtnicht zwingend dazu, dass der Schutzbedarf des Containers auf den höchsten Schutzbedarfder in diesem enthaltenen Schutzobjekte erhöht werden muss. Allerdings ist bei derpraktischen Umsetzung und/oder der Formulierung von Sicherheitsanforderungen im Sicherheitskonzeptdarauf zu achten, dass der Schutzbedarf der enthaltenen Elementedurch die Behandlung des niedrigeren Schutzbedarfs des Containers nicht verletzt wird.Ist eine getrennte Behandlung der Schutzbedürfnisse von Container und Inhalt nicht möglich,dann muss der Schutzbedarf des Containers entsprechend erhöht werden!Zusammenfassend werden pro Schutzobjekt die allgemein notwendigen Schritte zur Erfüllungdes Schutzzieles formuliert.C.1.4 - Zusammenhang Schutzbedarfsfeststellung von Informationsobjektenund DatenklassenDer Zusammenhang zwischen Schutzbedarfsfeststellung eines Informationsobjekts undSchutzbedarfsfeststellung einer Datenklasse wird im Folgenden genauer formuliert:Die Schutzbedarfsfeststellung eines einzelnen Informationsobjekts kann die Eigenheitenund Rahmenbedingungen eines Informationsobjekts viel genauer berücksichtigen als diemehr pauschale Schutzbedarfsfeststellung einer Datenklasse. Liegt also zu einem einzelnenInformationsobjekt eine Schutzbedarfsfeststellung vor, so gilt diese uneingeschränkt.Die zusätzliche Zuordnung dieses Informationsobjekts zu einer Datenklasse ist daher unnötig.Die Schutzbedarfsfeststellung der Datenklassen dient dazu, Informationsobjekte für die(noch) keine Schutzbedarfsfeststellung vorliegt, schnell zu klassifizieren. Wird dann eineSchutzbedarfsfeststellung zu diesem Informationsobjekt erstellt, so wird die Zuordnungzur Datenklasse obsolet.Ziel ist es, zu jedem relevanten Informationsobjekt eine Schutzbedarfsfeststellung zu haben:Entweder eine genaue passend für dieses Informationsobjekt oder eine mehr pauschaleüber die Schutzbedarfsfeststellung der Datenklasse.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 333 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2 - Schutzbedarfsdarstellung 26Zu näheren Infomationen zu den Informationsobjekten siehe C4.1C2.1 - Io001 – VersichertendatenTyp des Schutzobjektes: InformationsobjektGrundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochID: Io001Die Versichertendaten sind personenbezogeneDaten: Die darauf zugreifenden Akteure der TI(Arzt, Krankenkasse usw.) haben die für personenbezogeneDaten übliche Vertraulichkeit einzuhalten(mittel).Die Anforderungen an die Integrität von personenbezogenenVersichertendaten sind mit hocheinzustufen, da Manipulationen verhindert werdenmüssen. (z. B. Veränderung des Namensdes Versicherten und somit erfolgt eine fehlerhafteZuordnung), um die fehlerfreie Nutzbarkeitder gespeicherten Daten sicherzustellen.Könnte als mittel eingestuft werden, weil ggf. einLeistungserbringer trotzdem den Versichertenbehandeln könnte (per Unterschrift verpflichtenzur Nachreichung der Daten, Barzahlung). Darüberhinaus besteht in Notfällen die Pflicht zurHilfeleistung. Allerdings sind zu lange oder häufigeAusfälle der TI oder einzelnen Dienste fürdie meisten Abläufe stark akzeptanzmindernd.Daher wird ein hoher Schutzbedarf festgelegt.Der Erzeuger (bzw. Übermittler) von Versichertendatenmuss zuordenbar sein. Ein Verlust derAuthentizität (Fälschung von Dokumenten) kannerhebliche negative Auswirkungen (Imageschäden,Akzeptanz eGK, …) haben, nicht authentischeVersichertendaten dürfen in der TInicht benutzt werden. Eine Aussage über dieAuthentizität der Daten auf dem Wege bis zumVSDD wird dadurch nicht getroffen.Ein Abstreiten der Erzeugung konkreter Versichertendaten,die im Rahmen eines Prozessesauf einer eGK oder über den VSDD verfügbargemacht werden, darf durch den Erzeuger nichtmöglich sein26 Einige Informationsobjekte sind nicht mehr aktuell und wurden daher gelöscht. Daher kann es zufehlenden Nummern, wie z. B. C2.30 kommen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 334 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.2 - Io002 – LeistungserbringerdatenTyp des Schutzobjektes: InformationsobjektID: Io002Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigr mittelhochr sehr hochniedrigr mittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Leistungserbringerdaten sind für die daraufzugreifenden Akteure der TI (wie Versicherter,KV usw.) bekannt; allerdings sindauch sie personenbezogen und somit ist dieVertraulichkeit mit mittel einzustufen.Die Anforderungen an die Integrität von personenbezogenenLeistungserbringerdaten sindmit hoch einzustufen, um Manipulationen vorzubeugen.Wird als niedrig eingestuft, weil ein Leistungserbringertrotz Nicht-Vorhandensein seinerDaten einen Versicherten (Sonderfall Apothekewird hier nicht betrachtet) behandelnkann. Die Abrechnung darüber kann spätererfolgen.Konkrete Leistungserbringerdaten müsseneinem Ersteller zuordenbar sein. Auf der aktuellenDetailtiefe der Daten- und Ablaufspezifikationist zwar direkt kein großer Schadenidentifizierbar. Allerdings haben im Anlassfallnachweislich nicht authentische Leistungserbringerdateneine sehr schlechte Außenwirkungzur Folge.Ein Abstreiten konkreter Leistungserbringerdatendie im Rahmen eines Prozesses aufeinem HBA oder über einen zentralen Datendienst(z. B. Directory-Service) verfügbar gemachtwerden, darf durch den Erzeuger nichtmöglich sein (siehe auch Authentizität).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 335 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.3 - Io004 - eVerordnung für ArzneimittelTyp des Schutzobjektes: InformationsobjektID: Io004Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEs enthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als besonders schützenswert zubetrachten sind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür die eVerordnung für Arzneimittel gilt einsehr hoher Schutzbedarf, denn z. B. die Manipulationeiner Medikation kann zum Schadenfür Leib und Leben führen.Wird als hoch angesehen, da ein Schadenfür Leib und Leben durch die Nicht-Verfügbarkeiteines eVerordnung nicht ausgeschlossenwerden kann.Aufgrund des besonderen Status medizinischerDaten muss der Ersteller einer eVerordnungaus Gründen der Revisionsfähigkeitund Rechtssicherheit eindeutig zuordenbarsein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit (für Leistungserbringer wieauch den Versicherten) darf der Erzeugereiner eVerordnung diese eVerordnung nichtabstreiten können.C2.3.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 336 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.4 - Io005 - Verordnung zur KrankenhausbehandlungTyp des Schutzobjektes: InformationsobjektID: Io005Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür diese Verordnung gilt ein mittlererSchutzbedarf, denn die Manipulation derDaten hat unter der Annahme von einer imKrankenhaus stattfindenden Plausibilitätsprüfungkeinen größeren Schaden (materiellwie körperlich) zur Folge.Wird als „mittel“ angesehen, denn ggf. kanneine neue Verordnung ausgestellt werdenbzw. ist eine Rücksprache mit dem Leistungserbringermöglich.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.4.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 337 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.5 - Io006 - Verordnung zur physikalischen Therapie und PodologenTyp des Schutzobjektes: InformationsobjektID: Io006Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür diese Verordnung gilt ein mittlererSchutzbedarf, denn die Manipulation derDaten hat vermutlich keinen größeren Schaden(materiell wie körperlich) zur Folge.Wird als mittel angesehen, denn ggf. kannsich der Versicherte eine neue Verordnungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.5.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 338 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.6 - Io007 - Verordnung zu Maßnahmen der Stimm-, Sprech- und SprachtherapieTyp des Schutzobjektes: InformationsobjektID: Io007Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür diese Verordnung gilt ein mittlererSchutzbedarf, denn die Manipulation derDaten hat keinen größeren Schaden (materiellwie körperlich) zur Folge.Wird als mittel angesehen, denn ggf. kannsich der Versicherte eine neue Verordnungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.6.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 339 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.7 - Io008 - Verordnung einer HörhilfeTyp des Schutzobjektes: InformationsobjektID: Io008Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür diese Verordnung gilt ein mittlererSchutzbedarf, denn die Manipulation derDaten hat keinen größeren Schaden (materiellwie körperlich) zur Folge.Wird als mittel angesehen, denn ggf. kannsich der Versicherte eine neue Verordnungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.7.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 340 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.8 - Io009 - Verordnung einer ErgotherapieTyp des Schutzobjektes: InformationsobjektID: Io009Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochniedrigrmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür diese Verordnung gilt ein mittlererSchutzbedarf, denn die Manipulation derDaten hat vermutlich keinen größeren Schaden(materiell wie körperlich) zur Folge.Wird als niedrig angesehen, denn ggf. kannsich der Versicherte eine neue Verordnungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.8.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 341 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.9 - Io010 - Verordnung einer SoziotherapieTyp des Schutzobjektes: InformationsobjektID: Io010Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür diese Verordnung gilt ein mittlererSchutzbedarf, denn die Manipulation derDaten hat keinen größeren Schaden (materiellwie körperlich) zur Folge.Wird als mittel angesehen, denn ggf. kannsich der Versicherte eine neue Verordnungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.9.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 342 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.10 - Io011 - Verordnung einer SehhilfeTyp des Schutzobjektes: InformationsobjektID: Io011Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür diese Verordnung gilt ein mittlererSchutzbedarf, denn die Manipulation derDaten hat keinen größeren Schaden (materiellwie körperlich) zur Folge.Wird als mittel angesehen, denn ggf. kannsich der Versicherte eine neue Verordnungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.10.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 343 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.11 - Io012 - Überweisung zum FacharztTyp des Schutzobjektes: InformationsobjektID: Io012Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür die Überweisung gilt ein niedriger bismittlerer Schutzbedarf, denn die Manipulationder Daten hat vermutlich keinen größerenSchaden (materiell wie körperlich) zurFolge.Wird als mittel angesehen, denn ggf. kannsich der Versicherte eine neue Überweisungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.11.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 344 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.12 - Io013 - Überweisung zum LaborTyp des Schutzobjektes: InformationsobjektID: Io013Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochFür die Überweisung gilt ein niedriger bismittlerer Schutzbedarf, denn die Manipulationder Daten hat vermutlich keinen größerenSchaden (materiell wie körperlich) zurFolge.Wird als mittel angesehen, denn ggf. kannsich der Versicherte eine neue Überweisungausstellen lassen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.C2.12.1 - Allgemeine Anforderungen/Weiteres VorgehenVerordnungen müssen im Rahmen der geltenden Rechtslage rechtsgültig von der verordnendenStelle digital signiert und dem Stand der Technik entsprechend so verschlüsseltwerden, dass ein technisches Abhören/technischer Zugriff durch unautorisierte Dritte ausgeschlossenwerden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 345 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.14 - Io015 – DispensierdatenTyp des Schutzobjektes: InformationsobjektID: Io015Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Dispensierdaten haben einen sehr hohenSchutzbedarf, denn die Manipulationdieser Daten kann größeren finanziellenSchaden zur Folge haben.Wird als hoch angesehen, da eine neuerlicheDispensierung einer bereits dispensierteneVerordnung problematisch erscheint.Eine detaillierte Betrachtung muss aber nochauf Basis der konkreten Abrechnungsabläufein der Telematikinfrastruktur durchgeführtwerden.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss ein entsprechenderDispensierdatensatz einem Ersteller zuordenbarsein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 346 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.15 - Io016 – NotfalldatenTyp des Schutzobjektes: InformationsobjektID: Io016Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Notfalldaten haben einen sehr hohenSchutzbedarf, denn die Manipulation dieserDaten kann größeren körperlichen Schadenzur Folge haben.Wird als hoch angesehen. Obwohl in Situationenmit Gefahr für Leib und Leben bei einerNicht-Verfügbarkeit von Notfalldaten gegenüberheute grundsätzlich keine schlechtereNotfallbehandlung gegeben sein wird, müssenfür jenen Prozentsatz an Notfallbehandlungendie nur durch die Verfügbarkeit derNotfalldaten zusätzlichen Schaden abwendenkonnten hohe Verfügbarkeitsanforderungengestellt werden.Da davon auszugehen ist, dass Notfalldatenbei Verfügbarkeit auch im Rahmen der Notfallbehandlungeingesetzt werden, ist einSchaden für Leib- und Leben nicht auszuschließen.Der Verursacher dieser Fehlinformationmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit identifizierbarsein.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann ein Akteur Notfalldaten erfasst hatgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 347 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.16 - Io017 – Elektronischer ArztbriefTyp des Schutzobjektes: InformationsobjektID: Io017Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten 27 (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDer elektronische Arztbrief hat einen sehrhohen Schutzbedarf. Die Manipulation dieserDaten kann zu einem schweren Schaden fürLeib und Leben führen.Wird als hoch angesehen, denn ggf. kannder elektronische Arztbrief wichtige Informationenfür den Arzt beinhalten und somitSchaden für Leib und Leben verhindern.Primär aus Gründen der Akzeptanz des e-lektronischen Arztbriefes durch den Leistungserbringerbesteht für die nachweislicheZuordenbarkeit von Arztbriefen zum Erstellerein sehr hoher Schutzbedarf.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer denBrief verfasst hat und wann das passiert ist.27 Der konkrete Inhalt des elektronischen Arztbriefs ist zurzeit noch nicht bekannt, allerdings wirdein Zusammenhang von Versichertendaten zu möglichen Erkrankungen angenommen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 348 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.17 - Io018 - Elektronische PatientenakteTyp des Schutzobjektes: InformationsobjektID: Io018Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten 28 , (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie elektronische Patientenakte hat einensehr hohen Schutzbedarf, denn die Manipulationdieser Daten kann größeren körperlichenSchaden zur Folge haben.Wird als hoch angesehen, denn ggf. kanndie elektronische Patientenakte wichtigeInformationen für den Arzt beinhalten undsomit Schaden für Leib und Leben verhindern.Eine Patientenakte (als Container für medizinischeEinträge) muss aus Gründen derRechtssicherheit und in weiterer Folge derRevisionsfähigkeit eindeutig dem Erstellerzuordenbar sein.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer diePatientenakte erstellt hat und wann diespassiert ist.C2.17.1 - Allgemeine Anforderungen/Weiteres VorgehenEs wird davon ausgegangen, dass der technische Container der die Patientenakte repräsentiertnoch keine vertraulichen medizinischen Daten beinhaltet bzw. alle vertraulichenmedizinischen Daten als „Eintrag in der Patientenakte“ behandelt werden (siehe SchutzbedarfsfeststellungIo019/Eintrag in die elektronische Patientenakte).28 Der konkrete Inhalt der elektronischen Patientenakte ist zurzeit noch nicht bekannt, allerdingswird ein Bezug von Versichertendaten zu medizinischen Punkten (Erkrankungen, Untersuchungenusw.) angenommen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 349 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.18 - Io019 - Eintrag in die elektronische PatientenakteTyp des Schutzobjektes: InformationsobjektID: Io019Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten 29 (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDer Eintrag in eine elektronische Patientenaktehat einen sehr hohen Schutzbedarf,denn die Manipulation des Eintrags kanngrößeren körperlichen Schaden zur Folgehaben.Wird als hoch angesehen, denn ggf. kannder Eintrag in die elektronische Patientenaktewichtige Informationen für den Arztbeinhalten und somit Schaden für Leib undLeben verhindern.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann einen Eintrag in die elektronische Patientenakteerstellt hat. Anm.: Es wird zwischendem Eintrag selbst und der Sichtbarkeitdes Eintrages unterschieden (sieheSchutzbedarfsfeststellung zu Io080 Sichtbarkeiteines Eintrages in der Patientenakte)Siehe Authentizität.29 Der konkrete Inhalt (und damit verbundenen Einträge) der elektronischen Patientenakte ist zurzeitnoch nicht bekannt, allerdings wird ein Bezug von Versichertendaten zu medizinischen Punkten(Erkrankungen, Untersuchungen usw.) angenommen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 350 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.19 - Io020 – ArzneimitteldokumentationTyp des Schutzobjektes: InformationsobjektID: Io020Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten 30 (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Arzneimitteldokumentation hat einensehr hohen Schutzbedarf, denn die Manipulationdieser Daten kann größeren körperlichenSchaden zur Folge haben.Wird als hoch angesehen, denn ggf. kanndie Arzneimitteldokumentation wichtige Informationenfür den Arzt beinhalten.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann die Arzneimitteldokumentation erstellthat.Siehe Authentizität.30 Der konkrete Inhalt der Arzneimitteldokumentation ist zurzeit noch nicht bekannt, allerdings wirdein Bezug von Versichertendaten zu Medikamenten angenommen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 351 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.20 - Io021 - Eintrag in die ArzneimitteldokumentationTyp des Schutzobjektes: InformationsobjektID: Io021Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochEnthält sensitive Daten 31 (Versichertendatenmit dem Bezug zu möglichen Krankheiten),welche als sehr schützenswert zu betrachtensind.IntegritätVerfügbarkeit(1)AuthentizitätWeil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann den Eintrag in die Arzneimitteldokumentationerstellt hat. Anm.: Es wird zwischendem Eintrag selbst und der Sichtbarkeitdes Eintrages unterschieden (sieheSchutzbedarfsfeststellung von Io082 Sichtbarkeiteines Eintrages in der Arzneimitteldokumentation).Nichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDer Eintrag in die Arzneimitteldokumentationhat einen sehr hohen Schutzbedarf, denn dieManipulation des Eintrags kann größerenkörperlichen Schaden zur Folge haben.Wird als hoch angesehen, denn ggf. kannder Eintrag in die Arzneimitteldokumentationwichtige Informationen für den Arzt beinhalten.Siehe Authentizität..31 Der konkrete Inhalt (bzw. deren Eintrag) der Arzneimitteldokumentation ist zurzeit noch nichtbekannt, allerdings wird ein Bezug von Versichertendaten zu Medikamenten angenommen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 352 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.21 - Io023 - Zugriffsprotokoll auf die eGKTyp des Schutzobjektes: InformationsobjektGrundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeitAuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochID: Io023Gemäß § 291a SGB V ist der Zugriff nurdem Versicherten vorbehalten.Die Integrität des Zugriffsprotokolls hat einensehr hohen Schutzbedarf, denn eine Manipulation(Löschung von Zugriffen) darf nichtmöglich sein.Die Verfügbarkeit des „Zugriffsprotokolls auf die eGK“ auf der eGKhängt von der Verfügbarkeit der eGK i.d.R. selbst ab 32 .Das Zugriffsprotokoll auf der eGK MUSS verfügbar sein, so lange dieeGK selbst verfügbar ist.r niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDer Erzeuger eines Eintrags im Zugriffsprotokolleiner eGK muss eindeutig zuordenbarsein.Aus Gründen der Nachvollziehbarkeit dürfenAuditdaten von auslösenden Personen nichtabgestritten werden können.32 Hiermit ist die technische Funktionsfähigkeit gemeint, da dies nicht gleichbedeutend mit der Verfügbarkeitder eGK ist.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 353 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.22 - Io099 - Private-Keys (Verschl. und Auth.) der eGKTyp des Schutzobjektes: InformationsobjektID: Io099Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist ggf. ein Zugriff auf vertraulicheDaten möglich.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität der Private-Keys hat einen hohenSchutzbedarf, denn eine Manipulationder Private-Keys führt entweder dazu, dasseine Authentifikation oder Ent- bzw. Verschlüsselungvertraulicher Daten nicht mehrmöglich ist. Anm.: Dieser Fall ist aber vonder Auswirkung mit einem physischen Defektder Karte vergleichbar.Wird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys kann der Versicherteseine Daten ver-/entschlüsseln.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit und Rechtssicherheitbestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 354 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.23 - Io025 – Zertifikate mit dazugehörigen Public-Keys der eGKTyp des Schutzobjektes: InformationsobjektID: Io025Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Zertifikate sind innerhalb des Gesamtsystems„öffentlich“ sollten aber nicht unbedingthinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn eineManipulation darf nicht möglich sein.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann ein Akteur wie z.B. ein Arzt Daten verschlüsseln oder Signaturenvon Versicherten überprüfen.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 355 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.24 - Io097 - CVC-Zertifikat und dazugehöriger Public-Key der eGKTyp des Schutzobjektes: InformationsobjektID: Io097Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDas Zertifikat ist innerhalb des Gesamtsystems„öffentlich“, sollte aber nicht unbedingthinausgelangen.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität des CVC-Zertifikats hat einensehr hohen Schutzbedarf, denn eine Manipulationdarf nicht möglich sein.Wird als hoch angesehen, denn nur Mithilfedes CVC-Zertifikats können sich eGK undHBA gegenseitig authentisieren.Der Erzeuger eines CVC-Zertifikats mussaus Gründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten CVC-Zertifikats vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 356 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.25 - Io098 - Private-Keys (Verschl. und Auth.) des HBATyp des Schutzobjektes: InformationsobjektID: Io098Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden können gefälschte HBA-Kartenauftauchen.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität der Private-Keys hat einen sehrhohen Schutzbedarf, denn eine Manipulationder Private-Keys führt entweder dazu, dasseine Authentifikation oder Ent- bzw. Verschlüsselungvertraulicher Daten nicht mehrmöglich ist. Anm.: Dieser Fall ist aber vonder Auswirkung mit einem physischen Defektder Karte vergleichbar.Wird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys kann der LeistungserbringerDaten entschlüsseln undZugriffsberechtigungen erlangen.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit und Rechtssicherheitbestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 357 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.26 - Io026 - Zertifikate mit dazugehörigen Public-Keys des HBATyp des Schutzobjektes: InformationsobjektID: Io026Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Zertifikate sind innerhalb des Gesamtsystems„öffentlich“ sollten aber nicht unbedingthinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn eineManipulation darf nicht möglich sein.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann ein Akteur wie z.B. ein Arzt Daten verschlüsseln oder Signaturenvon anderen Leistungserbringern ü-berprüfen.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys/Zertifikats vom Erstellernicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 358 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.27 - Io096 - CVC-Zertifikat und dazugehöriger Public-Key des HBATyp des Schutzobjektes: InformationsobjektID: Io096Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelrhochr sehr hochDie Zertifikate sind innerhalb des Gesamtsystems„öffentlich“, sollten aber nicht hinausgelangen.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität des CVC-Zertifikats hat einensehr hohen Schutzbedarf, denn eine Manipulationdarf nicht möglich sein.Wird als hoch angesehen, denn nur Mithilfedes CVC-Zertifikats können sich eGK undHBA gegenseitig authentisieren.Der Erzeuger eines CVC-Zertifikats mussaus Gründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten CVC-Zertifikats vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 359 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.28 - Io045 - PatientendatenTyp des Schutzobjektes: InformationsobjektID: Io045Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochBesitzen einen sehr hohen Schutzbedarf,denn die Daten beinhalten sensitive Informationen(Versicherte mit Bezug zu möglichenKrankheiten/Untersuchungen usw.),welche als sehr schützenswert zu betrachtensind.Ist mit sehr hoch angesetzt, weil die Manipulationder Daten Schaden für Leib undLeben zur Folge haben kann.Wird mit hoch angesetzt, weil bei Nicht-Verfügbarkeit der Patientendaten eine Behandlungvon Versicherten potentiell schwierigerwird.Der Erzeuger (bzw. Übermittler) von Versichertendatensollte zuordenbar sein.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann die Daten erfasst und ggf. verwaltethat.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 360 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.29 - Io046 – ProtokolleTyp des Schutzobjektes: InformationsobjektID: Io046Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochirrelevant -Bei (technischen) Protokollen kann nicht ausgeschlossenwerden, dass diese direkt oder indirekt(eine detaillierte Betrachtung muss für dieZielarchitektur durchgeführt werden) einenRückschluss auf vertrauliche Informationen bieten.Ein Schadenspotential bei fehlerhaften/mangelhaftentechnischen Protokollen ist aus demBlickwinkel der Systemsicherheit zwar gegeben,aber im Vergleich zu anderen Aspekten der Telematikinfrastrukturgering.Das Schadenspotential einer geringen Verfügbarkeitvon technischen Protokolldaten wird alsmittel eingestuft (wobei im Rahmen der Erstellungdes Betriebskonzepts bzw. der Sicherheitszertifizierungeines Rechenzentrumsbetriebszwischen einem temporär nicht möglichen Zugriffauf und dem generellen Fehlen von Protokollierungsinformationenzu unterscheiden ist).siehe Integrität.C2.29.1 - Allgemeine Anforderungen/Weiteres VorgehenIm Rahmen der Integrität kommen vor allem operationale Aspekte zum Tragen die imRahmen eines Betriebskonzepts sowie eines sicherheitszertifizierten (wie z. B. I-SO27002:2005) Betriebs behandelt werden müssen.Hinsichtlich der Verfügbarkeitsanforderungen von Protokollinformationen ist ein eigenes(technisches) Protokollierungskonzept notwendig auf dessen Basis eine detaillierter Abschätzungder Verfügbarkeits- und Integritätsanforderungen möglich ist.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 361 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.31 - Io049 - Elektronische Signatur des LeistungserbringersTyp des Schutzobjektes: InformationsobjektID: Io049Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Signaturen sind nur innerhalb eines Teilsdes Gesamtsystems „öffentlich“ und solltennicht aus einem geschlossenen System, wieder TI gelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochIst mit sehr hoch anzusetzen, weil die Manipulationder elektronischen Signatur zur Folgehaben könnte, dass Daten nicht mehr aufihre Authentizität und Integrität überprüfbarsind.Wird mit hoch angesetzt, weil die elektronischeSignatur einem Empfänger ermöglichetdie Authentizität und Integrität der Datenzu überprüfen. Ist diese nicht vorhanden,kann man den empfangenen Daten nichtvertrauen.Siehe Nichtabstreitbarkeit.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann die Daten signiert hat.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 362 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.32 - Io050 - Elektronische Signatur des VersichertenTyp des Schutzobjektes: InformationsobjektID: Io050Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Signaturen sind nur innerhalb eines Teilsdes Gesamtsystems „öffentlich“, allerdingsmuss ein „Missbrauch“ der Signatur (Erstellungvon Profilen) verhindert werden.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochIst mit sehr hoch anzusetzen, weil die Manipulationder elektronischen Signatur zur Folgehaben könnte, dass Daten nicht mehr aufihre Authentizität und Integrität überprüfbarsind.Wird mit sehr angesetzt, weil die elektronischeSignatur einem Empfänger ermöglichetdie Authentizität und Integrität der Datenzu überprüfen. Ist diese nicht vorhanden,kann man den empfangenen Daten nichtvertrauen.Siehe Nichtabstreitbarkeit.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann die Daten signiert hat.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 363 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.33 - Io048 - Verordnung von SprechstundenbedarfTyp des Schutzobjektes: InformationsobjektID: Io048Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelhochr sehr hochniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochEnthält keine sensitiven Daten, deshalb hatsie nur einen niedrigen Schutzbedarf.Für diese Verordnung gilt ein hoher Schutzbedarf,denn die Manipulation der Datenkann beträchtlichen Schaden (materiell) zurFolge haben.Wird als niedrig angesehen, denn ggf. kanndie Verordnung erneut ausgestellt werden.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss eine entsprechendeVerordnung einem Ersteller zuordenbar sein.Der Schaden, der durch ein erfolgreichesAbstreiten einer entsprechenden Verordnungentsteht liegt primär in der Akzeptanzsenkungaufgrund der sinkenden Revisionsfähigkeitund Rechtssicherheit.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 364 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.34 - Io052 – PatientenquittungTyp des Schutzobjektes: InformationsobjektID: Io052Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochniedrigr mittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochGibt Auskunft über Transaktionen im Bereichdes Gesundheitswesens und ggf. auch übersensitive Daten (Versichertendaten mit demBezug zu möglichen Krankheiten auf Basisder gegebenen Medikation).Für die Quittung gilt nur ein mittlerer Schutzbedarf,denn die Manipulation der Daten hatkeinen größeren Schaden (materiell wie körperlich)zur Folge.Wird als niedrig angesehen, denn ggf. kannsich der Versicherte eine neue Quittung ausstellenlassen bzw. wird davon ausgegangen,dass der Zugriff auf Quittungen keinenkritischen Zeitrestriktionen unterliegt.Aus Gründen der Revisionsfähigkeit undRechtssicherheit sollte der Erzeuger einerQuittung zuordenbar sein. Ein mittlererSchutzbedarf wird angenommen, da primärvon einem überschaubaren finanziellenSchaden verursacht durch nicht authentischeQuittungen ausgegangen wirdsiehe Authentizität.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 365 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.35 - Io053 – Geschützte VersichertendatenTyp des Schutzobjektes: InformationsobjektID: Io053Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hoch..Die geschützten Versichertendaten könnenAuskunft über die wirtschaftliche Situationoder über chronische Krankheiten des Versichertengeben. Beispiele hierfür sind derZuzahlungsstatus oder das DMP-Kennzeichen.Mit den geschützten Versichertendaten wiez. B. dem Zuzahlungsstatus wird ein wesentlichesElement zur Minderung von unberechtigterInanspruchnahme von Leistungenangesehen. Zum einen können Integritätsverletzungeneine unberechtigte Inanspruchnahmeermöglichen bzw. kann umgekehrtnicht ausgeschlossen werden, dass beieinem falschen Zuzahlungsstatus eine berechtigteInanspruchnahme von Leistungnicht möglich ist.Da eine Prüfung der geschützten Versichertendatentendenziell bei jeder Inanspruchnahmevon Leistungen erfolgt, muss eineentsprechend hohe Verfügbarkeit gewährleistetwerden.Der Ersteller von geschützten Versichertendatenmuss zuordenbar sein.siehe Authentizität.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 366 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.36 - Io054 – Pseudonym eines VersichertenTyp des Schutzobjektes: InformationsobjektID: Io054Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätr niedrigr mittelhochr sehr hochEine Vertraulichkeitsverletzung des Pseudonymsführt zu keinem Schaden, da a priorinoch keine Zuordnung zur Person möglichist. Erst in Kombination mit anderen Informationen(z. B. Datum über Arztbesuche etc.)erhöht sich das Schadenspotential. Des Weiterenwird eine hohe Mechanismenstärke fürdas Pseudonymisierungsverfahren verlangt,daher kann die Vertraulichkeit auf mittel gesetztwerden.Die Integrität hat einen hohen Schutzbedarf,denn eine Manipulation des Pseudonymskönnte u. a. ein korrektes Arbeiten verhindern.Verfügbarkeit irrelevant -AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDer Erstellungsprozess/Ersteller eines konkretenPseudonyms muss zuordenbar sein.Der Erstellungsprozess/Ersteller eines konkretenPseudonyms muss zuordenbar seingematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 367 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.37 - Io055 – KrankenversichertennummerTyp des Schutzobjektes: InformationsobjektID: Io055Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochDie Krankenversichertennummer per sestellt keine kritische Information dar. Profilbildungmuss aber verhindert werden!Eine „falsche“ (d. h. nicht zum die Nummervorlegenden Versicherten gehörende) Krankenversichertennummerhat primär das Potentialeinen überschaubaren finanziellenSchaden zu generieren (d. h. unberechtigterLeistungsbezug). Der Schutzbedarf kannaber je nach Speicherort (z. B. eGK, Primärsystem)in dem es zur Integritätsverletzungkommt unterschiedlich sein. Eine entsprechendeBehandlung muss auf Basis derkonkreten Architektur erfolgen.Da die Krankenversichertennummer auchohne Karte Funktionen hat (z .B. bei der Benennungvon Vertretern im ObjektTicket)sollte sie zuverlässig zur Verfügung stehen.Im Rahmen der Revisionsfähigkeit undRechtssicherheit muss die Zuordnung einerkonkreten Krankenversichertennummer zumErzeuger möglich sein, wobei aus der Sichtder Telematikinfrastruktur zum aktuellenZeitpunkt von einem geringen Schadenspotentialausgegangen wird.siehe Authentizität.C2.37.1 - Allgemeine Anforderungen/Weiteres VorgehenEin direkter Zugriff auf Informationsobjekte mit einem Schutzbedarf höher als „mittel“ unterausschließlicher Kenntnis der Krankenversichertennummer darf nicht möglich sein.Kritisch wird in diesem Zusammenhang die Integrität einer Kombination einer konkretenKrankenversichertennummer und eines konkreten kryptographischen Schlüssels angesehen(z. B. darf der Austausch/Manipulation der Krankenversicherungsnummer auf dereGK nicht dazu führen, dass ein Zugriff auf medizinische Daten eines anderen Versichertenmöglich wird, der „zufällig“ denselben kryptographischen Schlüssel besitzt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 368 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.38 - Io060 – Versichertenzentriertes Audit (Liste der Einträge eines Versicherten)Typ des Schutzobjektes: InformationsobjektID: Io060Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDas versichertenzentrierte Audit (Liste allerEinträge eines Versicherten) gibt detaillierteAuskunft über vertrauliche Daten eines Versicherten,deren Bekanntgabe einen bedeutsamenSchaden für die betroffene Personhaben kann. Daher wird ein hoher Schutzbedarffestgelegt.Aus Gründen der Nachvollziehbarkeit gilt einhoher Schutzbedarf für Auditdaten.Wird als mittel angesehen, da keine besonderenzeitlichen Rahmenbedingungen für dieVerfügbarkeit definiert sind, wobei allgemeindavon auszugehen ist, dass Auditdaten imnicht vorhersehbaren Anlassfall zeitnah zurVerfügung stehen.Aus Gründen der Nachvollziehbarkeit mussder Erzeuger von Auditdaten eindeutig bestimmbarsein.Aus Gründen der Nachvollziehbarkeit dürfenAuditdaten von auslösenden Personen nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 369 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.39 - Io061 – AutorisierungsinformationenTyp des Schutzobjektes: InformationsobjektID: Io061Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochAutorisierungsinformationen sind aus fachlicherSicht allgemein als unbedenklich anzusehen.Da es sich aber um Informationenhandelt, die zum einen möglicherweise Auskunftauf Beziehungen zwischen Akteuren(z. B. Versicherter/Leistungserbringer) undzum anderen im Rahmen der Planung einerböswilligen Aktion Auskunft über potentielleAngriffspunkte geben können, wird derSchutzbedarf mit „mittel“ statt mit niedrigangesetzt. Des Weiteren wird eine hohe Mechanismenstärkefür das Pseudonymisierungsverfahrenverlangt, daher kann dieVertraulichkeit auf mittel gesetzt werden.Integritätsverletzungen haben das Potentialfachlich unautorisierten Zugriff auf Informationsobjektezu gewähren oder umgekehrtfachlich autorisierten den benötigten Zugriffzu verweigern.Aufgrund der zentralen Bedeutung vonZugriffskontrollinformationen für Abläufe inder Telematikinfrastruktur, die einen Zugriffauf Informationsobjekte mit einem sehr hohenSchutzbedarf realisieren müssen, müssenauch die Autorisierungsinformationenzumindest hohen Verfügbarkeitsanforderungengenügen.Aus Gründen der Revisionsfähigkeit undRechtssicherheit muss der Erzeuger vonAutorisierungsinformationen eindeutig bestimmbarsein.Weil es in einem möglichen Rechtsstreit zuordenbar(beweisbar) sein muss, wer undwann Zugriffskontrollinformationen verändert/erzeugthat.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 370 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.40 - Io063 – Sperrlisten: Qualifizierte ZertifikateTyp des Schutzobjektes: InformationsobjektID: Io063Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Sperrlisten sind zwar innerhalb des Gesamtsystems„öffentlich“, sollten aber nichthinaus gelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochAus Gründen der Revisionsfähigkeit undRechtssicherheit führt eine Integritätsverletzungder Sperrlisten zu einem sehr hohenSchaden, da möglicherweise ein konkreterSignaturschlüssel nach dessen Sperre eingesetztwurde.Für die Sperrliste gelten hohe Verfügbarkeitsanforderungen,da davon ausgegangenwird, dass im Rahmen der Ablauflogik auchkeine Signaturfunktionen (Online) bzw. dessenÜberprüfung durchführbar sind, wennkeine Aussage über Sperrinformationen abgerufenwerden kann.Eine konkrete Sperrliste muss einem Erzeugerzuordenbar sein. Anm.: Jeder einzelneEintrag in einer Sperrliste sollte dem Erzeugerzuordenbar sein.Ein Erzeuger einer Sperrliste bzw. einesEintrages darf aus Gründen der Revisionsfähigkeitund Rechtssicherheit diesen Vorgangnicht abstreiten können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 371 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.41 - Io064 – Sperrlisten: eGKTyp des Schutzobjektes: InformationsobjektID: Io064Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Sperrlisten sind zwar innerhalb des Gesamtsystems„öffentlich“, sollten aber nichthinaus gelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochAus Gründen der Revisionsfähigkeit undRechtssicherheit führt eine Integritätsverletzungder Sperrlisten zu einem hohen Schaden,da möglicherweise medizinische Leistungenmit gesperrten Karten bezogen werdenkönnen.Für die Sperrliste gelten hohe Verfügbarkeitsanforderungen,da davon ausgegangenwird, dass im Rahmen der Ablauflogik auchkeine Signaturfunktionen durchführbar sindwenn keine Aussage über Sperrinformationenabgerufen werden können.Eine konkrete Sperrliste muss einem Erzeugerzuordenbar sein. Anm.: Jeder einzelneEintrag in einer Sperrliste sollte dem Erzeugerzuordenbar sein.Ein Erzeuger einer Sperrliste bzw. einesEintrages darf aus Gründen der Revisionsfähigkeitund Rechtssicherheit diesen Vorgangnicht abstreiten können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 372 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.42 - Io065 – Sperrlisten: HBATyp des Schutzobjektes: InformationsobjektID: Io065Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Sperrlisten sind zwar innerhalb des Gesamtsystems„öffentlich“, sollten aber nichthinaus gelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochAus Gründen der Revisionsfähigkeit undRechtssicherheit führt eine Integritätsverletzungder Sperrlisten zu einem hohen Schaden,da möglicherweise z. B. Verordnungenmit gesperrten Karten ausgestellt werdenkönnen.Für die Sperrliste gelten hohe Verfügbarkeitsanforderungen,da davon ausgegangenwird, dass im Rahmen der Ablauflogik auchkeine Signaturfunktionen durchführbar sindwenn keine Aussage über Sperrinformationenabgerufen werden können.Eine konkrete Sperrliste muss einem Erzeugerzuordenbar sein. Anm.: Jeder einzelneEintrag in einer Sperrliste sollte dem Erzeugerzuordenbar sein.Ein Erzeuger einer Sperrliste bzw. einesEintrages darf aus Gründen der Revisionsfähigkeitund Rechtssicherheit diesen Vorgangnicht abstreiten können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 373 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.43 - Io066 – Temporäre SchlüsselTyp des Schutzobjektes: InformationsobjektID: Io066Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätr niedrigmittelr hochr sehr hochObwohl eine Kompromittierung vertraulicherDaten möglich ist, bleibt die schadhafteAuswirkung begrenzt und überschaubar, dader Schaden sich nur auf die Dauer einerSession beschränkt. Da aber davon ausgegangenwerden muss, dass der Sessionkeyauch den Klartext hochsensibler Datenschützen können soll, wird ein hoherSchutzbedarf festgelegt.Eine Integritätsverletzung eines temporärenSchlüssels führt zur fehlerhaften Chiffrenoder fehlerhaftem Klartext. Die schadhafteAuswirkung ist begrenzt und überschaubar.Verfügbarkeit irrelevant Anm.: kann allgemein nicht definiert werden,da die Verfügbarkeit für diese Schlüssel unterschiedlichsein kann.AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochirrelevant -Wird mit hoch eingestuft, um den Schutz vorAngriffen (z. B. Man-in-the-Middle Attacke)beim Schlüsselaustausch zu verhindern.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 374 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.44 - Io067 – Statische SchlüsselTyp des Schutzobjektes: InformationsobjektID: Io067Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDa der symmetrische Schlüssel vertraulichemedizinische Daten schützt, weist eineKompromittierung dieses Schlüssels ein erheblichesSchadenspotential auf. Daher wirdder Schutzbedarf mit sehr hoch eingestuft.Die Verletzung der Integrität eines statischenSchlüssels führt primär dazu, dass auf dieverschlüsselten Informationen nicht mehrzugegriffen werden kann. Aus diesem Grundwird Integrität wie der Schutzbedarf für „Verfügbarkeit“angesehen und daher auf hochgesetzt.Da die Verfügbarkeit der statischen Schlüsselgleichbedeutend mit der Verfügbarkeitder verschlüsselten Inhalte ist, wird hier einhoher Schutzbedarf angesetzt.Der Erzeuger bzw. erzeugende Prozess einesstatischen Schlüssels zur Verschlüsselungmedizinischer Daten muss bestimmbarsein.Der Erzeuger eines statischen Schlüsselsdarf dessen Erzeugung nicht abstreiten können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 375 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.45 - Io068 – CAMS-SchlüsselTyp des Schutzobjektes: InformationsobjektID: Io068Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochDer CAMS-Schlüssel ermöglicht die Autorisierungvon Kartenapplikationen und besitztaufgrund des sehr hohen potentiellen Schadens(Revisionsfähigkeit und Rechtssicherheiteiner Vielzahl von Abläufen in der Telematikinfrastruktursind dann nicht mehr gewährleistet)einen sehr hohen Schutzbedarf.Eine Integritätsverletzung des CAMS-Schlüssels hat ein hohes Schadenspotentialwobei der Schaden nicht unmittelbar dieRevisionsfähigkeit und Rechtssicherheit allerAbläufe der Telematikinfrastruktur betrifft.Daher wird der Schutzbedarf nur mit hocheingestuft.Es wird davon ausgegangen, dass derCAMS-Schlüssel im laufenden Betrieb eineelementare funktionale Rolle spielt und zurVerarbeitung von mindestens einem anderenInformationsobjekt benötigt wird, dass einesehr hohe Verfügbarkeitsanforderungen hat.Die Herkunft und der Entstehungsprozesseines konkreten CAMS-Schlüssels müsseneindeutig bestimmbar sein.Der Ersteller eines konkreten CAMS-Schlüsselsdarf dessen Erstellung nicht abstreitenkönnen.C2.45.1 - Allgemeine Anforderungen/Weiteres VorgehenAufgrund des Potentials des CAMS die Firmware/Daten sämtlicher im Umlauf befindlichenKarten zu verändern sind für das CAMS und die Nutzung dessen Schlüssel besondersstrenge Sicherheitsvorkehrungen zu treffen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 376 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.46 - Io069 – Master-SchlüsselTyp des Schutzobjektes: InformationsobjektID: Io069Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochDer Master-Schlüssel ermöglicht die Ausstellungvon Zertifikaten und besitzt aufgrunddes sehr hohen potentiellen Schadens (Revisionsfähigkeitund Rechtssicherheit einerVielzahl von Abläufen in der Telematikinfrastruktursind dann nicht mehr gewährleistet)einen sehr hohen Schutzbedarf.Eine Integritätsverletzung des Master-Schlüssels hat ein hohes Schadenspotentialwobei der Schaden nicht unmittelbar dieRevisionsfähigkeit und Rechtssicherheitaller Abläufe der Telematikinfrastruktur betrifft.Daher wird der Schutzbedarf nur mithoch eingestuft.Es wird davon ausgegangen, dass der Master-Schlüsselim laufenden Betrieb eine elementarefunktionale Rolle spielt und zur Verarbeitungvon mindestens einem anderenInformationsobjekt benötigt wird, dass einesehr hohe Verfügbarkeitsanforderungen hat.Die Herkunft und der Entstehungsprozesseines konkreten Master-Schlüssels müsseneindeutig bestimmbar sein.Der Ersteller eines konkreten Master-Schlüssels darf dessen Erstellung nicht abstreitenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 377 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.47 - Io072 – Verwendete Software (TI)Typ des Schutzobjektes: InformationsobjektID: Io072Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätr niedrigr mittelhochr sehr hoch„Security by Obscurity“ wird im technischenBereich als eine nicht zielführende Vorgehensweiseangesehen.Da es sich bei der Software zum Teil umFirmengeheimnisse handelt, trotzdem hoch.Auch die Software-Prüfer haben den Codevertraulich zu behandelnBei Integritätsverletzung von sicherheitsrelevantemProgrammcode besteht das Risikovon Vertrauensverletzungen. Auch Gefahrfür Leib- und Leben kann nicht ausgeschlossenwerden.Verfügbarkeit irrelevant -AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochirrelevant -Der Schaden beim Einsatz von Programmcodedessen Herkunft nicht nachvollziehbarist, bietet dasselbe Schadenspotential wiebei Integritätsverletzungen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 378 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.48 - Io070 – Signatur-PINTyp des Schutzobjektes: InformationsobjektID: Io070Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(2)AuthentizitätDa eine Nicht-Verfügbarkeit der Signatur-PIN den Zugang auf sämtliche Signaturfunktionenunterbindet, ist der Schutzbedarf fürdie Verfügbarkeit der PIN mit hoch anzusetzen.Nichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Signatur-PIN (sowohl bei der eGK alsauch bei der HBA) stellt den einzigenZugriffsschutz für die Signatur-Funktion derjeweiligen Karte mit dem Private-Key desInhabers dar.Eine böswillige unautorisierte Veränderungder PIN hat das selbe Schadenspotential wieeine Vertraulichkeitsverletzung (den unautorisiertenZugriff auf die Signierfunktion mitdem jeweiligen Private-Key)Siehe Integrität.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf eine konkrete PIN(bzw. die Durchführung des PIN-Änderungsprozesses) vom Ändernden nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 379 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.49 - Io071 – Authentifikations-PINTyp des Schutzobjektes: InformationsobjektID: Io071Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeitAuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Authentifikations-PIN (vor allem bei dereGK) stellt den primären Zugriffsschutz fürden Zugriff auf vertrauliche medizinischeDaten dar. Da hier mindestens ein vertraulichesInformationsobjekt einen sehr hohenSchutzbedarf hat, ist gilt der entsprechendSchutzbedarf auch für die Authentifikations-PIN sehr hoch.Eine böswillige unautorisierte Veränderungder PIN hat dasselbe Schadenspotential wieeine Vertraulichkeitsverletzung (den unautorisiertenZugriff auf vertrauliche medizinischeDaten).Da eine Nicht-Verfügbarkeit der Authentifikations-PINmöglicherweise den Zugang aufSignaturfunktionen unterbindet ist derSchutzbedarf für die Verfügbarkeit der PINmit hoch anzusetzen.Siehe Integrität.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf eine konkrete PIN(bzw. die Durchführung des PIN-Änderungsprozesses) vom Ändernden nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 380 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.50 - Io073 – Verschlüsselte, signierte medizinische DatenTyp des Schutzobjektes: InformationsobjektID: Io073Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochUnter der Annahme einer adäquaten Stärkeder gewählten Verschlüsselungsalgorithmenbesitzt der Ciphertext geringe Vertraulichkeitsanforderungen.Ein Schutzbedarf von„mittel“ wurde aus dem (geringen) Restrisikovon Bruteforce-Angriffen, Known-PlaintextAngriffen bzw. der Möglichkeit Ciphertextsolange kopiert aufzubewahren bis ein Entschlüsselnmöglich ist, gewählt.Eine Entschlüsselung der Chiffre ist auch beieiner manipulierten Chiffre möglich. Aus derSicht des Schutzbedarfes für die medizinischenChiffren wird davon ausgegangen,dass die Integritätsanforderungen für diedurch den Klartext repräsentierten Informationsobjektezusätzlich und explizit geprüftwerden. Zur Untermauerung dieser Annahmewird ein hoher Schutzbedarf festgelegt.Könnte als mittel eingestuft werden, weil ggf.ein Leistungserbringer trotzdem den Versichertenbehandeln könnte. Allerdings sind zulange oder häufige Ausfälle der TI oder einzelnenDienste für die meisten Abläufe starkakzeptanzmindernd. Daher wird ein hoherSchutzbedarf festgelegt.Die medizinischen Informationsobjekte sindinnerhalb einer gültigen PKI signiert. Daherkeine weitergehenden Anforderungen.Die medizinischen Informationsobjekte sindvon ihrem Erzeuger verifizierbar signiert.Damit sind sie eindeutig zuzuordnen, keineweitergehenden Anforderungen.C2.50.1 - Allgemeine Anforderungen/Weiteres VorgehenDer Schutzbedarf des Grundwertes Integrität des Klartextes der medizinischen Datenmuss prüfbar sein.Eine Integritätsverletzung des Klartextes der medizinischen Daten von zur Erbringungeiner medizinischen Leistung (z. B. Röntgenbild, Hämatologischer Befund) muss demLeistungserbringer deutlich dargelegt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 381 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.52 - Io100 - Private-Key (Signatur) der eGKTyp des Schutzobjektes: InformationsobjektID: Io100Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDer Private-Key besitzt einen sehr hohenSchutzbedarf, denn sollte er kompromittiertwerden, ist er nicht mehr vertrauenswürdig.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität des Private-Key hat einen sehrhohen Schutzbedarf, denn eine Manipulationdes Private-Keys führt dazu, das ungültigeSignaturen erstellt werden, die im Rahmender Prüfung von Signaturen zumindest zueinem späteren Zeitpunkt identifizierbar sindaber möglicherweise im Rahmen eines Ablaufeszum Zeitpunkt der Nutzung einen bedeutsamenSchaden erzeugen können.Wird als hoch angesehen, denn nur bei Vorhandenseindes Private-Key kann der Versichertesignieren.Der Erzeuger eines Private-Key muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Key vom Ersteller nichtabgestritten werden können. Die Existenzvon korrekt ausgestellten Private-Keys, fürdie der Aussteller deren Erzeugung abstreitenkönnte, würde die Vertrauenswürdigkeitder Signaturfunktionalitäten signifikant beeinträchtigen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 382 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.53 - Io101 - Private-Key (Signatur) des HBATyp des Schutzobjektes: InformationsobjektID: Io101Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDer Private-Key besitzt einen sehr hohenSchutzbedarf, denn sollte er kompromittiertwerden, ist er nicht mehr vertrauenswürdig.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität des Private-Key hat einen sehrhohen Schutzbedarf, denn eine Manipulationdes Private-Keys führt dazu, dass ungültigeSignaturen erstellt werden, die im Rahmender Prüfung von Signaturen zumindest zueinem späteren Zeitpunkt identifizierbar sindaber möglicherweise im Rahmen eines Ablaufeszum Zeitpunkt der Nutzung einen bedeutsamenSchaden erzeugen können.Wird als sehr hoch angesehen, denn nur beiVorhandensein des Private-Key kann derLeistungserbringer signieren.Der Erzeuger eines Private-Key muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Key vom Ersteller nichtabgestritten werden können. Die Existenzvon korrekt ausgestellten Private-Keys fürdie der Aussteller deren Erzeugung abstreitenkönnte, würde die Vertrauenswürdigkeitder Signaturfunktionalitäten signifikant beeinträchtigen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 383 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.56 - Io080 – Sichtbarkeit eines Eintrages in der PatientenakteTyp des Schutzobjektes: InformationsobjektID: Io080Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochDie Information über versteckte Einträgekann auch eine Information über zu verheimlichendeKrankheiten darstellen und verletztdie Privatsphäre des Versicherten.IntegritätVerfügbarkeit(1)AuthentizitätDa diese Information im Rahmen der üblichenGeschäftsvorfälle die über die Telematikinfrastrukturabgewickelt werden keinezentrale Rolle spielt, wird der Schutzbedarfhinsichtlich der Verfügbarkeit mit mittel festgelegt.Nichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochIm Rahmen der Rechtssicherheit und Revisionsfähigkeitwird ein hoher Schutzbedarffür die Integrität dieser Information festgelegt.Der Erzeuger der Information muss eindeutigzuordenbar sein.Ein Akteur darf die ihm gebotene Möglichkeitdes Zugriffs auf einen Eintrag in die Patientenaktenur sehr schwer abstreiten können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 384 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.57 - Io081 – Sichtbarkeit einer eVerordnung für ArzneimittelTyp des Schutzobjektes: InformationsobjektID: Io081Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätr niedrigr mittelhochr sehr hochVerfügbarkeit irrelevant -Die Information über versteckte Einträgekann auch eine Information über zu verheimlichendeKrankheiten darstellen und verletztdie Privatsphäre des Versicherten. Es wirdweiter davon ausgegangen, dass ein Versicherter,wenn er die Sichtbarkeit einer eVerordnungeinschränkt, auch nicht möchte,dass ein Apotheker über die Existenz verstecktereVerordnungen informiert wird.AuthentizitätIm Rahmen der Rechtssicherheit und Revisionsfähigkeitwird ein hoher Schutzbedarffür die Integrität dieser Information festgelegt.Nichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochSiehe Integrität.Siehe Integrität.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 385 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.58 - Io082 – Sichtbarkeit eines Eintrages in der ArzneimitteldokumentationTyp des Schutzobjektes: InformationsobjektID: Io082Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochDie Information über versteckte Einträgekann auch eine Information über zu verheimlichendeKrankheiten darstellen und verletztdie Privatsphäre des Versicherten.IntegritätVerfügbarkeit(1)AuthentizitätDa diese Information im Rahmen der üblichenGeschäftsvorfälle die über die Telematikinfrastrukturabgewickelt werden keinezentrale Rolle spielt, wird der Schutzbedarfhinsichtlich der Verfügbarkeit mit mittel festgelegt.Nichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochIm Rahmen der Rechtssicherheit und Revisionsfähigkeitwird ein hoher Schutzbedarffür die Integrität dieser Information festgelegt.Der Erzeuger der Information muss eindeutigzuordenbar sein.Ein Akteur darf die ihm gebotene Möglichkeitdes Zugriffs auf einen Eintrag der Arzneimitteldokumentationnur schwer abstreitenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 386 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.59 - Io083 – Privater CVC-Key der eGKTyp des Schutzobjektes: InformationsobjektID: Io083Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(2)AuthentizitätWird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys kann die CV-Authentifizierung durchgeführt werden unddann der Versicherte mit seiner eGK agieren.Nichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochBesitzt einen hohen Schutzbedarf, denn eineKompromittierung des privaten Schlüsselshätte zur Folge, dass die Offline-Authentisierungzwischen eGK und HBA nicht mehrgewährleistet („missbraucht“) werden kann.Die Offline-Authentisierung ist nur für selteneFälle vorgesehen, daher der gewählteSchutzbedarf.Die Integrität der Private-Keys hat einen sehrhohen Schutzbedarf, denn eine Manipulationder Private-Keys führt entweder dazu, dasseine Authentifikation oder Ent- bzw. Verschlüsselungvertraulicher Daten nicht mehrmöglich ist. Dieser Fall ist aber von der Auswirkungmit einem physischen Defekt derKarte vergleichbar.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 387 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.60 - Io084 – Privater CVC-Key des HBATyp des Schutzobjektes: InformationsobjektID: Io084Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(2)AuthentizitätWird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys kann die CV-Authentifizierung durchgeführt werden unddann der Versicherte mit seiner eGK agieren.Nichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochBesitzt einen sehr hohen Schutzbedarf, denneine Kompromittierung des privaten CVC-Schlüssels hätte zur Folge, dass mit diesemSchlüssel eine CV-Authentisierung mit jedereGK durchgeführt werden kann. Da dieserCV-Schlüssel nicht wirksam gesperrt werdenkann, folgt der „sehr hohe“ Schutzbedarf.Die Integrität der Private-Keys hat einen sehrhohen Schutzbedarf, denn eine Manipulationder Private-Keys führt entweder dazu, dasseine Authentifikation oder Ent- bzw. Verschlüsselungvertraulicher Daten nicht mehrmöglich ist. Dieser Fall ist aber von der Auswirkungmit einem physischen Defekt derKarte vergleichbar.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 388 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.61 - Io085 – PIN.HomeTyp des Schutzobjektes: InformationsobjektID: Io085Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(2)AuthentizitätDa eine Nicht-Verfügbarkeit der PIN möglicherweisedie Wahrnehmung der Versichertenrechteunterbindet ist der Schutzbedarffür die Verfügbarkeit der PIN mit hoch anzusetzen.Nichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Persönliche Identifikations-NummerPIN.home (PIN zur Wahrnehmung der passivenVersichertenrechte an einem PC durchden Versicherten und zur Freischaltung derPKI-Schlüssel PrK.CH.ENC undPrK.CH.AUT). Diese PIN der eGK stellt einenZugriffsschutz für den Zugriff auf vertraulichemedizinische Daten dar. Da hiermindestens ein vertrauliches Informationsobjekteinen sehr hohen Schutzbedarf hat,gilt der entsprechend Schutzbedarf auch fürdiese PIN sehr hoch.Eine böswillige unautorisierte Veränderungder PIN hat dasselbe Schadenspotential wieeine Vertraulichkeitsverletzung (den unautorisiertenZugriff auf vertrauliche medizinischeDaten).Siehe Integrität.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf eine konkrete PIN(bzw. die Durchführung des PIN-Änderungsprozesses) vom Ändernden nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 389 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.62 - Io086 – ObjektTicket 33Typ des Schutzobjektes: InformationsobjektID: Io086Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochIm ObjektTicket stehen die mit den öffentlichenSchlüsseln der Berechtigten Session-Keys (Schutzbedarf sehr hoch) mit dem u. U.sensible Daten verschlüsselt sind. Ein Angreiferder das ObjektTicket liest, kann dahernicht auf diese vertraulichen medizinischenDaten zugreifen. Das ObjektTicket enthältaber die Liste der Berechtigten und ist damitgeeignet, Profile im medizinischen Kontextzu erstellen, daher der Schutzbedarf hoch.Eine Veränderung des ObjektTickets würdeu. U. den Zugriff auf diese Nutzdaten unmöglichmachen (Schutzbedarf hoch). Daaber das ObjektTicket signiert ist, kann eineIntegritätsverletzung zumindest sehr zuverlässigerkannt werden, daher Schutzbedarfmittel.Eine Nicht-Verfügbarkeit des ObjektTicketsunterbindet den Zugriff auf die Daten derVersicherten. Folglich ist der Schutzbedarffür die Verfügbarkeit des ObjektTickets mithoch anzusetzen.Siehe Integrität.Das ObjektTicket ist durch den Ausstellerdes Tickets signiert. Dadurch ist die Zuordenbarkeitgewährleistet.33 Damit ist das signierte ObjektTicket gemeint.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 390 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.63 - Io087 – ServiceTicket 34Typ des Schutzobjektes: InformationsobjektID: Io087Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätEine Nicht-Verfügbarkeit des ServiceTicketsunterbindet den Zugriff auf die Daten desVersicherten in Abwesenheit des Versicherten.Folglich ist der Schutzbedarf für die Verfügbarkeitdes ServiceTickets mit hoch anzusetzen.Nichtabstreitbarkeitr niedrigmittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigmittelr hochr sehr hochDas ServiceTicket stellt einen Zugriffsmechanismusfür den Zugriff auf vertraulichemedizinische Daten (Schutzbedarf sehrhoch) dar. Ein Angreifer der das ServiceTicketliest, kann aber nicht auf diese vertraulichenDaten zugreifen, da diese in ObjektTicketsverschlüsselt sind, daher Schutzbedarfmittel.Eine Veränderung des ServiceTickets würdeu. U. den Zugriff auf diese Nutzdaten unmöglichmachen oder gar Unberechtigtenden Zugriff ermöglichen (Schutzbedarf sehrhoch). Da aber das ServiceTicket signiert ist,kann eine Integritätsverletzung zumindestsehr zuverlässig erkannt werden, daherSchutzbedarf mittel.Siehe Integrität.Das ServiceTicket ist durch den Ausstellerdes Tickets signiert. Dadurch ist die Zuordenbarkeitgewährleistet.34 Damit ist das signierte ServiceTicket gemeint.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 391 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.64 - Io090 – SMC-A CVC Zertifikat und dazugehöriger Public-KeyTyp des Schutzobjektes: InformationsobjektID: Io090Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn eine Manipulationdarf nicht möglich sein.Bei Nicht-Verfügbarkeit dieses CVC-Zertifikatsist die Arbeitsfähigkeit des Leistungserbringersstark eingeschränkt.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 392 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.65 - Io091 – Privater CVC-Key der SMC-ATyp des Schutzobjektes: InformationsobjektID: Io091Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDer Private-Key besitzt einen sehr hohenSchutzbedarf, denn sollte er kompromittiertwerden ist ggf. ein Zugriff auf vertraulicheDaten möglich.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn eineManipulation darf nicht möglich sein.Bei Nicht-Verfügbarkeit des privaten CVC-Key ist die Arbeitsfähigkeit des Leistungserbringersstark eingeschränkt.Der Erzeuger eines privaten Key muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten privaten Key vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 393 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.66 - Io092 – SMC-B Public-Keys zu ZertifikatenTyp des Schutzobjektes: InformationsobjektID: Io092Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn eine Manipulationdarf nicht möglich sein.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann ein Akteur wiez. B. berufsmäßige Gehilfen Versichertenstammdatenabfragen.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 394 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.67 - Io093 – SMC-B Private KeysTyp des Schutzobjektes: InformationsobjektID: Io093Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist ein ggf. ein Zugriff auf vertraulicheDaten möglich.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität der Private-Keys hat einen sehrhohen Schutzbedarf, denn eine Manipulationder Private-Keys führt entweder dazu, dasseine Authentifikation oder Ent- bzw. Verschlüsselungvertraulicher Daten nicht mehrmöglich ist. Anm.: Dieser Fall ist aber vonder Auswirkung mit einem physischen Defektder Karte vergleichbar.Wird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys können dieLeistungserbringer und ihre Angestelltenuneingeschränkt arbeiten.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Key vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 395 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.68 - Io094 – SMC-B CVC Zertifikat und dazugehöriger Public-KeyTyp des Schutzobjektes: InformationsobjektID: Io094Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn eine Manipulationdarf nicht möglich sein.Bei Nicht-Verfügbarkeit des privaten CVC-Key ist die Arbeitsfähigkeit des Leistungserbringersstark eingeschränkt.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 396 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

C2.69 - Io095 – Privater CVC-Key der SMC-BTyp des Schutzobjektes: InformationsobjektID: Io095Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDer Private-Key besitzt einen sehr hohenSchutzbedarf, denn sollte er kompromittiertwerden ist ein ggf. ein Zugriff auf vertraulicheDaten möglich.IntegritätVerfügbarkeit(2)AuthentizitätÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn eineManipulation darf nicht möglich sein.Bei einer Nicht-Verfügbarkeit des privatenCVC-Key könnte der Leistungserbringervielleicht nicht uneingeschränkt arbeiten,was hohe Auswirkungen für ihn, ggf. seineMitarbeiter und Versicherten hat. Daher istder Schutzbedarf mit hoch festzulegen.Der Erzeuger eines privaten CVC-Key mussaus Gründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten privaten Key vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 397 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.70 - Io103 – Versichertenzentriertes Audit (Einzeleintrag eines Versicherten)Typ des Schutzobjektes: InformationsobjektID: Io103Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelhochrsehr hochr niedrigr mittelhochrsehr hochDas versichertenzentrierte Audit (Einzeleintrageines Versicherten) gibt eine einzelneAuskunft über vertrauliche Daten eines Versicherten,deren Bekanntgabe keinen sohohen Schaden für die betroffene Personhat. Daher wurde hier mittel gewählt.Aus Gründen der Nachvollziehbarkeit gilt einhoher Schutzbedarf für Auditdaten.Wird als mittel angesehen, da keine besonderenzeitlichen Rahmenbedingungen für dieVerfügbarkeit definiert sind, wobei allgemeindavon auszugehen ist, dass Auditdaten imnicht vorhersehbaren Anlassfall zeitnah zurVerfügung stehen.Aus Gründen der Nachvollziehbarkeit mussder Erzeuger von Auditdaten eindeutig bestimmbarsein.Aus Gründen der Nachvollziehbarkeit dürfenAuditdaten von auslösenden Personen nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 398 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.71 - Io104 – Versichertenzentriertes Audit (Liste der Einträge aller Versichertenbzw. einer Gruppe)Typ des Schutzobjektes: InformationsobjektID: Io104Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochrsehr hochDas versichertenzentrierte Audit (Liste derEinträge aller Versicherten bzw. einer Gruppe)gibt Auskunft über vertrauliche Datenvon vielen Versicherten, daher ist derSchutzbedarf mit sehr hoch zu bewerten.Aus Gründen der Nachvollziehbarkeit gilt einhoher Schutzbedarf für Auditdaten.Wird als mittel angesehen, da keine besonderenzeitlichen Rahmenbedingungen für dieVerfügbarkeit definiert sind, wobei allgemeindavon auszugehen ist, dass Auditdaten imnicht vorhersehbaren Anlassfall zeitnah zurVerfügung stehen.Aus Gründen der Nachvollziehbarkeit mussder Erzeuger von Auditdaten eindeutig bestimmbarsein.Aus Gründen der Nachvollziehbarkeit dürfenAuditdaten von auslösenden Personen nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 399 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.72 - Io105 – Antwort des OCSP BasisdienstTyp des Schutzobjektes: InformationsobjektID: Io105Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Sperrlisten sind zwar innerhalb des Gesamtsystems„öffentlich“, sollten aber nichthinaus gelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochrsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochrsehr hochr niedrigr mittelhochr sehr hochDer Schutzbedarf der Antwort ist hoch einzustufen,denn eine (böswillige) Manipulationkann dazu führen, dass einzelne Diensteund Komponenten von der weiteren Teilnahmean der TI ausgeschlossen sind undsomit nicht mehr korrekt arbeiten können.Bei einer Nicht-Verfügbarkeit der OCSP-Antwort könnte der Leistungserbringer vielleichtnicht korrekt arbeiten, was hohe Auswirkungenfür ihn, ggf. seine Mitarbeiter undVersicherten hat. Daher ist der Schutzbedarfmit hoch festzulegen.Der Schutzbedarf ist mit hoch einzustufen,denn eine gefälschte Antwort kann eine weitereTeilnahme an der TI verhindern. Sieheauch Integrität.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung der korrektenAntwort vom Ersteller nicht abgestrittenwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 400 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.73 - Io106 – CRListen des CRL Validation und CRL Provider BasisdiensteTyp des Schutzobjektes: InformationsobjektID: Io106Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Information ist TI-weit öffentlich und somitwird der Schutzbedarf mit mittel eingeschätzt.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochrsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDer Schutzbedarf der Listen ist hoch einzustufen,denn eine (böswillige) Manipulationkann dazu führen, dass einzelne Diensteund Komponenten von der weiteren Teilnahmean der TI ausgeschlossen sind undsomit nicht mehr korrekt arbeiten können.Bei einer Nicht-Verfügbarkeit der Listenkönnte der Leistungserbringer vielleichtnicht korrekt arbeiten, was hohe Auswirkungenfür ihn, ggf. seine Mitarbeiter und Versichertenhat. Daher ist der Schutzbedarf mithoch festzulegen.Der Schutzbedarf ist mit hoch zu einstufen,denn eine gefälschte Liste kann eine weitereTeilnahme an der TI verhindern.Aus Gründen der Nachvollziehbarkeit darfdie Erstellung der korrekten Liste vom Erstellernicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 401 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.74 - Io107 – TSL des TSL Retrieval BasisdienstTyp des Schutzobjektes: InformationsobjektID: Io107Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochrsehr hochDie Information ist TI-weit öffentlich und somitwird der Schutzbedarf mit mittel eingeschätztIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDer Schutzbedarf der Listen ist mit sehrhoch einzustufen, denn eine (böswillige)Manipulation kann dazu führen, dass einzelneDienste und Komponenten von derweiteren Teilnahme an der TI ausgeschlossensind und somit nicht mehr korrekt arbeitenkönnen.Bei einer Nicht-Verfügbarkeit der Listenkönnte der Leistungserbringer vielleichtnicht korrekt arbeiten, was hohe Auswirkungenfür ihn, ggf. seine Mitarbeiter und Versichertenhat. Daher ist der Schutzbedarf mithoch festzulegen.Der Schutzbedarf ist mit sehr hoch zu einstufen,denn eine gefälschte Liste kann eineweitere Teilnahme an der TI verhindern.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung der korrektenListe vom Ersteller nicht abgestrittenwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 402 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.75 - Io108 – TS-Listen des TSL Creator BasisdienstTyp des Schutzobjektes: InformationsobjektID: Io108Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDie Information ist TI-weit öffentlich und somitwird der Schutzbedarf mit mittel eingeschätzt.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDer Schutzbedarf der Listen ist mit sehrhoch einzustufen, denn eine (böswillige)Manipulation kann dazu führen, dass einzelneDienste und Komponenten von derweiteren Teilnahme an der TI ausgeschlossensind und somit nicht mehr korrekt arbeitenkönnen.Bei einer Nicht-Verfügbarkeit der Listenkönnte der Leistungserbringer vielleichtnicht korrekt arbeiten, was hohe Auswirkungenfür ihn, ggf. seine Mitarbeiter und Versichertenhat. Daher ist der Schutzbedarf mithoch festzulegen.Der Schutzbedarf ist mit sehr hoch zu einstufen,denn eine gefälschte Liste kann eineweitere Teilnahme an der TI verhindern.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung der korrektenListe vom Ersteller nicht abgestrittenwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 403 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.76 - Io109 – Private-Key des TSL Creator Basisdienst zum Signieren derTSLTyp des Schutzobjektes: InformationsobjektID: Io109Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist ggf. das Einbringen von nichtautorisierten Zertifikaten möglich.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität der Private-Keys hat einen sehrhohen Schutzbedarf, denn eine Manipulationder Private-Keys führt dazu, dass die Erstellungeiner neuen TSL nicht mehr möglichist.Wird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys können dieLeistungserbringer und ihre Angestelltenkorrekt arbeiten.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Key vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 404 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.77 - Io110 – Public-Key und dazugehöriges Zertifikat des TSL Creator BasisdienstTyp des Schutzobjektes: InformationsobjektID: Io110Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Public-Keys und die dazugehörigen Zertifikatehaben nur einen niedrigen bis mittlerenSchutzbedarf, denn sie sind sowiesobekannt und ggf. öffentlich verfügbar (Verzeichnisdienst).Die Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn eineManipulation der TSLs darf nicht möglichsein.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann die Gültigkeit derTSL überprüft werden.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys/Zertifikat vom Erstellernicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 405 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.78 - Io111 – Cache des ServiceDirectoryService (SDS)Typ des Schutzobjektes: InformationsobjektID: Io111Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochNur niedrig, da die enthaltenen IP-Adressenin der Regel öffentlich bekannt sein werden.Nach der Broker-Spez. sind verpflichtenderst die IP-Adressen aus diesem Speicherzu benutzten.Wird eine IP-Adresse durch Fehler oder Angriffverfälscht, geht die Nachricht ins Leereund muss neu erstellt werden (erneutesSenden ist nach Broker-Spez. nicht zulässig).Daher muss die Integrität dieser Datenlückenlos gewährleistet werden. Deshalb istder Schutzbedarf mit hoch festzulegen.Der SDS ist zur Entlastung der sehr hohenVerfügbarkeitsanforderung an den eigentlichenSDS eingeführt worden. D.h. ist derCache nicht verfügbar, wird der eigentlicheSDS abgefragt. Da dieser nur „mittel„ verfügbarist, muss der Cache mindestens hochverfügbar sein.Die Authentizität der enthalten IP-Adressenmuss lückenlos gewährleistet werden.Die Urheberschaft der Einträge muss lückenlosverfolgbar sein:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 406 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.79 - Io114 – Private-Key des SecurityConfirmationService (SCS)Typ des Schutzobjektes: InformationsobjektID: Io114Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden können gefälschte Anfragen beiFachdiensten auftauchen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität der Private-Keys hat einen hohenSchutzbedarf, denn eine Manipulationder Private-Keys führt dazu, dass eine Authentifikationbeim Fachdienst nicht mehrmöglich ist.Wird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys kann der Nachrichtenerzeugernicht mehr anonymisiertwerdenDer Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 407 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.80 - Io115 – Public-Key und dazugehöriges Zertifikat des SCSTyp des Schutzobjektes: InformationsobjektID: Io115Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Public-Keys und die dazugehörigen Zertifikatehaben nur einen niedrigen bis mittlerenSchutzbedarf, denn sie sind sowiesobekannt und ggf. öffentlich verfügbar (Verzeichnisdienst).Die Integrität der Public-Keys hat einen hohenSchutzbedarf, denn eine Manipulationführt dazu dass eine Authentifikation beimFachdienst nicht mehr möglich ist.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann ein Fachdiensteinen Aufruf überprüfen.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys/Zertifikat vom Erstellernicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 408 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.81 - Io116 - Liste aller Einträge einer Person im Update Flag Service (UFS)Typ des Schutzobjektes: InformationsobjektID: Io116Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Information das Updates für einen Versichertenvorliegen, könnte darauf schließenlassen, wie oft er zum Arzt geht und an welchenAnwendungen er teilnimmt. Dies kannzu einer Profilbildung führen, daher sind dieseDaten als besonders vertraulich zu erachten.Der Schutzbedarf der Liste ist sehr hocheinzustufen, denn eine (böswillige) Manipulationkann dazu führen, dass für den Versichertenkeine Updates eingespielt werdenmüssen/können (da das relevante Flag fehlt)und somit seine Daten nicht aktuell sind undseine Anwendungen nicht korrekt arbeitenkönnen.Bei einer Nicht-Verfügbarkeit der Einträgekönnte der Versicherte keine Updates einspielen,was bedeuten kann, dass nicht alleAnwendungen korrekt/sicher arbeiten (fehlendesSicherheitspatch erhöht das Risikofür Viren etc, aber die Fkt. ist noch gewährleistet).Vielleicht kann aber die ältere Versionnoch arbeiten (für eine kurze Zeit), daherist der Schutzbedarf hier mit hoch festzulegen.Der Schutzbedarf ist mit sehr hoch zu einstufen,denn eine gefälschte/veränderte Listeverhindert ggf. ein korrektes Update. Sieheauch Integrität.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung der korrektenEinträge vom Ersteller nicht abgestrittenwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 409 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.82 - Io117 – Menge aller Listen von allen Personen im UFSTyp des Schutzobjektes: InformationsobjektID: Io117Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeitAuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Information, dass Updates für alle Versichertenvorliegen, könnte darauf schließenlassen, wie oft sie zum Arzt gehen und anwelchen Anwendungen sie teilnehmen. Dieskann zu einer Profilbildung führen, dahersind diese Daten als besonders vertraulichzu erachten.Der Schutzbedarf der Listen ist sehr hocheinzustufen, denn eine (böswillige) Manipulationkann dazu führen, dass die Versichertenkeine Updates einspielen müssen/können(da ja die relevanten Flags fehlen)und somit ihre Daten/Anwendungennicht korrekt arbeiten können.Ist nicht relevant.Der Schutzbedarf ist mit sehr hoch zu einstufen,denn eine gefälschte/veränderte Listeverhindert ggf. ein korrektes Update. Sieheauch IntegritätAus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung der korrektenListen vom Ersteller nicht abgestrittenwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 410 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.83 - Io118 – Private-Key des VPN-KonzentratorTyp des Schutzobjektes: InformationsobjektID: Io118Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochDie Private-Keys besitzen einen hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist eine nicht autorisierte IPSecAuthentifikation möglich.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn der Eintragvon gefälschten Zertifikaten darf nicht möglichsein.Verfügbarkeit wird als hoch angesehen,denn der Schlüssel ist nötig, denn sonstkann keine Verbindung zur TI durch denKonnektor aufgebaut werden.Dieser Private Key muss auf den Erzeugerrückführbar sein.Die Erstellung des korrekten Private-Keymuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 411 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.84 - Io119 – Public-Key und dazugehöriges Zertifikat des VPN-KonzentratorsTyp des Schutzobjektes: InformationsobjektID: Io119Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn die Fälschungeines IPSec-Zertifikats darf nichtmöglich sein.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann eine IPSec Authentifikationdurchgeführt werden.Dieses Public-Key/Zertifikat muss auf denErzeuger rückführbar sein.Die Erstellung des korrekten Public-Keysmuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 412 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.85 - Io120 – Private-Key des Ticket-TreuhändersTyp des Schutzobjektes: InformationsobjektID: Io120Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, können Unberechtigte, Objektschlüsselfür medizinische Daten entschlüsseln.Die Integrität der Private-Keys hat einen sehrhohen Schutzbedarf, denn eine Manipulationder Private-Keys führt dazu, dass u. U. eineEntschlüsselung der Objektschlüssel für medizinischeDaten nicht mehr möglich ist.Wird als hoch angesehen, denn nur bei Vorhandenseinder Private-Keys können im Bedarfsfalldie Objektschlüssel für medizinischeDaten entschlüsselt werden.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 413 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.86 - Io121 – Public-Key und dazugehöriges Zertifikat des Ticket-TreuhändersTyp des Schutzobjektes: InformationsobjektID: Io121Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Public-Keys und die dazugehörigen Zertifikatehaben nur einen niedrigen bis mittlerenSchutzbedarf, denn sie sind sowiesobekannt und ggf. öffentlich verfügbar (Verzeichnisdienst).Die Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn eineManipulation darf nicht möglich sein.Wird als hoch angesehen, denn nur bei Vorhandenseindes Zertifikats können Objektschlüsselfür medizinische Daten hinterlegtwerden. Steht das Zertifikat nicht zurVerfügung können u. U. medizinischen Datenverloren gehen.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys/Zertifikat vom Erstellernicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 414 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.87 - Io122 - Private-Key der CV-RootTyp des Schutzobjektes: InformationsobjektID: Io122Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, können gefälschte CV-SubCAZertifikate auftauchen.IntegritätVerfügbarkeit(*)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn dieErstellung von nicht autorisierten Sub-CA-Zertifikaten darf nicht möglich sein.Die Anforderungen an „Verfügbarkeit ausSicht der Performanz“ sind zwar niedrig,denn die Schlüssel sind nur zur Erstellungvon CV-SubCA-Zertifikaten nötig. Geht derSchlüssel jedoch verloren, droht ein Systemwechsel,d.h.dass alle Karten gewechseltwerden müssen.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys/Zertifikat vom Erstellernicht abgestritten werden können.*: Der private Schlüssel der Root-CVC-CA muss mit hoher Zuverlässigkeit wiederhergestelltwerden können. Andernfalls droht der Austausch sämtlicher HBA und eGK. Die Anforderungenan den zeitlichen Rahmen der Wiederherstellung sind niedrig (kleiner als 3Tage).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 415 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.88 - Io123 – Public-Key und dazugehöriges Zertifikat der CV-RootTyp des Schutzobjektes: InformationsobjektID: Io123Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Public-Keys und die dazugehörigen Zertifikatehaben nur einen niedrigen bis mittlerenSchutzbedarf, denn sie sind sowiesobekannt und ggf. öffentlich verfügbar (Verzeichnisdienst).Die Integrität des Public-Key der CV-Roothat einen sehr hohen Schutzbedarf, denneine Manipulation, das Unterschieben einesfalschen Schlüssels, kann die CV-Authentifikationunterlaufen.Wird als hoch angesehen, denn nur Mithilfedes Public-Key der CV-Root können sicheGK und HBA gegenseitig authentisieren.Der Erzeuger eines CVC-Zertifikats der CV-Root muss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten CVC-Zertifikats der CV-Root vomErsteller nicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 416 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.89 - Io124 – Private-Keys der CV-SUB-CATyp des Schutzobjektes: InformationsobjektID: Io124Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, können gefälschte CV-Zertifkateauftauchen.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn dieErstellung von nicht autorisierten aber gültigenCV-Zertifikaten darf nicht möglich sein.Verfügbarkeit wird als niedrig angesehen,denn die Schlüssel sind im direkten Betriebnicht nötig, nur zur Erstellung von CV-Zertifikatensind sie notwendig.Der Erzeuger eines Public-Keys/Zertifikatsmuss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Public-Keys/Zertifikat vom Erstellernicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 417 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.90 - Io125 – Public-Keys und dazugehörige Zertifikate der CV-SUB-CATyp des Schutzobjektes: InformationsobjektID: Io125Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochDas Zertifikat ist innerhalb des Gesamtsystems„öffentlich“, sollte aber nicht unbedingthinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität Public-Key und des Zertifikatsder CV-SUB-CA hat einen sehr hohenSchutzbedarf, denn eine Manipulation, dasUnterschieben eines falschen Schlüssels,kann die CV-Authentikation unterlaufen.Wird als hoch angesehen, denn nur Mithilfedes CVC-Zertifikats der CV-SUB-CA könnensich eGK und HBA gegenseitig authentisieren.Der Erzeuger eines CVC-Zertifikats der CV-SUB-CA muss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbarsein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten CVC-Zertifikats der CV-SUB-CAvom Ersteller nicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 418 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.91 - Io126 – Private-Keys eines Telematikservices (SSL)Typ des Schutzobjektes: InformationsobjektID: Io126Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochDie Private-Keys besitzen einen hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist eine nicht autorisierte SSL-Verbindung möglich.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn der Eintrageines gefälschten privaten Schlüssels darfnicht möglich sein.Wird als hoch angesehen, denn nur wennder private Schlüssel vorhanden ist, kanneine SSL-Verbindung aufgebaut werden.Dieser Private-Key muss auf den Erzeugerrückführbar sein.Die Erstellung des korrekten Private-Keymuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 419 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.92 - Io127 – Public-Keys und dazugehörige X.509-Zertifikate eines Telematikservices(SSL)Typ des Schutzobjektes: InformationsobjektID: Io127Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn der Eintrageines gefälschten SSL-Zertifikats darf nichtmöglich sein.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann eine SSL-Verbindungaufgebaut werden.Dieses Public-Keys/Zertifikat muss auf denErzeuger rückführbar sein.Die Erstellung des korrekten Public-Keysmuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 420 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.93 - Io128 – Private-Key der X.509-Telematik Service-CATyp des Schutzobjektes: InformationsobjektID: Io128Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochDie Private-Keys besitzen einen hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist eine nicht autorisierte SSL-Verbindung möglich.IntegritätVerfügbarkeit(1)AuthentizitätVerfügbarkeit wird nur als niedrig angesehen,denn der Schlüssel ist im direkten Betriebnicht nötig, nur zur Erstellung der Zertifikate.Nichtabstreitbarkeitr niedrigr mittelhochr sehr hochniedrigr mittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn der Eintragvon gefälschten Zertifikaten darf nicht möglichsein.Dieser Private-Key muss auf den Erzeugerrückführbar sein.Die Erstellung des korrekten Private-Keymuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 421 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.94 - Io129 – Public-Key und dazugehöriges Zertifikat der X.509-TelematikService-CATyp des Schutzobjektes: InformationsobjektID: Io129Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn die Benutzungeines gefälschten Public Key darf nichtmöglich sein.Wird durch die Infrastruktur-TSL zur Verfügunggestellt.Dieses Public-Key/Zertifikat muss auf denErzeuger rückführbar sein.Die Erstellung des korrekten Public-Keysmuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 422 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.95 - Io130 – Private-Key der X.509-Telematik-Netz-CATyp des Schutzobjektes: InformationsobjektID: Io130Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochDie Private-Keys besitzen einen hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist eine nicht autorisierte IPSec-Verbindung möglich.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochniedrigr mittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, da der Eintragvon gefälschten Zertifikaten nicht möglichsein darf.Verfügbarkeit wird nur als niedrig angesehen,da der Schlüssel im direkten Betriebnicht nötig ist. Er dient nur zur Erstellung derZertifikate.Dieser Private-Key muss auf den Erzeugerrückführbar sein.Die Erstellung des korrekten Private-Keymuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 423 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.96 - Io131 – Public-Key und dazugehöriges Zertifikat der X.509-Telematik-Netz-CATyp des Schutzobjektes: InformationsobjektID: Io131Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn die Benutzungeines gefälschten Public Key darf nichtmöglich sein.Wird durch die Infrastruktur-TSL zur Verfügunggestellt.Dieses Public-Key/Zertifikat muss auf denErzeuger rückführbar sein.Die Erstellung des korrekten Public-Keysmuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 424 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.97 - Io132 – Private-Key der eGK-X.509 RootTyp des Schutzobjektes: InformationsobjektID: Io132Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, können gefälschte eGK-X.509-SubCA Zertifikate auftauchen.IntegritätVerfügbarkeit(1)AuthentizitätVerfügbarkeit wird als nur als niedrig angesehen,denn die Schlüssel sind im direktenBetrieb nicht nötig, nur zur Erstellung voneGK-X.509-SubCA-Zertifikaten sind sie notwendig.Nichtabstreitbarkeitr niedrigr mittelr hochsehr hochniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn dieErstellung von nicht autorisierten Sub-CA-Zertifikaten darf nicht möglich sein.Der Erzeuger eines Private-Key muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 425 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.98 - Io133 – Public-Key und dazugehöriges Zertifikat der eGK-X.509-RootTyp des Schutzobjektes: InformationsobjektID: Io133Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Public-Keys und die dazugehörigen Zertifikatehaben nur einen niedrigen bis mittlerenSchutzbedarf, denn sie sind sowiesobekannt und ggf. öffentlich verfügbar (Verzeichnisdienst).Die Integrität des Public-Key der eGK-X.509-Root hat einen sehr hohen Schutzbedarf,denn sonst können gefälschte eGK-X.509SubCA-Zertifikate ausgegeben werden.Wird als hoch angesehen, denn nur Mithilfedes Public-Key der eGK-X.509-Root kannein eGK-Zertifikat vollständig verifiziert werden.Der Erzeuger eines eGK-X.509- SubCA Zertifikatsder CV-Root muss aus Gründen derRevisionsfähigkeit und Rechtssicherheitbestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten eGK-X.509- SubCA Zertifikatsdurch die eGK-X.509-Root vom Erstellernicht abgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 426 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.99 - Io134 – Private-Keys der eGK-X.509-SUB-CATyp des Schutzobjektes: InformationsobjektID: Io134Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochDie Private-Keys besitzen einen sehr hohenSchutzbedarf, denn sollten sie kompromittiertwerden, können gefälschte eGK-X.509-Zertifkate auftauchen.IntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Integrität dieser Informationsobjekte hateinen sehr hohen Schutzbedarf, denn dieErstellung von nicht autorisierten aber gültigeneGK-X.509-Zertifikaten darf nicht möglichsein.Verfügbarkeit wird als niedrig angesehen,denn die Schlüssel sind im direkten Betriebnicht nötig, nur zur Erstellung von eGK-X.509-Zertifikaten sind sie notwendig.Der Erzeuger eines Private-Keys muss ausGründen der Revisionsfähigkeit undRechtssicherheit bestimmbar sein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten Private-Keys vom Ersteller nichtabgestritten werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 427 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.100 - Io135 – Public-Keys und dazugehörige Zertifikate der eGK-X.509-SUB-CATyp des Schutzobjektes: InformationsobjektID: Io135Grundwert Schutzbedarf BegründungVertraulichkeitIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitniedrigr mittelr hochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDie Public-Keys und die dazugehörigen Zertifikatehaben nur einen niedrigen bis mittlerenSchutzbedarf, denn sie sind sowiesobekannt und ggf. öffentlich verfügbar (Verzeichnisdienst).Die Integrität des Public-Key der eGK-X.509-Root hat einen sehr hohen Schutzbedarf,denn sonst können gefälschte eGK-X.509Zertifikate ausgegeben werden.Wird als hoch angesehen, denn nur Mithilfedes Public-Key der zugehörigen eGK-X.509-SubCA-Zertifikate kann ein eGK-Zertifikatvollständig verifiziert werden.Der Erzeuger eines eGK-X.509 Zertifikatsder SubCA muss aus Gründen der Revisionsfähigkeitund Rechtssicherheit bestimmbarsein.Aus Gründen der Revisionsfähigkeit undRechtssicherheit darf die Erstellung eineskorrekten eGK-X.509- Zertifikats durch dieeGK-X.509- SubCA vom Ersteller nicht abgestrittenwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 428 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.101 - Io136 – Private-Key des SM-KTyp des Schutzobjektes: InformationsobjektID: Io136Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Private-Keys besitzen einen hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist die Vortäuschung eines zugelassenenKonnektors und eine nicht autorisierteIPSec Authentifikation möglich.Die Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn der Eintrageines gefälschten privaten Schlüssels darfnicht möglich sein.Verfügbarkeit wird als hoch angesehen,denn der Schlüssel ist nötig, denn sonstkann keine Verbindung zur TI durch denKonnektor aufgebaut werden bzw. nicht dieZulassung des Konnektors geprüft werden.Dieser Private Key muss auf den Erzeugerrückführbar sein.Die Erstellung des korrekten Private-Keymuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 429 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.102 - Io137 – Public-Key und dazugehöriges Zertifikat des SM-KTyp des Schutzobjektes: InformationsobjektID: Io137Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn die Fälschungeines IPSec-Zertifikats darf nichtmöglich sein.Wird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann eine IPSec Authentifikationoder eine Zulassungsprüfungdurchgeführt werden.Dieses Public-Key/Zertifikat muss auf denErzeuger rückführbar sein.Die Erstellung des korrekten Public-Keysmuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 430 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.103 - Io138 – Private-Key des SM-KTTyp des Schutzobjektes: InformationsobjektID: Io138Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Private-Keys besitzen einen hohenSchutzbedarf, denn sollten sie kompromittiertwerden, ist die Vortäuschung eine zugelassenenKartenterminals und eine nichtautorisierte SSL Authentifikation möglich.Die Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn der Eintrageines gefälschten privaten Schlüssels darfnicht möglich sein.Verfügbarkeit wird als hoch angesehen,denn der Schlüssel ist nötig, denn sonstkann keine Verbindung zum Konnektor aufgebautwerden bzw. nicht die Zulassung desKartenterminals geprüft werden.Dieser Private Key muss auf den Erzeugerrückführbar sein.Die Erstellung des korrekten Private-Keymuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 431 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.104 - Io139 – Public-Key und dazugehöriges Zertifikat des SM-KTTyp des Schutzobjektes: InformationsobjektID: Io139Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIst mit mittel einzustufen, da das Zertifikatund der Public-Key innerhalb des Gesamtsystems„öffentlich“ sind, sie sollten abernicht unbedingt hinausgelangen.IntegritätVerfügbarkeit(2)AuthentizitätWird als hoch angesehen, denn nur wenndie Public-Keys und die relevanten Zertifikatevorhanden sind, kann eine Verbindungzum Konnektor aufgebaut werden bzw. dieZulassung des Kartenterminals geprüft werdenNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDie Integrität dieser Informationsobjekte hateinen hohen Schutzbedarf, denn die Fälschungeines SSL-Zertifikats darf nicht möglichsein.Dieses Public-Key/Zertifikat muss auf denErzeuger rückführbar sein.Die Erstellung des korrekten Public-Keysmuss eindeutig auf eine natürliche Personrückführbar sein. Die Erstellung soll vonAusübenden nur schwer bestritten werdenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 432 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.105 - Io140 – Symm. Objektschlüssel bzgl. verschlüsselter pers. bezogenermedizinischer DatenTyp des Schutzobjektes: InformationsobjektID: Io140Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelr hochsehr hochIntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDa der symmetrische Objektschlüssel vertraulichemedizinische Daten schützt, weisteine Kompromittierung dieses Schlüssels einerhebliches Schadenspotential auf. Daherwird der Schutzbedarf mit sehr hoch eingestuft.Die Verletzung der Integrität eines symmetrischenObjektschlüssels führt primär dazu,dass auf die verschlüsselten Informationennicht mehr zugegriffen werden kann. Ausdiesem Grund wird der Schutzbedarf aufhoch gesetzt.Da die Verfügbarkeit der symmetrischenObjektschlüssel gleichbedeutend mit derVerfügbarkeit der verschlüsselten Inhalte ist,wird hier ein hoher Schutzbedarf angesetzt.Der Erzeuger bzw. erzeugende Prozess einessymmetrischen Objektschlüssels zurVerschlüsselung medizinischer Daten mussbestimmbar sein.Der Erzeuger eines symmetrischen Objektschlüsselsdarf dessen Erzeugung nicht abstreitenkönnen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 433 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.106 - Io141 – Liste der BerechtigungenTyp des Schutzobjektes: InformationsobjektID: Io141Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochDa anhand der Liste der BerechtigungenProfile über die vom Versicherten besuchtenLeistungserbinger erstellt werden können,ergibt sich ein Schutzbedarf von hoch.IntegritätVerfügbarkeit(2)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochEine Veränderung der Liste der Berechtigungenwürde u. U. den Zugriff auf die Nutzdatenunmöglich machen oder gar Unberechtigtenden Zugriff ermöglichen.Da die Verfügbarkeit der Liste der Berechtigungengleichbedeutend mit der Verfügbarkeitder verschlüsselten medizinischen Datenist, wird hier ein hoher Schutzbedarf angesetzt.Die Berechtigungen sind auf die Autorisierungdes Versicherten zurückzuführen.Die Autorisierung der Berechtigungen durchden Versicherten dürfen nicht abgestrittenwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 434 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.107 - Io142 – ObjektTicket (unsigniert)Typ des Schutzobjektes: InformationsobjektID: Io142Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochIm ObjektTicket stehen die mit den öffentlichenSchlüsseln der Berechtigten Session-Keys (Schutzbedarf sehr hoch) mit dem u. U.sensible Daten verschlüsselt sind. Ein Angreiferder das ObjektTicket liest, kann dahernicht auf diese vertraulichen medizinischenDaten zugreifen. Das ObjektTicket enthältaber die Liste der Berechtigten und ist damitgeeignet, Profile im medizinischen Kontextzu erstellen, daher der Schutzbedarf hoch.Eine Veränderung des ObjektTickets würdeu. U. den Zugriff eines Berechtigten auf seinemedizinischen Daten für immer unmöglichmachen, dadurch drohen Schäden fürLeib und Leben.Eine Nicht-Verfügbarkeit des ObjektTicketsunterbindet den Zugriff auf die Daten derVersicherten. Folglich ist der Schutzbedarffür die Verfügbarkeit des ObjektTickets mithoch anzusetzen.Die ObjektTickets sind eindeutig und nachweisbarauf einen Versicherten zurückzuführen,denn nur der Versicherte darf einenZugriff autorisieren.Die Erstellung und Modifikation des Objekt-Ticktes (z. B. Änderung der Liste der Berechtigten)muss eindeutig und nachweisbarauf die Autorisierung des Versicherten rückführbarsein.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 435 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.108 - Io143 – ServiceTicket (unsigniert)Typ des Schutzobjektes: InformationsobjektID: Io143Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelr hochsehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelr hochsehr hochr niedrigr mittelr hochsehr hochDas ServiceTicket stellt einen Zugriffsmechanismusfür den Zugriff auf vertraulichemedizinische Daten (Schutzbedarf sehrhoch) dar. Ein Angreifer der das ServiceTicketliest, kann aber nicht auf diese vertraulichenDaten zugreifen, da diese in ObjektTicketsverschlüsselt sind, daher Schutzbedarfmittel.Eine Veränderung des ServiceTickets würdeu. U. den Zugriff auf diese Nutzdaten unmöglichmachen oder gar Unberechtigtenden Zugriff ermöglichen.Eine Nicht-Verfügbarkeit des ServiceTicketsunterbindet den Zugriff auf die Daten desVersicherten in Abwesenheit des Versicherten.Folglich ist der Schutzbedarf für die Verfügbarkeitdes ServiceTickets mit hoch anzusetzen.Die ServiceTickets sind eindeutig und nachweisbarauf einen Versicherten zurückzuführen,denn nur der Versicherte darf einenZugriff autorisieren.Die Erstellung des ServiceTicktes muss eindeutigund nachweisbar auf den Versichertenrückführbar sein.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 436 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.109 - Io144 – HybridschlüsselTyp des Schutzobjektes: InformationsobjektID: Io144Grundwert Schutzbedarf BegründungVertraulichkeit r niedrigmittelr hochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochDa der Hybridschlüssel ein mit einem öffentlichenSchlüssel verschlüsselter symmetrischerSchlüssel ist und der symmetrischeSchlüssel für den Zugriff auf medizinischeVersichertendaten damit kryptographischgeschützt ist, gilt ein Schutzbedarf von mittel.Die Verletzung der Integrität eines Hybridschlüsselsführt primär dazu, dass auf dieverschlüsselten Informationen nicht mehrzugegriffen werden kann. Aus diesem Grundwird Integrität auf hoch gesetzt.Da die Verfügbarkeit des Hybridschlüsselsgleichbedeutend mit der Verfügbarkeit derverschlüsselten medizinischen Daten ist,wird hier ein hoher Schutzbedarf angesetzt.Der Erzeuger bzw. erzeugende Prozess einesHybridschlüssels zur Verschlüsselungmedizinischer Daten muss bestimmbar sein.Der Erzeuger eines Hybridschlüssels darfdessen Erzeugung nicht abstreiten können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 437 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC2.110 - Io145 – Berechtigungshistorie 35Typ des Schutzobjektes: InformationsobjektGrundwert Schutzbedarf BegründungVertraulichkeit r niedrigr mittelhochr sehr hochIntegritätVerfügbarkeit(1)AuthentizitätNichtabstreitbarkeitr niedrigr mittelhochr sehr hochr niedrigmittelr hochr sehr hochr niedrigr mittelhochr sehr hochr niedrigr mittelhochr sehr hochID: Io145Da anhand der Berechtigungshistorie Profileüber die vom Versicherten besuchten Leistungserbringererstellt werden können, ergibtsich ein Schutzbedarf von hoch. Die Anzeigeder Zugriffsberechtigungen inkl. der Historieist nur dem Versicherten zugänglich.Die Zugriffsberechtigungen sind zu archivieren,so dass jederzeit nachvollziehbar ist,welche Berechtigungen in der Vergangenheitvergeben wurden.Die Historie kann ggf. geringere Verfügbarkeitsanforderungenhaben, als die aktuellenBerechtigungen.Siehe IntegritätSiehe Integrität35 Die Berechtigungshistorie sollte keine ServiceTicktes (insbesondere auch unabhängig von derenGültigkeit) enthalten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 438 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC3 - Beschreibung der SchutzzieleC3.1 - Schutzbedarfsklassen für Schutzziel VertraulichkeitFür das Schutzziel Vertraulichkeit (Schutz vor unberechtigtem Zugriff) gelten folgendeVoraussetzungen für die zugrunde liegende Prozessqualitäten:SchutzbedarfNiedrigMittelHochSehr HochProzessqualitätDer Zugriff ist durch einfache, zweckmäßige Verfahren eingeschränkt.Informationsobjekte dieser Schutzbedarfskategorie sind vor unberechtigtemZugriff durch Verschlüsselungsverfahren geschützt. Das entsprechendeSchlüsselmaterial wird mit der Mechanismenstärke „Niedrig“nach ITSEC geschützt.Der Zugriff auf ein Informationsobjekt dieser Schutzbedarfskategorieist nur nach einer Autorisierung entsprechend eines Verfahrens derProzessqualität „Benutzername und Passwort“ möglich.Informationsobjekte dieser Schutzbedarfskategorie sind vor unberechtigtemZugriff durch Verschlüsselungsverfahren geschützt. Das entsprechendeSchlüsselmaterial wird mit der Mechanismenstärke „Mittel“nach ITSEC geschützt.Der Zugriff auf ein Informationsobjekt dieser Schutzbedarfskategorieist nur nach einer Autorisierung entsprechend eines Verfahrens derProzessqualität wie z. B. „Zertifikat und Passwort“ möglich. Die Beantragung,die Ausstellung und das Zertifikatsmanagement entsprechendem Niveau einer fortgeschrittenen Signatur nach SigG/SigV.Der Besitzer der Daten muss den Zugriff einer natürlichen Person odereiner Personengruppe auf diese Daten durch explizite Zustimmungfreigeben.Informationsobjekte dieser Schutzbedarfskategorie sind vor unberechtigtemZugriff durch starke Verschlüsselungsverfahren geschützt. Dasentsprechende Schlüsselmaterial wird mit der Mechanismenstärke„Hoch“ nach ITSEC geschützt.Der Zugriff auf ein Informationsobjekt dieser Schutzbedarfskategorieist nur nach einer Autorisierung entsprechend eines Verfahrens derProzessqualität „Zertifikat und Passwort“ möglich. Die Beantragung,die Ausstellung und das Zertifikatsmanagement entsprechen dem Niveaueiner qualifizierten Signatur nach SigG/SigV.Der Besitzer der Daten muss den Zugriff einer ausschließlich natürlichenPerson auf diese Daten durch explizite Zustimmung freigeben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 439 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC3.2 - Schutzbedarfsklassen für Schutzziel IntegritätFür das Schutzziel Integrität gelten folgende Voraussetzungen für die zugrunde liegendeProzessqualitäten:SchutzbedarfNiedrigMittelHochSehr HochProzessqualitätIntegritätsprüfung erfolgt nach Ermessen, Integritätsverletzung könnennicht eindeutig und zweifelsfrei erkannt werden.Integritätsprüfung erfolgt nach Ermessen, Integritätsverletzung ist erkennbar,deren Verursacher sind nicht ermittelbar.Integritätsprüfung erfolgt an allen relevanten Prozessschritten, Integritätsverletzungist erkennbar, deren Verursacher ist nicht immer ermittelbar.Integritätsprüfung erfolgt an allen relevanten Prozessschritten, Integritätsverletzungist erkennbar, deren Verursacher ist immer ermittelbar.C3.3 - Schutzbedarfsklassen für Schutzziel VerfügbarkeitFür das Schutzziel Verfügbarkeit gelten folgende Wiederherstellungszeiträume (entsprichtder max. Dauer der Unterbrechung der Verfügbarkeit aufgrund einer dedizierten Ursache)meist für zentrale technische Komponenten wie z. B. Server-Systeme, Router etc.Verfügbarkeit Typ 1:Schutzbedarf Wiederherstellungszeitraum tägl. VerfügbarkeitNiedrig < 6 Stunden > 75%Mittel < 1 Stunde > 95,83Hoch < 10 min > 99,3Sehr Hoch < 1 min > 99,93Die konkrete zeitliche Verfügbarkeit bzw. die Servicezeiten und Betriebszeiten (z. B. 7x24oder nur während der regulären Arbeitsstunden) werden dienstindividuell geregelt.Für dezentrale Komponenten wie z. B. Konnektor, eGK, HBA gelten meist folgende maximaleWiederherstellungszeiträume, auch bezeichnet als Verfügbarkeit Typ 2:Verfügbarkeit Typ 2:SchutzbedarfNiedrigMittelHochSehr HochWiederherstellungszeitraum2 Wochen (14 Tage)1 Woche (7 Tage)3 Tage (72 Stunden)1 Tag (24 Stunden)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 440 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC3.4 - Schutzbedarfsklassen für Schutzziel NichtabstreitbarkeitFür das Schutzziel Nichtabstreitbarkeit gelten folgende Voraussetzungen für die zugrundeliegende Prozessqualitäten:SchutzbedarfNiedrigMittelHochSehr HochProzessqualitätHandlungen sind nicht eindeutig einer bestimmten Gruppe oder bestimmtennatürlichen Person zu zuordnen.Handlungen sind auf eine eindeutig bestimmbare Gruppe oder technischeEinheit rückführbar. Handlung kann vom Ausübenden bestrittenwerden. Nachweispflicht der Handlung liegt beim Kläger.Handlungen sind eineindeutig und auf eine natürliche Person rückführbar.Handlung kann vom Ausübenden nur schwer bestritten werden.Nachweispflicht der Handlung liegt bei beim Kläger. Die Nichtabstreitbarkeithat keine Beweiskraft vor Gericht.Handlungen sind eineindeutig und nachweisbar auf eine natürlichePerson rückführbar. Nachweispflicht der Nicht-Handlung liegt beimHandelnden. Die Nichtabstreitbarkeit hat Beweiskraft vor Gericht.C3.5 - Schutzbedarfsklassen für Schutzziel AuthentizitätFür das Schutzziel Authentizität gelten folgende Voraussetzungen, für die zugrunde liegendeProzessqualitäten:SchutzbedarfNiedrigMittelHochSehr HochProzessqualitätHandlungen sind nicht eindeutig einer bestimmten Gruppe oder bestimmtennatürlichen Person zu zuordnen.Handlungen sind auf eine eindeutig bestimmbare Gruppe rückführbar.Handlungen sind eineindeutig auf eine natürliche Person rückführbar.Handlungen sind eineindeutig und nachweisbar auf eine natürlichePerson rückführbar.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 441 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturC4 - Informationsobjekte und DatenklassenDie Menge der Informationsobjekte stellt alle im Rahmen der Aufgabenerfüllung der Telematikinfrastrukturerfassten bzw. verarbeiteten Informationen dar.Ziel ist es, zu jedem relevanten Informationsobjekt eine Schutzbedarfsfeststellung zu haben:Entweder eine genaue passend für dieses Informationsobjekt oder eine mehr pauschaleüber die Schutzbedarfsfeststellung der Datenklasse.Die Schutzbedarfsfeststellung eines einzelnen Informationsobjekts kann die Eigenheitenund Rahmenbedingungen eines Informationsobjekts viel genauer berücksichtigen als diemehr pauschale Schutzbedarfsfeststellung einer Datenklasse. Liegt also zu einem einzelnenInformationsobjekt eine Schutzbedarfsfeststellung vor, so gilt diese uneingeschränkt.Die zusätzliche Zuordnung dieses Informationsobjekts zu einer Datenklasse ist daher unnötig.Das folgende Kapitel beschreibt kurz die Informationsobjekte und Datenklassen.C4.1 - InformationsobjekteDie folgende Tabelle gibt eine Übersicht der bisher identifizierten Informationsobjekte 36 :Tabelle 34: InformationsobjekteID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltIo001 Versichertendaten - Alle Daten die in den Dateien:EF.PD und EF.VD stehen, d.h. dieminimalen Daten um den Versichertenzu verwalten. Für nähereInformationen siehe[gemSpec_eGK_P2].Io002 Leistungserbringerdaten- Alle relevanten Daten, die einenLeistungserbringer zuzuordnensind.Io003 Verordnungsdaten - Datensatz der Informationen übereine zu erbringende Leistung enthält(§ 291a, Abs.2 Satz 1 Nr.1SGB V).Io004eVerordnung für ArzneimittelDatensatz, der Informationen übereine zu erbringende Leistung enthält.Io005 Verordnung zur Kran- Datensatz, der Informationen über36 Falls Felder frei sind, sind diese Informationsobjekte für die Autoren selbst erklärend und bedürfenkeiner weiteren Beschreibung.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 442 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltIo006Io007Io008Io009Io010Io011Io012Io013kenhausbehandlungVerordnung zur physikalischenTherapie undPodologeneine zu erbringende Leistung enthält.Datensatz, der Informationen übereine zu erbringende Leistung enthält.Verordnung zu Maßnahmender Stimm-, Sprech- eine zu erbringende Leistung ent-Datensatz, der Informationen überund Sprachtherapie hält.Verordnung einer HörhilfeVerordnung einer ErgotherapieVerordnung einer SoziotherapieVerordnung einer SehhilfeÜberweisung zum FacharztDatensatz, der Informationen übereine zu erbringende Leistung enthält.Datensatz, der Informationen übereine zu erbringende Leistung enthält.Datensatz, der Informationen übereine zu erbringende Leistung enthält.Datensatz, der Informationen übereine zu erbringende Leistung enthält.Datensatz, der Informationen übereine zu erbringende Leistung enthält.Überweisung zum Labor Datensatz, der Informationen übereine zu erbringende Leistung enthält.Io015 Dispensierdaten - Inhalte noch unbekannt/aber Existenzdes Info-Objektes gesichert.Io016 Notfalldaten - Die Bereitstellung von Notfalldatengehört zu den freiwilligen Anwendungender eGK. Die eigentlichenInformationen werden im Rahmender Notfallmedizin benötigt: z. B.Kontraindikationen für Notfallmedikamente,Allergien, etc. (§ 291a,Abs. 3 Satz 1 Nr. 1 SGB V).Io017 Elektronischer Arztbrief(eAB)Io018 Elektronische Patientenakte(ePA)- Noch unklar, welche Daten esenthält (allgemein § 291a, Abs. 3,Satz1 Nr. 2 SGB V).- Ist ein Synonym für ein durch eineeindeutige OID identifizierbaresObjekt (§ 291a, Abs. 3 Satz Nr. 4SGB V).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 443 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltIo019 Eintrag in der PatientenakteIo020 ArzneimitteldokumentationIo021 Eintrag in ArzneimitteldokumentationIo023 Zugriffsprotokoll aufeGKIo025 Zertifikate mit dazugehörigenPublic-Keysder eGKIo026 Zertifikaten mit dazugehörigenPublic-Keysdes HBA- Ist ein Synonym für ein durch eineeindeutige OID identifiziertes Objekt(ein Eintrag in einer Patientenakte),dass einem anderendurch eine eindeutige OID identifizierbarenObjekt (der Patientenakte)zugeordnet wurde.- Synonym für ein durch eine eindeutigeOID identifizierbares Objekt.Für die Notfallmedizin relevanteArzneimittelinformationenmüssen in den Notfalldaten erfasstwerden.(allgemein § 291a, Abs. 3 Satz Nr. 3SGB V)- Synonym für ein durch eine eindeutigeOID identifiziertes Objekt(ein Eintrag in der Arzneimitteldokumentation),das einemanderen identifizierbaren Objekt(der Arzneimitteldokumentation)zugeordnet wurde.- Protokoll der letzten 50 Zugriffe.- Es wird von drei Public-Keys unddrei Zertifikaten (Authentisierung,Verschlüsselung, qualifizierte digitaleSignatur) auf der eGK ausgegangen.- Es wird von drei Public-Keys unddrei Zertifikaten (Authentisierung,Verschlüsselung, qualifizierte digitaleSignatur) auf dem HBA ausgegangen.Io045 Patientendaten - Alle über einen Versicherten erfasstenadministrativen und medizinischenDaten.Hierunter werden alle Daten verstanden,die bei einem Leistungserbringerüber einen Versichertengespeichert/vorhandensind (z. B. im PVS oder in Akten).Io046 Protokolle - Technische Logfiles und weiteretechnische Datenbestände mitden es möglich ist Bewegungs-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 444 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltIo048 VerordnungsdatenIo049 Elektronische Signaturdes LeistungserbringersIo050 Elektronische Signatureines VersichertenVerordnung von Sprechstundenbedarfprofile zu erstellen.Datensatz der Informationen übereine zu erbringende Leistung enthält.- Signatur eines Leistungserbringers- Signatur eines VersichertenIo052 Patientenquittung - (§ 291a, Abs. 3 Satz Nr. 6 SGB V)Io053 Geschützte VersichertendatenIo054 Pseudonym eines VersichertenIo055 KrankenversichertennummerIo060 VersichertenzentriertesAudit, Liste der Einträgeeines VersichertenIo061 Autorisierungsinformationen- Alle Daten die in der Datei: EF.GVDstehen.- -Io062 Sperrlisten -Io063 - Qualifizierte Zertifikate -Io064 - eGK -Io065 - HBA -- Lebenslang gültige einheitlicheKrankenversichertennummer einesVersicherten.- Versichertenzentriertes Audit, Listeder letzten 50 Einträge einesVersicherten bzw. die Einträge derletzten 12 Monate.- Informationen, die zur Realisierungvon Zugriffskontrollmechanismendienen (ACLs etc.)Io066 Temporäre Schlüssel - Kryptographische Schlüssel diezur Sicherung der Übertragungsstreckevon Informationengenutzt werden.Io067 Statische Schlüssel - Kryptographische Schlüssel diezur Sicherung von gespeichertenmedizinischen Daten genutzt werden.Io068 CAMS-Schlüssel - Zentralschlüssel eines Card-Management-Systems (CAMS).Io069 Master-Schlüssel - Zentralschlüssel einer PKI.Io070 Signatur PIN - PIN zur Verwendung eines kryptographischenSchlüssels zur Erstel-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 445 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-Inhaltlung einer qualifizierten Signatur.Io071 Authentifikations PIN - PIN zur Verwendung eines kryptographischenSchlüssels zur Authentifikation.Io072 Verwendete Software (TI) -Code sicherheitsrelevanter FunktionenIo073 Verschlüsselte, signiertemedizinische DatenIo079 Information der Sichtbarkeiteines anderenInformationsobjektesIo080Io081Io082Io083 Privater CVC-Key dereGKIo084 Privater CVC-Key derHBAIo085 PIN.home- Mittels statischer Schlüssel (Io067)erstellter Ciphertext von medizinischenDaten.Sichtbarkeit eines Eintragesin der PatientenakteSichtbarkeit eines Eintragseiner eVerordnung für ArzneimittelSichtbarkeit eines Eintragsin der ArzneimitteldokumentationInformation über die Sichtbarkeiteines Informationsobjektes (d. h.wann war ein Informationsobjektfür wenn sichtbar bzw. die Informationdarüber ob „nicht sichtbare/versteckte“Instanzen vorhandensind.)Information über die Sichtbarkeiteines Eintrages in der Patientenakte(d. h. wann war ein Eintragin der Patientenakte für wennsichtbar bzw. die Information darüberob „nicht sichtbare/versteckte“Einträge vorhandensind.)Information über die Sichtbarkeiteiner eVerordnung. Informationdarüber ob „nicht sichtbare/versteckte“eVerordnungen vorhandensind.Information über die Sichtbarkeiteines Eintrages in der Arzneimitteldokumentation(d. h. wann warein Eintrag in der Arzneimitteldokumentationfür wenn sichtbarbzw. die Information darüberob „nicht sichtbare/versteckte“Einträge vorhanden sind.- Private-Key zu dem der Karte zugeordnetenCVC.- Private-Key zu dem der Karte zugeordnetenCVC.Die globale Persönliche Identifikations-NummerPIN.home (PINzur Wahrnehmung der passivenVersichertenrechte an einem PCgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 446 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-Inhaltdurch den Versicherten und zurFreischaltung der PKI-SchlüsselPrK.CH.ENC und PrK.CH.AUT).Io086 ObjektTicketIo087 ServiceTicketIm ObjektTicket stehen die mitden öffentlichen Schlüsseln derBerechtigten Session-Keys(Schutzbedarf sehr hoch) mit demu. U. sensible Daten verschlüsseltsind. Ein Angreifer der das ObjektTicketliest, kann daher nichtauf diese vertraulichen medizinischenDaten zugreifen.Die Zustimmung eines Versichertenzur Verwendung einerfreiwilligen Anwendung wird durchdas Erstellen eines ServiceTicketsdurch den Versicherten für sichselbst dokumentiert. Durch dieErstellung eines ServiceTickets füreinen Heilberufler kann der Versicherteeinen Heilberufler dazuberechtigen, neue Datenobjektefür den Versicherten in dessenAbwesenheit zu erstellen. Durchdie Erstellung eines ServiceTicketsfür einen Treuhänder kannder Versicherte festlegen, welcheIdentitäten automatisch bei derErstellung eines Objektes hinterlegtwerden, so dass diese Identitätenbei dem Verlust der eGK desVersicherten einen Schlüssel fürdie neue eGK hinterlegen können.Durch die Erzeugung eines ServiceTicketsfür einen ständigen Vertreterkann der Versicherte Personenhinterlegen, die in seinerAbwesenheit als Datenautoritätagieren können. Diese ständigenVertreter werden bei dem Erzeugeneines Objektes automatischals Datenautorität in das neu erstellteObjektTicket eingefügt underben die im ServiceTicket hinterlegtenRechte. Ständige Vertreterhaben keinen Zugriff zum Erteilenzusätzlicher Rechte oder zurUmschlüsselung von Daten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 447 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltDurch die Erzeugung eines ServiceTicketsfür Vertreter ist der Versichertein der Lage, Personen zuhinterlegen, die auf seinenWunsch bei der Erstellung einesObjektes in seiner Abwesenheitdurch den Heilberufler als Datenautoritäthinterlegt werden können.Io090 SMC-A CVC Zertifikatund dazugehörigerPublic-KeyIo091 Privater CVC-Key derSMC-AIo092 SMC-B Public-Keys zuZertifikaten---Io093 SMC-B Private Keys -Io094 SMC-B CVC Zertifikatund dazugehörigerPublic-KeyIo095 Privater CVC-Key derSMC-BIo096 CVC-Zertifikat und dazugehörigerPublic-Keydes HBAIo097 CVC-Zertifikat und dazugehörigerPublic-Keyder eGKIo098 Private-Keys (Verschl.und Auth.) des HBAIo099 Private-Keys (Verschl.und Auth.) der eGKIo100 Private-Key (Signatur)der eGKIo101 Private-Key (Signatur)des HBA----Es wird von zwei Private-Keys(Authentisierung, Verschlüsselung)ausgegangen, welche PINgeschützt sind.Es wird von zwei Private-Keys(Authentisierung, Verschlüsselung)ausgegangen, welche PINgeschützt sind.Es wird von einem Private-Key fürdie qualifizierte Signatur ausgegangen,welche PIN geschützt ist.Es wird von einem Private-Key fürdie qualifizierte Signatur ausgegangen,welche PIN geschützt ist.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 448 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltIo103 VersichertenzentriertesAudit, Einzeleintrageines VersichertenIo104 VersichertenzentriertesAudit, Liste der Einträgealler Versichertenbzw. einer Gruppe.Io105 Antwort des OCSPBasisdienstIo106 CRListen des CRLValidation und CRLProvider BasisdiensteIo107 TSL des TSL RetrievalBasisdienstVersichertenzentriertes Audit, nurein einziger Eintrag .Versichertenzentriertes Audit, Listealler Einträge aller Versichertenbzw. einer Gruppe.Der OCSP-Responder-Dienst implementierteine Schnittstelle gemäßRFC 2560 (Appendix 1) überHTTP. Aufgabe des OCSP-Responders ist es, auf Anfrage dieGültigkeit eines Zertifikates zubestätigen oder zu widerrufen.Der Certificate Revocation ListValidation Basisdienst dient zurÜberprüfung des Zertifikatsstatusgegenüber einer CRL. CRLs sindzur Statusüberprüfung lediglich alsOptimierung möglich, generell istOCSP zu verwenden. SolltenCLRs zur Optimierung verwendetwerden, so muss die Verwendungvon CRLs näher spezifiziert werden.Hier stellt sich generell dasProblem der Verteilung der CRL.Es muss hierbei entschieden werden,welche CRLs auf welchenSystemen zur Optimierung vorgehaltenwerden. EntscheidendeFaktoren sind hierbei, wie häufigsich der Inhalt der CRL ändert undwie häufig auf eine CRL zugegriffenwird. Nachdem diese Entscheidunggetroffen wurde, mussein Konzept erstellt werden, umeine Verteilung außerhalb derHauptlastzeiten zu realisieren. Andieser Stelle soll keine weitereAusführung erfolgen, da es sichum eine optionale Optimierunghandelt. GA_12.4.8 .Aufgabe des TSL Retrieval Basisdienstesist es, eine lokale Versioneiner TSL zu verwalten undzu aktualisieren. Neue Versionender TSL werden durch den TSLgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 449 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltRetrieval Basisdienst von einemTSL Provider Basisdienst heruntergeladen.Hierzu wird das http-Protokoll verwendet, da wederVertraulichkeit noch Integritätsschutzauf dieser Ebene sicherzustellensind. GA_12.4.9Io108 TS-Listen des TSLCreator BasisdienstIo109 Private-Key des TSLCreator Basisdienstzum Signieren der TSLIo110 Public-Key und dazugehörigesZertifikatdes TSL Creator BasisdienstIo111 Cache des Service-DirectoryService(SDS).Io114 Private-Key des SecurityConfirmationService(SCS)Io115 Public-Key und dazugehörigesZertifikatdes SCSIo116 Liste aller Einträge einerPerson im UpdateFlag Service (UFS)Aufgabe des TSL Creator Basisdienstist es, neue Versionender TSL zu erzeugen und den TSLProvider Basisdienst-Instanzenzur Verfügung zu stellen.GA_12.4.11Aufgabe des TSL Creator Basisdienstist es, neue Versionender TSL zu erzeugen und den TSLProvider Basisdienst-Instanzenzur Verfügung zu stellen.GA_12.4.11Aufgabe des TSL Creator Basisdienstist es, neue Versionender TSL zu erzeugen und den TSLProvider Basisdienst-Instanzenzur Verfügung zu stellen.GA_12.4.11Siehe oben. GA_12.11.5 SDSSecurityConfirmationService(SCS). Eine erfolgreiche Validierungdes SVS kann der Broker-Service durch eine Signatur desSecurityConfirmationService bestätigen.Der BrokerService mussdie Authentizität von Nachrichtenbestätigen, die durch identifizierende,verschlüsselte Zertifikateanonymisiert oder pseudonymisiertsind. GA_12.11.7 SCSSiehe oben.Aufgabe des Update Flag Serviceist das Statusmanagement undeine Proxyfunktion für notwendigeKartenupdates: der UFS verwaltetgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 450 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-Inhaltzentral die Information, welcheFachdienste auf die eGK zugreifenmöchten. Durch die ProxyfunktionUFS entfällt der Aufwand,bei jedem Kontakt der eGK mit derTelematikinfrastruktur jeden Fachdienst,der potenziell auf die eGKzugreifen möchte, explizit nacheinem Update zu fragen. Dementsprechendmuss der UFS vonjedem Fachdienst informiert werden,der ein Update für eine eGKvorhält bzw. schreibend auf dieeGK zugreifen möchte. Wenn einFachdienst konkret benachrichtigtwerden möchte, setzt dieserFachdienst ein entsprechendesUpdate Flag im UFS. Sobald dieeGK anschließend z. B. im Rahmeneines Arztbesuches odereines Krankenhausaufenthaltes inKontakt mit der Telematikinfrastrukturtritt, wird abgefragt,ob für diese eGK UpdateFlags gesetzt sind, und es wirdggf. eine Verbindung zum anfragendenFachdienst aufgebaut.GA_12.13.2Io117 Menge aller Listen vonallen Personen im UFSIo118 Private-Key des VPN-KonzentratorIo119 Public-Key und dazugehörigesZertifikatdes VPN-KonzentratorsIo120 Private-Key des Ticket-Treuhänders-Der VPN-Konzentrator trennt zwischenZugangsnetz und Frontend-VPN. IPSec Layer 2 TunnelingProtocol wird auf der Zugangsstreckezwischen Konnektorenund VPN-Konzentratoren eingesetzt.Siehe auch BrokerGA_6.7.1-Jeder Versicherte KANN Objekt-Schlüssel bei einem Treuhänderzur Datenwiederherstellung hinterlegen.Durch Service-TicketsKÖNNEN Versicherte Ticket-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 451 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltTreuhänder festlegen und so einen‚Hinterlegungsvertrag’ (eng.escrow agreement) dokumentieren.GA_?Io121 Public-Key und dazugehörigesZertifikatdes Ticket-TreuhändersIo122 Private-Key der CV-RootIo123 Public-Key und dazugehörigesZertifikat derCV-RootIo124 Private-Keys der CV-SUB-CAIo125 Public-Keys und dazugehörigeZertifikate derCV-SUB-CAIo126 Private-Keys eines Telematikservices(SSL)Io127 Public-Keys und dazugehörigeX.509-Zertifikateeines Telematikservices(SSL)Io128 Private-Key der X.509-Telematikservice-CAIo129 Public-Key und dazugehörigesZertifikat derX.509-Telematikser-vice-CAIo130 Private-Key der X.509-Telematiknetz-CAIo131 Public-Key und dazugehörigesZertifikat derX.509-Telematiknetz-CAIo132 Private-Key der eGK-X.509 Root-Mit diesem Schlüssel werden dieCV-Zertifikate der CV-Sub-CAssigniertDiesen öffentlichen Schlüsselmuss jede eGK und HBA sicherspeichern und verfügbar haben.Mit diesem Schlüssel werden dieCV-Zertifikate der Karten signiert.Dieses CV-Zertifikat kann in derKarte verifiziert werden. SSchlüssel für SSL/TLSZertifikat für SSL/TLSMit diesem Schlüssel werden dieZertifikate der SSL Service-Instanzen signiert.Mit diesem öffentlichen Schlüsselwerden die SSL-Zertifikate derService-Instanzen signiert.Mit diesem Schlüssel werden dieZertifikate der IPsec-Netz-Instanzen signiert.Mit diesen öffentlichen Schlüsselwerden die Zertifikate der IPsec-Netz-Instanzen signiertMit diesem Schlüssel werden dieX.509-Zertifikate der X.509 Sub-CAs signiertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 452 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltIo133 Public-Key und dazugehörigesZertifikat dereGK-X.509-RootIo134 Private-Keys der eGK-X.509-SUB-CAIo135 Public-Keys und dazugehörigeZertifikate dereGK-X.509-SUB-CAIo136 Private-Keys der SM-KIo137 Public-Keys und dazugehörigeZertifikate derSM-KIo138 Private-Keys der SM-KTDieses Zertifikat ist der Vertrauensankerbei der eGK und wirdauch von HBA-Root anerkannt.Mit diesem Schlüssel werden dieeGK-X.509-Zertifikate der eGKssigniert-Privater Schlüssel zur Geräteidentitätdes Konnektors in einemsicheren Schlüsselspeicher (SM-K, i. d. R. Chipkarte). Aufgabender SM-K sind: Bestätigung alszugelassener Konnektor und AufbauVPN zur TI (Netzzugang +sicherer Kanal), Erzeugung vonZufall hoher Güte.Die SM-K MUSS dabei:den privaten Schlüssel sicherschützen, d. h., dass er physikalischenAngriffen widerstehenMUSS (Tamper Resistance),für den privaten Schlüssel Entschlüsselungund Verschlüsselung/Signaturfür die Authentifizierungunterstützen, wobei für dieBenutzung des privaten Schlüsselskeine Benutzerverifikationerforderlich ist.Öffentliche Schlüssel und Zertifikatezur Geräteidentität desKonnektors in einem sicherenSchlüsselspeicher (SM-K,i. d. R. Chipkarte). Aufgaben derSM-K sind: Bestätigung als zugelassenerKonnektor und AufbauVPN zur TI (Netzzugang + sichererKanal), Erzeugung vonZufall hoher Güte.Die SM-K MUSS dabei den öffentlichenSchlüssel frei auslesen lassen.Privater Schlüssel zur Geräteidentitätdes Kartenterminals ineinem sicheren Schlüsselspeichergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 453 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-Inhalt(SM-KT, i. d. R. Chipkarte). Aufgabender SM-KT sind: Bestätigungals baugruppenzugelassenesTerminal und AufbauTLS zum Konnektor (sichererKanal).Als zusätzliche Sicherung gegenunbemerkten Austausch von Gerätenoder deren Identitäten, wirdüber ein zusätzliches Verfahrendie SM-KT über den Konnektorlogisch an das eHealth-Terminalgebunden.Io139 Public-Keys und dazugehörigeZertifikate derSM-KTIo140 Symmetrische Objektschlüsselbzgl. verschlüsseltenpers. bezogenenmedizinischenDatenIo141 Liste der BerechtigungenIo142 ObjektTicket (unsigniert)Io143 ServiceTicket (unsigniert)Io144 HybridschlüsselÖffentliche Schlüssel und Zertifikatezur Geräteidentität des Kartenterminalsin einem sicherenSchlüsselspeicher (SM-KT, i. d. R.Chipkarte). Aufgaben der SM-KTsind: Bestätigung als baugruppenzugelassenesTerminal und AufbauTLS zum Konnektor (sichererKanal).Als zusätzliche Sicherung gegenunbemerkten Austausch von Gerätenoder deren Identitäten, wirdüber ein zusätzliches Verfahrendie SM-KT über den Konnektorlogisch an das eHealth-TerminalgebundenWurde bisher als statischer symmetrischerSchlüssel geführt, sollteaufgrund der Bedeutung eineigenes Informationsobjekt werden.Wird eine Person/Instanz als Empfängergeführt, so kann die Person/Instanzden Objekt-schlüsselfür medizinische Daten entschlüsseln.Siehe Io086. Das ObjektTicket isthier noch nicht signiert.Siehe Io087. Das ServiceTicket isthier noch nicht signiert.Symmetrischer Schlüssel für einmedizinisches Datenobjekt verschlüsseltmit dem öffentlichengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 454 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung Subtyp-Bezeichnung Überblick-InhaltSchlüssel eines Berechtigten.Io145 BerechtigungshistorieHistorie der vom Versicherten vergebenenBerechtigungen.C4.2 - DatenklassenFür einen aus sicherheitstechnischer Sicht effizienten Umgang mit Informationsobjektenwerden diese mittels Datenklassen in Äquivalenzklassen zusammengefasst. Informationsobjektesind wie folgt definiert: Es sind alle im Rahmen der Aufgabenerfüllung der Telematikinfrastrukturerfassten bzw. verarbeiteten Informationen, welche einer Datenklassezugeordnet sind.In Fällen, in denen keine eindeutige Zuordnung eines Informationsobjekts zu einer Datenklassemöglich ist, weil es z. B. in zwei oder mehr Datenklassen vorkommen kann, wirddas Informationsobjekt der Datenklasse zugeordnet, welche den höchsten Schutzbedarfaufweist. Die Tabelle gibt einen Überblick über die vorhandenen Datenklassen:Tabelle 35: Alle Datenklassen und ihre BeschreibungID Bezeichnung BeschreibungDk01PersonenbezogeneDaten: DK_persPersonenbezogene Daten sind Einzelangaben über persönlicheoder sachliche Verhältnisse einer bestimmtenoder bestimmbaren natürlichen Person (Betroffener)(BDSG § 3, Abs.1).Dk02 Sozialdaten: DK_soz Sozialdaten sind Einzelangaben über persönliche oder sachlicheVerhältnisse einer bestimmten oder bestimmbaren natürlichenPerson (Betroffener), die von einer in§ 35 des Ersten Buches genannten Stelle im Hinblick auf ihreAufgaben nach diesem Gesetzbuch erhoben, verarbeitet odergenutzt werden. Betriebs- und Geschäftsgeheimnisse sindalle betriebs- oder geschäftsbezogenen Daten, auch vonjuristischen Personen, die Geheimnischarakter haben (SGB X,§ 67 Abs. 1).Dk03Dk04Personenbezogenemedizinische Daten:DK_medAnonymisierte medizinischeDaten:DK_med_anoNicht anonymisierte med. Daten. Dies sind personenbezogeneDaten besonderer Art (gem. BDSG § 3(9))Med. Daten, die in anonymisierter Form vorliegen. Der Anonymisierungs-Mechanismusmuss Mechanismenstärke „hoch“haben. Anonymisieren ist das Verändern personenbezogenerDaten derart, dass die Einzelangaben über persönlicheoder sachliche Verhältnisse nicht mehr oder nur miteinem unverhältnismäßig großen Aufwand an Zeit, Kostenund Arbeitskraft einer bestimmten oder bestimmbarennatürlichen Person zugeordnet werden können (BDSG§ 3, Abs. 6). Statische Daten über medizinische Vorgänge, diekeinerlei Rückschluss auf die Einzelvorgänge ermöglichen,sind auch anonymisierte medizinische Datengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 455 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturID Bezeichnung BeschreibungDk05Dk07Dk08Dk09Dk10Pseudonymisiertemedizinische Daten:DK_med_pseudoMetadaten der medizinischenDaten:DK_org_medSystemdaten:DK_sysÖffentliche Sicherheitsobjekte:DK_SIO_pubTemporäre Sicherheitsobjekteund kryptographischeDaten :DK_SIO_tempMed. Daten die in pseudonymisierter Form vorliegen. Pseudonymisierenist das Ersetzen des Namens und anderer Identifikationsmerkmaledurch ein Kennzeichen zu dem Zweck, dieBestimmung des Betroffenen auszuschließen oder wesentlichzu erschweren. (BDSG §3, Abs. 6a)Dienen zur Beschreibung der medizinischen Daten: Beispielsweiseist dies das Erzeugungsdatum, Objektklasse oderFormat- bzw. Versionsinformationen.Daten, die zur Funktion eines Systems benötigt werdenoder zur Beschreibung eines Systemzustandes dienen(z. B. Auslastung eines IT-Systems, Status einer Transaktion).Daten, die zur Anwendung von asymmetrischen kryptographischenFunktionen im Rahmen von Prüfprozessenoder gerichteter vertraulicher Kommunikation (ÖffentlicherSchlüssel bei asymmetrische Verschlüsselung oder Zertifikate)benötigt werden.Daten, die zur Anwendung von Sicherheitsdiensten und insbesonderekryptographischer Funktionen dienen(z. B. kryptographische Session-Schlüssel), für die ein Mechanismuszur Beschränkung der Lebensdauer auf einenZeitraum (24h in Ausnahmenfällen 72 Stunden) existiert.DK11a kryptographische Sicherheitsobjekteunterpersönlicher Kontrolle:DK_SIO_PrK_persDK11b Personen- bzw. RollenbezogeneSicherheitsobjekteund kryptographischeDaten:DK_SIO_PrK_IdDaten, die zur Anwendung von Sicherheitsdiensten und insbesonderekryptographischer Funktionen dienen, wie privatekryptographische Schlüssel für qualifizierte Signaturen undderen Benutzung der persönlichen Kontrolle durch eine PIN(o. ä.) unterliegen.Daten, die zur Anwendung von Sicherheitsdiensten und insbesonderekryptographischer Funktionen zur Darstellung vonIdentitäten und Rollen dienen wie private kryptographischeSchlüsselDK11cStatische Sicherheitsobjekteund pseudonymekryptographischeDaten:DK_SIO_PrK_autoDaten, die zur Anwendung von Sicherheitsdiensten und insbesonderekryptographischer Funktionen dienen(z. B. geheime und private kryptographische Schlüssel in Maschinenzertifikaten).Das Schlüsselmaterial lässt keinen (direkten)Rückschluss auf Identitäten zu.DK11d Vertrauliche persönlicheAuthentikationsmittel:DK_Auth_persPINs, PUKs und Passwörter.DK12Signierte und verschlüsseltemedizinischeDaten:DK_med_secMed. Daten, die durch ein zugelassenes Verschlüsselungsverfahrenverschlüsselt sind. Eine Wiederherstellung desKlartextes ist nur mit Zustimmung jener Person möglich, desseninformationellen Selbstbestimmungsrecht der Klartextunterliegt. Der Inhalt ist qualifizierte signiertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 456 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang D – Berechtigungsrichtlinien für TI-AnwendungenIn den Fachkonzepten Versichertenstammdatenmanagement (VSDM) [gemFK_VSDM],Verordnungsdatenmanagement (VODM) [gemFK_VODM], Notfalldatenmanagement(NFDM) [gemFK_NFDM] und AMTS [gemFK AMTS] sind Akteure und ihre fachlichen Berechtigungenbeschrieben. Dieser Abschnitt enthält die normative Berechtigungslinie fürdie TI-Anwendungen VSDM, VODM, NFDM und AMTS, die aus den fachlichen Berechtigungskonzeptender einzelnen Anwendungen resultiert.Es werden im Folgenden zunächst die Akteure und die möglichen fachlichen Aktionen aufInformationsobjekte beschrieben. Dann erfolgt eine Zuordnung der in diesen Anwendungenauftretenden Informationsobjekte zu den Datenklassen. Anschließend wird die Rollenhierarchieaus den fachlichen Akteuren erstellt. Danach wird die Berechtigungsliniebestehend aus den Informationsflussregeln spezifiziert.D1 - AkteureDie auftretenden fachlichen Akteure sind:• Versicherter• Arzt• Zahnarzt• Psychotherapeut• Mitarbeiter medizinische Institution• Apotheker• Mitarbeiter Apotheke• Mitarbeiter Rettungswesen• Kostenträger (umfasst GKV und PKV)Mitarbeiter in einer psychotherapeutischen Praxis DÜRFEN NICHT Zugriff auf Daten derTelematikinfrastruktur erhalten, da ihnen nach §291a Abs. 4 Nr.2 kein Zugriffsrecht zusteht.Daher wurden sie nicht in die obige Liste aufgenommen.D2 - Abbildung fachlicher Aktionen auf ZugriffsoperationenIn den Fachkonzepten sind die folgenden fachlichen Aktionen definiert:Tabelle 36: Fachliche AktionenAktionDefinitionAnzeigenDas Informationsobjekt wird dem Akteur visuell verfügbar gemacht.Die Daten bleiben am Ursprungsort unverändert erhalten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 457 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAktionSpeichernÄndernEntfernenVerschiebenAktualisierenVerbergen/sichtbar machenDefinitionDas Informationsobjekt wird auf einem Speichermedium der Telematik(eGK/Infrastruktur) abgelegt.Das Informationsobjekt wird mit neuen oder anderen Informationenversehen und dann an Stelle des bestehenden Informationsobjektsauf einem Speichermedium der Telematik (eGK/Infrastruktur) abgelegt.Das Informationsobjekt steht nach dem Zugriff nicht mehr zur weiterenNutzung durch die Akteure zur Verfügung.Das Informationsobjekt wird von seinem Ursprungsort zum Bestimmungsorttransportiert. Am Ursprungsort verbleibt keine Kopie desInformationsobjektes.Das geänderte Informationsobjekt wird an Stelle des bestehendenInformationsobjekts auf einem Speichermedium der Telematik(eGK/Infrastruktur) abgelegt.eVerordnungen können vom Versicherten verborgen und wiedersichtbar gemacht werden. Freiwillige Anwendungen können vomVersicherten deaktivitiert und reaktiviert werden.Die fachlichen Aktionen werden auf die im Berechtigungsmodell vorhandenen OperationenCreate, Read, Update, Delete, Hide und Unhide abgebildet. Die Abbildung ist wiefolgt:Tabelle 37: Zuordnung fachlicher AktionenFachliche Aktion Operation des BerechtigungsmodellsAnzeigenSpeichernÄndernEntfernenReadCreateUpdateDeleteVerschieben Delete und Create (zusammengefasst in einer Transaktion Move 37 )AktualisierenVerbergenSichtbar machenUpdateHideUnhideD3 - DatenklassenAbbildung 29 beschreibt die für die Anwendungen benötigten Datenklassen mit ihren Verfeinerungen.Die blau hinterlegten Datenklassen sind Anhang C entnommen, die grün37 Für die beiden Operationen Delete und Create wird an dieser Stelle eine Transaktion Move eingeführt.Für diese Transaktion muss sowohl das Recht Create als auch Delete vorhanden sein.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 458 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturhinterlegten sind Verfeinerungen zur weiteren Differenzierung der fachlichen Telematik-Anwendungen.Abbildung 29: DatenklassenD4 - RollenhierarchieAus den fachlichen Akteuren wird eine Rollenhierarchie gebildet. Abbildung 30 stellt dieRollenhierarchie dar. Rollen mit blauem Hintergrund sind nicht-abstrakte Rollen, rote Rollen(bzw. Rollen mit Stereotype ) sind abstrakt.Abbildung 30: RollenhierarchieAbstrakte Rollen dienen einer einfacheren und handhabbareren Darstellung und Verwaltungder Berechtigungen, sie dienen jedoch nicht der Modellierung von fachlichen Akteuren.An abstrakte Rollen können (genauso wie an nicht abstrakte Rollen) Berechtigungengeknüpft werden, die sie an Rollen vererben (z. B. erben die nicht abstrakten Rollen Arzt,Zahnarzt und Mitarbeiter med. Institution alle Berechtigungen der abstrakten Rolle Arzt). Im Unterschied zu nicht-abstrakten Rollen, dürfen Subjekte nicht abstraktenRollen zugeordnet werden. Subjekte müssen immer nicht-abstrakten Rollen zugeordnetsein.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 459 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDas Personal von Zahnärzten wird ebenfalls der Rolle Mitarbeiter med. Institution zugeordnet.D5 - BerechtigungsrichtlinieFür die Informationsflussvorschriften werden folgende Kriterien unterschieden:• Verschlüsseln (V): Bevor Informationen in oder aus dem Datenort fließen,müssen diese verschlüsselt sein.• Entschlüsseln (E): Bevor Informationen in oder aus dem Datenort fließen,müssen diese entschlüsselt sein.• Signieren (S): Die aus dem bzw. zum Datenort fließenden Informationen sindmit dem Signaturschlüssel der qualifizierten elektronischen Signatur einesHBA signiert.• Signatur prüfen (P): Geprüfte und gültige qualifizierte elektronische Signatureines HBAs vorhanden.• Auditieren (A): Der Zugriff auf das Informationsobjekt im Datenort ist zu auditieren.Insbesondere müssen Zugriffe der berufsmäßigen Gehilfen oder Personen,die zur Vorbereitung auf den Beruf tätig sind, entsprechend §291aAbs.5 auditiert werden.• Anonymisieren (An): Die Identität des Leistungserbringers in der zurZugriffsoperation gehörenden Zugriffsinformation ist durch ein Anonym ersetzt(d. h. durch die Identität des zuständigen Brokers).• Pseudonomysieren (Pn): Die Identität des Zugreifenden ist pseudonomysiert.D5.1 - Notation von BerechtigungsrichtlinienBerechtigungsrichtlinien werden in Tabellenform notiert. Für jede Datenklasse gibt es dabeieine eigene Tabelle, die sich auf ein oder mehrere Datenorte beziehen kann. Vertikalsind in einer Tabelle die (abstrakten und nicht abstrakten) Rollen und horizontal dieZugriffsoperationen notiert.Enthält der Tabelleneintrag für Rolle X und Zugriffsoperation Y das Zeichen “-“, so hat dieRolle X keine Berechtigung zum Aufruf der Zugriffsoperation Y auf Objekten der Datenklasse.Andernfalls enthält der Tabelleneintrag einen Term der Form iv/(const). In diesemFall hat die Rolle X die Berechtigung zum Aufruf der Zugriffsoperation Y unter der Voraussetzung,dass die in iv angegebenen Informationsflussvorschriften und die in constdefinierten Constraints erfüllt sind. Die Informationsflussvorschriften iv sind eine Kombinationaus den oben gegebenen Kriterien V, E, S, P, A und An. Die in den Informationsflussvorschriftenauftretende Reihenfolge der Kriterien drückt jedoch nicht eine gefordertetechnische Reihenfolge aus.Die von einer anderen Rolle ererbten Berechtigungen werden kursiv geschrieben.Beispiel: Tabelle 40 beschreibt die Berechtigungen auf Objekte der Datenklasse VODbzgl. des Datenortes eGK. Die Bedeutung des Tabelleneintrages AVS/() in der Zeile Arztund der Spalte Create ist wie folgt:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 460 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Ein Arzt darf eVerordnungen auf der eGK speichern.• Die Informationsflussvorschriften AVS fordern, dass ein Speichern auf dereGK nur möglich ist, wenn der Zugriff auditiert (A) wird und die eVerordnungverschlüsselt (V) und signiert (S) ist. Ist eines der Kriterien nicht erfüllt, ist einSpeichern auf der eGK nicht möglich.• Es gibt keine weiteren Constraints an das Speichern von eVerordnungen anden Arzt, da die Liste der Constraints leer ist (notiert durch das leere Klammerpaar() ).• Der Eintrag AVS/() ist kursiv. Daher wurde diese Berechtigung von einer anderenRolle geerbt (in diesem Fall von der abstrakten Rolle Arzt).Bei der Umsetzung der Berechtigungslinien für die eGK ist zu erwähnen, dass in der eGK-Spezifikation [gemSpec eGK-P2] einige der in den folgenden Berechtigungsrichtliniengetrennt betrachteten Operationen auf gemeinsame technische Kartenoperationen abgebildetwerden, d.h. die eGK diese Trennung der Operationen momentan nicht vorsieht.Zum Beispiel werden die in den folgenden Berechtigungsrichtlinien getrennt betrachtetenOperationen Update und Delete in der eGK nicht unterschieden und auf eine gemeinsameKartenoperation abgebildet [gemSpec eGK-P2].D5.2 - PflichtanwendungenD5.2.1 - VersichertenstammdatenmanagementDie nicht geschützten VSD können ohne weitere Sicherheitsmaßnahmen ausgelesenwerden. Die geschützten VSD können hingegen nur von zugriffsberechtigten Personenmittels eines Authentifizierungswerkzeuges ausgelesen werden. Es muss nur der Zugriffauf die geschützten Versichertendaten protokolliert werden. Im Folgenden werden dieBerechtigungsrichtlinien für die geschützten VSD angegeben.Tabelle 38: Berechtigungsrichtlinie: geschützte VSD auf der eGK 38Datenklasse: geschützte VSDDatenort: eGKSubjekt Create Read Update Delete Un-/HideVersicherter - APn/(C7) - - - Leistungserbringer- - - - - Arzt - A/(C7) - - -Arzt - A/(C7) - - -Zahnarzt - A/( C7) - - -Mitarbeiter med.Institution. A/( C7) - - -38 Zeitlich begrenzt ist momentan der Zugriff auf die geschützten VSD analog zum Zugriff auf dieungeschützten VSD geregelt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 461 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDatenklasse: geschützte VSDDatenort: eGKSubjekt Create Read Update Delete Un-/Hide Apotheker- A/( C7) - - -Apotheker - A/( C7) - - -Mitarbeiter Apotheke - A/( C7) - - -Psychotherapeut - A/( C7) - - -Mitarbeiter Rettungswesen- A/( C7) - - -Kostenträger A/(C1) A/(C1) A/(C1) A/(C1) -Tabelle 39: Berechtigungsrichtlinie: geschützte VSD im FachdienstDatenklasse: geschützte VSDDatenort: FachdienstSubjekt Create Read Update Delete Un-/HideVersicherter - APn/(C7) - - - Leistungserbringer- - - - - Arzt - AAn/( C7) - - -Arzt - AAn/( C7) - - -Zahnarzt - AAn/( C7) - - -Mitarbeiter med.Institution Apotheker- AAn/( C7) - - -- AAn/(C7) - - -Apotheker - AAn/(C7) - - -Mitarbeiter Apotheke- AAn/(C7) - - -Psychotherapeut - - - - -Mitarbeiter Rettungswesen- - - - -Kostenträger A/(C1) A/(C1) A/(C1) A/(C1) -Constraints:Constraintnr. Constraintbeschreibung() kein ConstraintC1Der Versicherte ist Kunde des Kostenträgers.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 462 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturConstraintnr. ConstraintbeschreibungC7In Verbindung mit HBA/SMC-B oder mit PIN.homeD5.2.2 - VerordnungsdatenmanagementTabelle 40: Berechtigungsrichtlinie: VOD auf eGKDatenklasse: VODDatenort: eGKSubjekt Create Read Update Delete Un-/HideVersicherter - AEPPn/(C2) - APn/(C2) APn/(C2)Leistungserbringer- - - - - Arzt AVS/(C5) AEP/(C4,C5) - A/(C4,C5) -Arzt AVS/(C5) AEP/(C4,C5) - A/(C4,C5) -Zahnarzt AVS/(C5) AEP/(C4,C5) - A/(C4,C5) -Mitarbeiter med.Institution ApothekerAVS/(C5) AEP/(C4,C5) - A/(C4,C5) -AVS/(C5,C8) AEP/(C4,C5) - A/(C4,C5) -Apotheker AVS/(C5,C8) AEP/(C4,C5) - A/(C4,C5)Mitarbeiter ApothekeAVS/(C5,C8) AEP/(C4,C5) -A/(C4,C5)Psychotherapeut - - - - -Mitarbeiter Rettungswesen- - - - -Kostenträger - - - - -Der bei der Ver- bzw. Entschlüsselung benötigte Schlüssel in Tabelle 40 ist ein vom Konnektorerzeugter symmetrischer Schlüssel spezifisch für eine eVerordnung. Die Informationsflussvorschrift"S" bezieht sich bei elektronischen Verordnungen auf die Signatur desArztes bzw. Zahnarztes auf die Verordnungsdaten.Tabelle 41: Berechtigungsrichtlinie: VOD im FachdienstDatenklasse: VODDatenort: FachdienstSubjekt Create Read Update Delete Un-/HideVersicherter AVSPn/(C9) AEPPn/(C2) - APn/(C2) APn/(C2)Leistungserbringer- - - - - Arzt AVS/(C5) AEP/(C4,C5) - A/(C4,C5) -Arzt AVS/(C5) AEP/(C4,C5) - A/(C4,C5) -gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 463 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDatenklasse: VODDatenort: FachdienstSubjekt Create Read Update Delete Un-/HideZahnarzt AVS/(C5) AEP/(C4,C5) - A/(C4,C5) -Mitarbeiter med.Institution ApothekerAVS/(C5) AEP/(C4,C5) - A/(C4,C5) -AVS/(C5,C8) AEP/(C4,C5) - A/(C4,C5) -Apotheker AVS/(C5,C8) AEP/(C4,C5) - A/(C4,C5) -Mitarbeiter ApothekeAVS/(C5,C8) AEP/(C4,C5) - A/(C4,C5) -Psychotherapeut - - - - -Mitarbeiter Rettungswesen- - - - -Kostenträger - - - - -Der bei der Ver- bzw. Entschlüsselung benötigte Schlüssel in Tabelle 41 ist ein vom Konnektorerzeugter symmetrischer Schlüssel spezifisch für eine eVerordnung. Dieser wird imObjektTicket der Verordnung mit dem öffentlichen Schlüssel der eGK verschlüsselt. DieInformationsflussvorschrift "S" bezieht sich bei elektronischen Verordnungen auf die Signaturdes Arztes bzw. Zahnarztes auf die Verordnungsdaten.Constraints:Constraintnr. Constraintbeschreibung() kein ConstraintC2C4C5C8C9PIN des Versicherten erforderlicheVerordnung ist nicht verstecktIn Verbindung mit HBA/SMC-BNur diejenige eVerordnung, die vom Datenort entnommen wurde, abernicht dispensiert werden konnte und zurückgeschrieben werden soll.Nur zum Verschieben einer Verordnung von der eGK auf den Fachdienst.D5.3 - Versichertenzentrierte AuditdatenDie Auditdaten werden durch die Telematikinfrastruktur erstellt. Dies ist kein Recht, sonderndie Pflicht der technischen Komponenten (wie Konnektor oder Broker). In Tabelle 42bedeutet das Recht für Create bzw. Update für eine Rolle nicht, dass die Rolle die Auditdatenmanipulieren darf, sondern nur, dass deren Zugriffe auf Daten des Versicherten inden Audit-Dateien (auf der eGK oder im Audit-Dienst) erzeugt bzw. ergänzt werden können.Das Recht zum Update erlaubt hier lediglich das Anhängen von Audit-Einträgen,nicht das Überschreiben oder Ändern. Das Schreiben der Auditdaten erfolgt nach vorherigerAuthentifizierung des entsprechenden Subjekts.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 464 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 42: Berechtigungsrichtlinie: AuditdatenDatenklasse: versichertenzentrierte AuditdatenDatenort: eGK, FachdiensteSubjekt Create Read Update Delete Un-/HideVersicherter A/() A/(C2) A/() - -LeistungserbringerA/() - A/() - - Arzt A/() - A/() - -Arzt A/() - A/() - -Zahnarzt A/() - A/() - -Mitarbeiter med.Institution ApothekerA/() - A/() - -A/() - A/() - -Apotheker A/() - A/() - -Mitarbeiter Apotheke A/() - A/() - -Psychotherapeut A/() - A/() - -Mitarbeiter RettungswesenA/() - A/() - -Kostenträger A/() - A/() - -Constraints:Constraintnr. ConstraintbeschreibungC2PIN des Versicherten erforderlichD5.4 - Freiwillige AnwendungenD5.4.1 - Notfalldatenmanagement 39Tabelle 43: Berechtigungsrichtlinie: Notfalldaten auf eGKDatenklasse: NotfalldatenDatenort: eGKSubjekt Create Read Update Delete Un-/HideVersicherter - AP/(C2,C5) - A/(C2,C5) A(C6)39 Die zugriffsberechtigten Akteure sind im Fachkonzept [gemFK_NFDM] Version 1.3.0 noch nichtvollständig betrachtet. Es werden u.a. die Zugriffe der unter § 291a Abs. 4 Satz 1 Nr. 2 Buchstabed und e genannten Personen auf die Notfalldaten noch nicht berücksichtigt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 465 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDatenklasse: NotfalldatenDatenort: eGKSubjekt Create Read Update Delete Un-/HideLeistungserbringer- - - - - Arzt AS/(C2,C5) AP/(C5) APS/(C2,C5) A/(C2.C5) -Arzt AS/(C2,C5) AP/(C5) APS/(C2,C5) A/(C2.C5) -Zahnarzt AS/(C2,C5) AP/(C5) APS/(C2,C5) A/(C2,C5) -Mitarbeiter med.Institution ApothekerAS/(C2,C5) AP/(C5) APS/(C2,C5) A/(C2.C5) -- - - - -Apotheker - - - - -Mitarbeiter Apotheke- - - - -Psychotherapeut - - - - -Mitarbeiter Rettungswesen- AP/(C5) - - -Kostenträger - - - - -Tabelle 44: Berechtigungsrichtlinie: Notfalldaten im Fachdienst (Back-up)Datenklasse: NotfalldatenDatenort: FachdienstSubjekt Create Read Update Delete Un-/HideVersicherter - APE/(C5) - A/(C5) A(C6)Leistungserbringer- - - - - Arzt ASV/(C2,C5) APE/(C2,C5) APESV/(C2,C5) A/(C2,C5) -ArztZahnarztMitarbeiter med.Institution ApothekerASV/(C2,C5) APE/(C2,C5) APESV/(C2,C5) A/(C2,C5)ASV/(C2,C5) APE/(C2,C5) APESV/(C2,C5) A/(C2,C5)ASV/(C2,C5) APE/(C2,C5) APESV/(C2,C5) A/(C2,C5)- - - - -Apotheker - - - - -Mitarbeiter Apotheke- - - - -Psychotherapeut - - - - -gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 466 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDatenklasse: NotfalldatenDatenort: FachdienstSubjekt Create Read Update Delete Un-/HideMitarbeiter Rettungswesen- - - - -Kostenträger - - - - -Der bei der Ver- bzw. Entschlüsselung benötigte Schlüssel in Tabelle 44 ist ein vom Konnektorerzeugter symmetrischer Schlüssel spezifisch für einen Notfalldatensatz. Dieserwird im ObjektTicket des Notfalldatensatzes mit dem öffentlichen Schlüssel der eGK verschlüsselt.Constraints:Constraintnr. Constraintbeschreibung() kein ConstraintC2C5C6PIN des Versicherten erforderlichIn Verbindung mit HBA/SMC-BAlle Informationsobjekte der freiwilligen Anwendung (entspricht de-/reaktivieren der Anwendung)D5.4.2 - ArzneimitteltherapiesicherheitFür die Datenklasse Arzneimitteltherapiesicherheit ist der Datenort eGK nicht anwendbar.Alle Informationsobjekte befinden sich im Datenort Fachdienst.Tabelle 45: Berechtigungsrichtlinie: AMTS im Fachdienst 40Datenklasse: AMTSDatenort: FachdienstSubjekt Create Read Update Delete Un-/HideVersicherter - APE/(C5) - A/(C5) A(C6) Leistungserbringer- - - - - Arzt AVS/(C2,C5) APE/(C2,C5) AEPVS/(C2,C5) A/(C2,C5) -Arzt AVS/(C2,C5) APE/(C2,C5) AEPVS/(C2,C5) A/(C2,C5) -Zahnarzt AVS/(C2,C5) APE/(C2,C5) AEPVS/(C2,C5) A/(C2,C5) -40 Die Fachanwendung AMTS befindet sich noch in der Konzeption. Die Tabelle kann zu dieserZeit noch keinen Anspruch auf Vollständigkeit und Korrektheit erheben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 467 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDatenklasse: AMTSDatenort: FachdienstSubjekt Create Read Update Delete Un-/HideMitarbeiter med.Institution ApothekerAVS/(C2,C5) APE/(C2,C5) AEPVS/(C2,C5) A/(C2,C5) -AVS/(C2,C5) APE/(C2,C5) AEPVS/(C2,C5) A/(C2,C5) -Apotheker AVS/(C2,C5) APE/(C2,C5) AEPVS/(C2,C5) A/(C2,C5) -Mitarbeiter ApothekeAVS/(C2,C5) APE/(C2,C5) AEPVS/(C2,C5) A/(C2,C5) -Psychotherapeut - APE/(C2,C5) - - -Mitarbeiter Rettungswesen- - - - -Kostenträger - - - - -Constraints:Constraintnr. Constraintbeschreibung() kein ConstraintC2C5C6PIN des Versicherten erforderlichIn Verbindung mit HBA/SMC-BAlle Informationsobjekte der freiwilligen Anwendung (entspricht de-/reaktivieren der Anwendung)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 468 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang E – PIN/PUK- PolicyE1 - EinführungDer Zugriff auf die personenbezogenen und medizinischen Daten der Versicherten istdurch kryptographische Schlüssel geschützt, die durch die Eingabe von PINs freigeschaltetwerden. Um die Daten des Versicherten auf einem adäquaten Sicherheitsniveauzu schützen, sind daher auch diese PINs in der Telematikinfrastruktur in jedem Verarbeitungsschrittund zu jedem Zeitpunkt auf einem einheitlichen Mindestniveau zu schützen.Diese Mindestanforderungen gelten in gleicher Weise für PUKs, die für PIN-Änderungenbzw. für das Zurücksetzen des Fehlbedienungszählers einer PIN benötigt werden.Dieses Dokument gibt für den Gesamtbereich Kartenproduktion, Kartenausgabe, Karteneinzugder eGK und der HBA/SMC/BA (PIN.CH, PIN.home) sowie die Verwendung vondiesen PINs und den zugehörigen PUKs an allen betroffenen Komponenten der TelematikinfrastrukturMindeststandards vor, um das notwendige Sicherheitsniveau der Telematikinfrastrukturfür Zugriffe auf die Daten der Versicherten zu gewährleisten.Die Kartenherausgeber müssen bei der Auslieferung der Karten auch für die Übermittlungder zur Aktivierung verschiedener Funktionen benötigten PINs und PUKs sorgen. Austechnischer Sicht gibt es dafür verschiedene Verfahren, die jeweils unterschiedliche VorundNachteile haben. Dabei gilt es zwischen Sicherheitsanforderungen, Kosten für dieVerteilung und möglichen Auswirkungen auf die Nutzerakzeptanz abzuwägen. Mit diesemDokument werden Mindeststandards festgelegt, um das notwendige Sicherheitsniveauder Telematikinfrastruktur zu gewährleistenWie in Abbildung 31 dargestellt, berücksichtigt diese Policy die im Sicherheitskonzept dergematik dargestellten Schutzbedarf der Datenklasse sowie die relevanten Risiken für diePINs/PUKs in den einzelnen Komponenten. Die verbleibenden Restrisiken sind von deneinzelnen Verantwortlichen im spezifischen Sicherheitskonzept zu identifizieren und zubewerten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 469 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDatenklassePIN, PUK1 1PolicyPIN, PUK1RekursionnInformationsobjektinn nKomponenten1direktVerantwortlichernVertragndelegiertVerantwortlicher11Asset11 11Assetverantwortung1nRekursionnnrelevanterSchutzbedarfrelevantesRisikondelegiertes Risikon1nSchutzzielndurch t/o Maßnahmengemindertes RisikonnMaßnahme in der Verantwortung desdirekt Verantwortlichennin Summe gleichndurch Beschränkunggemindertes RisikonnBeschränkungnRestrisikoAbbildung 31: Einordnung der Policy für PIN, PUK in das Sicherheitskonzept.Die Abbildung 31 zeigt im Überblick den Assetmanagement-Prozess (siehe auch Kap. 8)speziell für die Datenklasse PIN/PUK und hierbei die Delegation der Verantwortlichkeit fürdie einzelnen Komponenten in denen diese Datenklasse auftritt. In der nachfolgendenTabelle sind der Schutzbedarf dieser Datenklasse und die Verantwortlichen zusammenfassenddargestellt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 470 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 46: Schutzbedarf und Verantwortliche für PIN, PUKs 41Informationsobjekt PIN/PUK für Authentifikation ID: lo071Datenklasse PIN/PUK Dk11dSchutzbedarf(So076)VertraulichkeitIntegritätVerfügbarkeitAuthentizitätNichtabstreitbarkeitsehr hochsehrhochsehr hoch sehr hoch sehr hochKomponenteCMSVerantwortlicherKomponenteKartenherausgeberKarte - eGK, HBA/SMC/BAVerantwortlicherKartenherausgeber bis zur Entgegennahme durch KarteninhaberKarteninhaberKomponentePIN-Brief, PUK-Brief, PIN/PUKVerantwortlicherKartenherausgeber bis zur Entgegennahme durch KarteninhaberKarteninhaberKomponenteVerantwortlicherKartenterminal, PIN-PADBetreiber der Komponente, bzw. Spitzenorganisation des jeweiligenSektors…..Karteninhaber für die unbeobachtete Eingabe der PIN/PUKZum Schutz der PINs/PUKs werden in den verschiedenen Komponenten kryptographischeVerfahren genutzt. Die Sicherheit der PINs/PUKs hängt direkt von der Sicherheitdieser Schlüssel ab. Daher werden im Rahmen der vorliegenden Sicherheitsleitlinie auchfür diese Schlüsselklassen einzuhaltende Mindestsicherheitsanforderungen und entsprechendeMaßnahmen zu deren Erfüllung festgelegt.Tabelle 47: Schutzbedarf 42 und Verantwortliche der Schlüssel für die PIN, PUKsInformationsobjektSchlüssel für PIN-/PUK-VerfahrenDatenklasseSchlüssel für PIN/PUKSchutzbedarf(So076)VertraulichkeitIntegritätVerfügbarkeitAuthentizitätNichtabstreitbarkeitsehr hochsehrhochsehr hoch sehr hoch sehr hoch41 Diese Datenklasse enthält nur Daten, die in der Hoheit der gematik liegen. Insbesondere werdenhier z. B. keine besonderen Anforderungen an PINs für qualifizierte Signaturen gestellt.42 Bisher wurden diese Schlüssel im übergreifenden Sicherheitskonzept nicht betrachtet. Jedochergibt sich der Schutzbedarf direkt aus dem Schutzbedarf der PIN/PUK.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 471 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKomponenteVerantwortlicherKomponenteVerantwortlicherKomponenteVerantwortlicherKomponenteVerantwortlicherCMS – KartenproduktionKartenherausgeberCMS - KartenpersonalisierungKartenherausgeberPIP- Online Verfahren zum Aktivieren der PIN bzw. zum Rücksetzendes Fehlbedienungszählers incl. der dazu notwendigen kartenindividuellenSchlüsselKartenherausgeberKartenterminal, PIN-PAD – betrifft hier insbesondere Schlüssel,die bei remote PIN-Eingaben den Schutz der PIN gewährleisten.Betreiber der Komponente (bzw. Kartenherausgeber, Gerätepersonalisierer,bei der Verwendung von Karten- bzw. GeräteindividuellerSchlüssel)E2 - PIN- und PUK-VerfahrenEs ist vorgesehen, dass der Karteninhaber seinen persönlichen Willen durch Besitz (derKarte) und Wissen (der PIN) ausdrücken kann und damit seine Rechte wahrnimmt. DiePIN MUSS in der alleinigen Verfügung des Karteninhabers sein, damit neben dem Besitzder Karte eine eindeutige Authentifizierung und damit eine Zuweisung der Verantwortlichkeitenan den Karteninhaber stattfinden kann. Mit diesen PINs zur Authentifizierung werdenkryptographische Schlüssel zugänglich, die einen Zugriff auf personenbezogene undmedizinische Daten der Versicherten ermöglichen. Daraus resultieren u. A. die Anforderungen:• Es muss technisch kontrolliert und zugesichert werden, dass jede eGK mit derzugehörigen PIN/PUK nur einmal existiert (keine Kartendubletten) und auchnur einmal an den Karteninhaber sicher ausgegeben wird.• Es ist organisatorisch sicherzustellen, dass Karte und PIN-Brief bis zur Übergabean den Karteninhaber nie gemeinsam an einer Stelle beim Kartenherausgebervorhanden sind z. B. durch den getrennten Versand mit einem Mindestabstandvon drei Tagen mit unterschiedlichen Rücksendeadressen.Die relevanten Verfahren werden bezüglich der Mindestanforderungen beschrieben, damitunabhängig von der jeweils gewählten Verfahrensvariante ein einheitliches Sicherheitsniveaufür die Behandlung der PIN/PUK 43 in der Telematikinfrastruktur gewährleistet werdenkann.• PIN-Erzeugungsverfahren – es werden zwei Optionen überblicksartig dargestellt:oPIN-Erzeugung bei der Herstellung, PIN zufällig und nicht reproduzierbarBei der Produktion steht eine mindestens 6-stellige, maximal 8-stellige Zufallszahlzur Verfügung. Diese wird einerseits im entsprechenden File dereGK abgelegt und andererseits mit einem PIN-Brief an den Karteninhaber43 Die PUK-Verfahren sind analog zu den PIN-Verfahren, daher wurde auf die beschreibende Darstellungdieser Verfahren verzichtet.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 472 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturübergeben. In der Regel werden die PIN/PUK nach der Produktion der Karteund des PIN-Briefs sicher aus den Produktionseinrichtungen des Kartenherausgebersgelöscht.oPIN-Erzeugung bei der Karten-Herstellung, PIN abgeleitetFür die Produktion wird die mindestens 6-stellige, maximal 8-stellige PINZufallszahl nach einem definierten Verfahren aus Kartendaten abgeleitet.Zur Übermittlung der PIN an den Karteninhaber wird die PIN in einem gesondertenPIN-Brief an den Karteninhaber übergeben. Da in diesem Falldie PIN nach bekannten Regeln abgeleitet wird, kann eine Folgekarte desKarteninhabers dieselbe PIN enthalten.• Transport-PINUnter einer Transport-PIN versteht man eine PIN, die für den Transport derKarte vom Kartenhersteller zum Karteninhaber auf die Karte aufgebracht wird.Diese Transport-PIN ist einmal nutzbar; direkt nach ihrer Eingabe muss derKarteninhaber eine von ihm frei gewählte PIN vorgegebener Länge (wie spezifiziert:6 – 8-stellig) eingeben. Die PIN ist damit nur dem Karteninhaber bekanntund die Karte ist erst dann exklusiv vom Karteninhaber nutzbar, wennnach der Kartenübergabe sofort die Transport-PIN geändert wird.Es gibt verschiedene Varianten des Transport-PIN-VerfahrensooooTransport-PIN mit festem, bekanntem WertNULL-PIN-VerfahrenTransport-PIN zufällig und nicht reproduzierbarTransport-PIN mit abgeleitetem Wertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 473 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturE2.A - Zusammenfassung der SicherheitsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03033A_03034SSPIN_PUK_Policy_01: Es dürfenkeine Kartendubletten existieren.PIN_PUK_Policy_02: GetrennteAufbewahrung/Transport vonKarte und PIN-Brief.Es MUSS technisch kontrolliert und zugesichert werden, dass jedeeGK mit der zugehörigen PIN/PUK nur einmal existiert (keine Kartendubletten)und auch nur einmal an den Karteninhaber sicher ausgegebenwird.Es MUSS organisatorisch sichergestellt werden dass Karte und PIN-Brief bis zur Übergabe an den Karteninhaber nie gemeinsam an einerStelle beim Kartenherausgeber vorhanden sind z. B. durch den getrenntenVersand mit einem Mindestabstand von drei Tagen mit unterschiedlichenRücksendeadressen.AnhangE.2AnhangE.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 474 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur•E2.1 - Mindestanforderungen und Sicherheits-Policies für die BehandlungPIN/PUKZu den Sicherheitsbedingungen, die von den verschiedenen Verfahren zur Erzeugung,Speicherung, Verteilung und Verwendung der PINs, PUKs erfüllt werden müssen, gehörenallgemein:• Der Zugriff auf schützenswerte und PIN-geschützte personenbezogene undmedizinische Daten des Versicherten durch Unberechtigte MUSS verhindertwerden. Der Schutzbedarf dieser personenbezogenen Daten ist sehr hochund daher MÜSSEN die PINs, PUKs während des gesamten Lebenszyklus’mit einem entsprechenden Schutzbedarf (Erzeugung, Speicherung, Verteilung,Verwendung, Löschung) geschützt werden.• Es MUSS durch technische und organisatorische Maßnahmen sichergestelltwerden, dass die für den Zugriff auf schützenswerte und PIN-geschützte Datenverwendete PIN nur dem Karteninhaber bekannt ist. Die Maßnahmenstärkedieser technischen und organisatorischen Sicherheitsmaßnahmen istfür PINs und PUKs in der Regel „sehr hoch“.Erste Rahmenbedingungen für die relevanten Prozesse sind in [b4h_SiArch] (siehe nachfolgendeAbbildung) festgelegt worden. Die Prozesse zur Behandlung der Authentisierungsdatenbeziehen sich im Wesentlichen auf die Verteilung der Karte (kartenindividuelleSchlüssel) und der zugehörigen PIN/PUK zur Freischaltung dieser Schlüssel.Nachweis der Identität4Vertrauenswürdigkeit derRückführbarkeit3RegistrierungsinstanzProtokollierbarkeit210Übergabe AuthentifizierungsdatenAdressierbarkeit, Zustellung NachrichtAuthentifizierungsprinzipÜbertragung derAuthentifizierungsdatenKonformität zu StandardsSpeicherung derAuthentifizierungsdatenQualifizierte Signatur Fortgeschritte Signatur Unterere GrenzeAbbildung 32: Anforderungen an die Stärke der einzusetzenden Authentifizierungsverfahren(siehe Rahmenarchitektur)In Anbetracht der zwischenzeitlich durchgeführten Risikoanalyse der gematik kann das in[b4h_SiArch] empfohlene Mindestniveau nur für die Erstausgabe der eGK – ohne einengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 475 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturWeiternutzung (§291 Abs. 4 Sätze 5, 6, 7 SGB V) schon in der Telematikinfrastruktur vorhandenergeschützter Daten – empfohlen werden. Für die Ausgabe von Folgekarten, dieden Zugriff auf sensitive personenbezogene Daten erlauben, ist ein höheres Sicherheitsniveauerforderlich. Es MÜSSEN für Folgekarten mindestens Maßnahmen mit einer Stärke„hoch“ für die einzelnen Prozessschritte zur Aushändigung der PIN/PUK-Briefe und derGesundheitskarten von den Kartenherausgebern verwendet werden. Die Erreichung derSchutzziele und die Wirksamkeit und Konsistenz der gewählten Prozesse sowie der einzelnenProzessschritte ist vom Kartenherausgeber zu gewährleisten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 476 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNachweis der Identitätdes KarteninhabersVertrauenswürdigkeitder RegistrierungsinstanzAushändigung der Authentifizierungsinformationen(PIN-Brief, Karte)KonformitätAufbewahrung, SpeicherungÜbertragungAdressierbarkeit undZustellbarkeitProtokollierbarkeitErstausgabe der eGK 44Maßnahmenstärke: mittelBestätigung der Identitätdurch eine vom Benutzer unabhängigeInstanz notwendig,z. B. Vorlage eines persönlichenDokumentesMitarbeiter der Registrierungsinstanzsind nach der Schutzbedarfsklasse„mittel“ identifiziertworden und vertrauenswürdig.PostwegStandards oder Best Practices,HerstellererklärungAuthentifizierungsdaten unterliegenSW-KontrolleAuthentifizierungsdaten werdenin Software ver- bzw. umgeschlüsseltBestätigung der Adressedurch eine vom Benutzer unabhängigeInstanz ist notwendiginnerhalb existierender Vertragsbeziehungengegen Dritteals Beweis verwertbarFolgekarten eGKHBA/SMC-B/BAMaßnahmenstärke: hochBelastbare Bestätigung derIdentität durch eine vom Benutzerunabhängige Instanznotwendig, z. B. persönlich(sicher) bekannt (persönlichidentifiziert)Mitarbeiter der Registrierungsinstanzsind nach derSchutzbedarfsklasse „hoch“identifiziert worden, vertrauenswürdig,geschult und arbeitennach festgelegter Policy.Postweg + Rückmeldung(Postzustellungsurkunde)oder gleichwertige ErsatzverfahrenOffizielle Standards mit unabhängigerEvaluierung undZulassung für das GesundheitswesenAuthentifizierungsdaten unterliegenHW-KontrolleAuthentifizierungsdaten werdenvon der Eingabe bis zurPrüfung verschlüsselt übertragenund in physikalischgeschützter Hardware geprüftbelastbare Bestätigung derAdresse durch eine vom Benutzerunabhängige Instanzist notwendiggegen (beliebige) Dritte alsBeweis verwertbarRückführbarkeit auf genau ein Unternehmen/Partnerrückführbarauf genau eine Person rückführbar44 Dieser verringerte Schutzbedarf ist nur bei der Erstausgabe der eGK für die PIN.CH möglich, dadamit alleine noch kein Zugriff auf personenbezogene medizinische Daten möglich ist. Die auf dereGK ggf. vorhandenen geschützten Versichertendaten sind nur von berechtigten Leistungserbringernnach Eingabe der PIN.CH mit dem HBA/SMC/BA einsehbar. Es ist daher bei der Ausgabe derHBA/SMC/BA besonders auf die persönliche Übergabe der PIN.CH bzw. der zugehörigen Karte anden berechtigten Leistungserbringer zu achten. Daher sind die Mindestanforderungen an die Maßnahmenstärkebei der Erstausgabe der Heilberufsausweise und der entsprechenden PIN.CH als„hoch“ einzustufen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 477 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturIn den nachfolgenden Unterkapiteln werden die für HBA, SMC, BA und Folgekarten eGKmindest einzuhaltenden Sicherheitsanforderungen und –policies über den gesamten Lebenszyklusbeschrieben. Es werden dabei die folgenden Phasen unterschieden:• PIN/PUK-Erzeugung• PIN/PUK-Speicherung• PIN/PUK-Transport• PIN/PUK-Verwendung• PIN/PUK-Änderung• PIN/PUK-Löschung• PIN/PUK-Aktivierung• PIN/PUK-DeaktivierungE2.1.1 - PIN/PUK-ErzeugungDie Auswahl einer PIN kann entweder durch den Karteninhaber erfolgen oder durch denHerausgeber, der sie dem Karteninhaber zuweist. Falls der Kartenherausgeber die PINszuweist, so können die PINs, PUKs entweder (pseudo-)zufällig erzeugt oder aus Kartendatenabgeleitet werden. In den beiden Fällen müssen die erhaltenen PINs, PUKs möglichstgleich verteilt sein, um das Erraten und Ausprobieren einer PIN nicht zu vereinfachen.Nr.SP_PIN_CRE_1SP_PIN_CRE_2Anforderungen oder Maßnahme PIN/PUK ErzeugungPIN-LängeEine vom Kartenherausgeber zugewiesenePIN DARF NICHT weniger als 6 und NICHT mehr als 8 Ziffern langsein.Eine PUK MUSS 8 Ziffern lang sein.Eine durch den Kunden gewählte 45 PIN DARF NICHT weniger als 6und nicht mehr als 8 Ziffern lang seinDie PIN-Auswahl MUSS gemäß einer der folgenden Techniken erfolgen:zugewiesene echt zufällige oder pseudozufällige PIN, PUKzugewiesene abgeleitete PIN, PUKdurch Kunden gewählte PIN45 Hinweis: äquivalentes Sicherheitsniveau der Selbstwahl- und zugewiesener PINsDie Länge der PIN hat großen Einfluss auf die Sicherheit der Telematikinfrastruktur. Damit dasErraten und Ausprobieren einer PIN (auch bei Vorliegen gewisser Teilinformationen) möglichstschwierig ist, sollte die PIN möglichst viele Stellen haben. Damit sich die Versicherten die PIN jedochauswendig merken können, muss hier ein Kompromiss geschlossen werden. Falls der Kartenherausgeberdie PINs zuweist, sollte es möglich sein eine kleinere PIN-Länge zuzulassen, dainsbesondere bei 6-stelligen Selbstwahl-PINs die Gleichverteilung nicht mehr gewährleistet ist undeine geringere PIN-Länge einer zugewiesenen PIN das gleiche Sicherheitsniveau aufweist.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 478 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_PIN_CRE_3SP_PIN_CRE_4SP_PIN_CRE_5SP_PIN_CRE_6SP_PIN_CRE_7SP_PIN_CRE_8Anforderungen oder Maßnahme PIN/PUK ErzeugungFalls die PINs, PUKs zufällig oder pseudozufällig erzeugt werden,so MUSS der dabei verwendete Zufalls- oder Pseudozufallsgeneratordie vorgegebenen Mindestanforderungen der gematik (sieheAnhang F) erfüllen.Falls die PINs, PUKs aus Kartendaten abgeleitet werden, MUSS dieabgeleitete PIN, PUK ohne Kenntnis des benutzten Schlüssels nichteinfacher bestimmt werden können als eine zufällig erzeugte PIN,PUK. Insbesondere DARF der Ableitungsprozess NICHT spezielleWerte bevorzugt erzeugen. Zugewiesene PINs, PUKs MÜSSENgleich verteilt sein, um das Erraten einer PIN, PUK zu erschweren.Falls die PINs, PUKs aus Kartendaten abgeleitet werden, MÜSSENsie kryptographisch von vollständigen Kartenidentifikationsdaten,die eineindeutig dem Versicherten zugeordnet sind, abgeleitet werden.Falls die PINs, PUKs aus Kartendaten abgeleitet werden, MUSSsichergestellt werden, dass aus der Kenntnis der PIN, PUK und derInputdaten keine Informationen über den benutzten Schlüssel desKartenherausgebers abgeleitet werden können. Es MÜSSEN dieMindestanforderungen der gematik für die kryptographischen Algorithmenerfüllt werden.Falls die PINs durch die Karteninhaber gewählt werden, so MUSSder Herausgeber den Karteninhaber entsprechende Auswahlanweisungenund Warnungen geben und dem Karteninhaber bei der Kartenausgabezusenden.Die PINs bzw. PUKs MÜSSEN in einem Sicherheitsmodul mit geprüftenAlgorithmen gemäß der gematik Mindeststandards erzeugtoder abgeleitet werden, so dass sie nicht von Unbefugten ausgelesenoder manipuliert werden können.E2.1.2 - PIN/PUK-SpeicherungEine Speicherung von PINs/PUKs beim Herausgeber für die Nutzung im Produktionsprozesserfolgt in der Regel nur so lange, bis PIN und PUK auf die Karte/PIN-Brief übertragenwurden. Zusätzlich kann eine Speicherung auch über den Lebenszyklus einer Kartehinaus erfolgen – beispielsweise wenn der Herausgeber die PINs/PUKs für die Ausgabevon Folgekarten bzw. für zentrale Rücksetzung des Fehlbedienungszählers nach der Kartenausgabeverwenden will. Die gespeicherte PIN darf nicht abgehört oder unbemerktmanipuliert werden können. PINs dürfen nur innerhalb von Sicherheitsmodulen (Chip,HSM) und Sicherheitsobjekten (inkl. PIN-Briefe) im Klartext vorliegen. Die Stärke dertechnischen und organisatorischen Maßnahmen zum Schutz der PIN MUSS mindestenshoch sein.Nr.SP_PIN_STO_1SP_PIN_STO_2Anforderungen oder Maßnahme PIN/PUK SpeicherungEine Speicherung und damit eine Wiederverwendung vonPINs/PUKs in dezentralen Systemen (u. a. Konnektor, Kartenterminal,Primärsystemen) DARF NICHT erfolgen.Wenn eine PIN/PUK außerhalb eines Sicherheitsmoduls gespei-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 479 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_PIN_STO_3SP_PIN_STO_4SP_PIN_STO_5SP_PIN_STO_6SP_PIN_STO_7SP_PIN_STO_8Anforderungen oder Maßnahme PIN/PUK Speicherungchert wird, so MUSS sie verschlüsselt sein. Die dabei verwendetenkryptographischen Algorithmen MÜSSEN die jeweils aktuellen Mindestanforderungender gematik erfüllen.Wenn eine PIN/PUK außerhalb eines Sicherheitsmoduls gespeichertwird, so MUSS die Integrität der PIN/PUK geschützt sein. Diedabei verwendeten kryptographischen Algorithmen MÜSSEN diejeweils aktuellen Mindestanforderungen der gematik erfüllen.Für den Schutz der PIN.CH, der PIN.home und der PUK einer KarteMÜSSEN während der Speicherung verschiedene Verschlüsselungsschlüsselverwendet werden.Auch wenn zwei PINs zufällig den gleichen Wert aufweisen, DÜR-FEN sie bei der Verschlüsselung zur Speicherung beim HerausgeberNICHT auf den gleichen verschlüsselten Wert abgebildetwerden.Falls dieselbe PIN wiederholt verschlüsselt wird, so MÜSSEN dieentsprechenden verschlüsselten Werte unterschiedlich sein. Fürdas Verschlüsseln der PIN zur Speicherung MÜSSEN je Verwendungszweckbzw. Empfänger (u. a. PIN-Druck, Chip-Personalisierung,Speicherung) unterschiedliche Schlüssel verwendet werden.Die Schlüssel für die entsprechenden Verwendungszwecke bzw.Empfänger sind zu dokumentieren. Es MUSS durch geeignete organisatorischeund technische Maßnahmen (z. B. Schlüsseltrennung,getrennte HSMs) sichergestellt werden, dass nur innerhalbder Sicherheitsmodule berechtigter Empfänger und Komponentendie PIN entschlüsselt und im Klartext vorliegen kann.Das Schlüsselmanagement für die Schlüssel der PIN-SpeicherungMUSS die Mindestanforderungen für das Schlüsselmanagementmindestens der 2. Stufe in einer Schlüsselhierarchie (u. a. Key EncryptionKeys für kartenindividuelle Schlüssel, SUB-CA für Kartenschlüssel,Zertifikate) erfüllen (siehe Anhang F).Nach Ablauf der Speicherungsdauer für die PIN/PUK sind diese imDatenspeicher sicher zu löschen.E2.1.3 - PIN/PUK-TransportEin Transport der PIN/PUK innerhalb des Systems ist zu verschiedenen Zwecken notwendig.Dazu gehört z. B. die Mitteilung der PIN durch den Herausgeber an den Karteninhaber46 oder die Verteilung der PIN/PUK vom Kartenherausgeber an die Dienstleisterfür die Kartenpersonalisierung oder den Druck des PIN-Briefes. Zusätzlich kann bei derPIN-Eingabe am Kartenterminal bzw. bei der Rücksetzung des Fehlbedienungszählerseine Übertragung von PIN/PUK in der Telematikinfrastruktur erfolgen. Die nachfolgendenMindestanforderungen für den PIN/PUK Transport MÜSSEN für jeden Transport eingehaltenwerden.Während des PIN-Transports darf die PIN nicht abgehört oder unbemerkt manipuliertwerden können. Außerdem muss verhindert werden, dass die PIN von Unbefugten dem46 Dieses Unterkapitel betrifft nicht die Verteilung öffentlicher Transport-PINs bzw. Einmal-PINs, dienach der Eingabe durch den Karteninhaber zu ändern sind.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 480 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturzugehörigen Versicherten zugeordnet werden kann. Eine unberechtigte Zwischenspeicherungund unberechtigte nachträgliche Verwendung auch der verschlüsselten PIN (u. a.Ausdruck eines zweiten PIN-Briefs für andere Adressaten) ist zu verhindern.Nr.SP_PIN_TRA_1SP_PIN_TRA_2SP_PIN_TRA_3SP_PIN_TRA_4SP_PIN_TRA_5Anforderungen oder Maßnahme PIN/PUK TransportDie PIN MUSS nur dem Karteninhaber bekannt sein. Daher ist dieVertraulichkeit der PIN in Transport, Speicherung und Gebrauch vornicht autorisierter Aufdeckung und Weitergabe der PIN, PUK zuschützen, dies betrifft:PINs, PUKs DÜRFEN außerhalb geschützter Hardware NICHT unverschlüsseltauftreten. Ausnahme ist der einmalige Ausdruck desPIN-Briefes, der durch gesonderte organisatorische Maßnahmengesichert ist.Die Verteilung der PINs, PUKs MUSS auf das absolut notwendigeMaß eingeschränkt werden, um die Möglichkeiten zur Kompromittierungder PIN zu minimieren und potentielle Schäden zu beschränken.Eine PIN DARF NICHT mehr als einmal erstellt werdenund MUSS dem Karteninhaber übermittelt werden.Während des elektronischen PIN/PUK-Transports außerhalb einersicheren Umgebung oder eines Sicherheitsmoduls MUSS die PINverschlüsselt sein. Die dabei verwendeten kryptographischen AlgorithmenMÜSSEN die jeweils aktuellen Mindestanforderungen dergematik erfüllen.Die PIN/PUK DARF NICHT außerhalb einer sicheren Umgebungoder eines Sicherheitsmoduls im Klartext erscheinen.Während der elektronischen PIN-Verteilung außerhalb einer sicherenUmgebung oder eines Sicherheitsmoduls MUSS die Integritätder PIN/PUK geschützt sein. Die dabei verwendeten kryptographischenAlgorithmen MÜSSEN die jeweils aktuellen Mindestanforderungender gematik erfüllen.Auch wenn zwei PINs einer Karte zufällig den gleichen Wert aufweisen,DÜRFEN sie bei der Verschlüsselung zum Transport NICHTauf den gleichen verschlüsselten Wert abgebildet werden. Für denSchutz der PIN.CH, der PIN.home und der PUK einer Karte MÜS-SEN für den verschlüsselten Transport z. B. verschiedene Schlüsseloder unterschiedliche Initiale Vektoren verwendet werden.Falls dieselbe PIN wiederholt verschlüsselt wird, so MÜSSEN dieentsprechenden verschlüsselten Werte unterschiedlich sein. Für dasVerschlüsseln der PIN bei Transport MÜSSEN je Verwendungszweckbzw. Empfänger (u. a. PIN-Druck, Chip-Personalisierung,Speicherung, PIN-Prüfung im Chip) unterschiedliche Schlüsselverwendet werden.Die Behandlung der Schlüssel für die entsprechenden Verwendungszweckebzw. Empfänger sind zu dokumentieren. Es MÜSSENdurch geeignete organisatorische und technische Maßnahmen (z. B.Schlüsseltrennung, getrennte HSMs) gewährleistet werden, dass nurinnerhalb der Sicherheitsmodule berechtigter Empfänger und Komponentendie PIN entschlüsselt und im Klartext vorliegen kann. DieMöglichkeit zur Umschlüsselung und der Export der umgeschlüssel-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 481 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_PIN_TRA_6SP_PIN_TRA_7SP_PIN_TRA_8SP_PIN_TRA_9Anforderungen oder Maßnahme PIN/PUK Transportten PIN/PUK in diesen Komponenten MUSS auf den jeweiligen Verwendungszweckeingeschränkt werden. Es SOLL nur eineUmschlüsselung auf kartenindividuelle Schlüssel der zugehörigenKarte erfolgen.Auch wenn zwei PINs unterschiedlicher Karten zufällig den gleichenWert aufweisen, DÜRFEN sie bei der Verschlüsselung zum TransportNICHT auf den gleichen verschlüsselten Wert abgebildet werden.Die Verschlüsselung von PINs/PUKs während der Verteilung mussso erfolgen, dass jede PIN z. B. mit einem anderen Schlüssel bzw.Initiale Vektoren verschlüsselt wird. Die Wahl dieser Schlüssel mussso erfolgen, dass es nicht möglich ist, bei Kenntnis aller ab einemZeitpunkt benutzten Schlüssel die vorher benutzten Schlüssel abzuleiten.Das Schlüsselmanagement für die Schlüssel des PIN-TransportsMUSS die Mindestanforderungen für das Schlüsselmanagementmindestens der 3. Stufe in einer Schlüsselhierarchie (u. a. Key EncryptionKeys für kartenindividuelle Schlüssel, SUB-CA für Kartenschlüssel,Zertifikate) erfüllen.Nach der Übertragung der PIN/PUK MÜSSEN diese in allen beteiligtenKomponenten sicher gelöscht werden.Alle Aktivitäten und die unterstützenden Systemfunktionen der PIN-Herausgabe, die die Zuordnung einer PIN zu einer Karte oder zueinem Karteninhaber betreffen und die Personal des Herausgebersbzw. Personal des vom Kartenherausgeber beauftragtenDienstleisters benötigen, MÜSSEN dem Vieraugenprinzip gehorchen.SP_PIN_TRA_10 Alle Funktionen, die das Rücksetzen des Fehlbedienungszählersbzw. der (De)Aktivierung einer Karte oder Kartenanwendung betreffenund die Personal des Herausgebers benötigen, MÜSSEN demVieraugenprinzip gehorchen.E2.1.4 - PIN/PUK-VerwendungDie Verwendung der PIN/PUK erfolgt an von der gematik zugelassenen Terminals derLeistungserbringer, bzw. an den Terminals der empfohlenen Heimumgebung in der Verantwortungdes Versicherten.Nr.SP_PIN_USE_1SP_PIN_USE_2Anforderungen oder Maßnahme PIN/PUK VerwendungDie Ausgestaltung der Kartenterminals bzw. der Umgebung MUSS sogestaltet sein, dass die PIN/PUK vom Karteninhaber unbeobachtetvon anderen eingegeben werden kann.Die Ausgestaltung der Kartenterminals bzw. der Umgebung MUSS sogestaltet sein, dass von der gematik nicht zugelassene oder möglicherweisekompromittierte Komponenten vom Karteninhaber erkanntwerden können. Es DARF NICHT möglich sein,die geheimen Daten, die im sicheren PIN-Eingabegerät gespeichertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 482 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_PIN_USE_3SP_PIN_USE_4Anforderungen oder Maßnahme PIN/PUK Verwendungsind (Schlüssel und PINs), in Erfahrung zu bringen oder zu verändernodereine Abhörvorrichtung innerhalb des Gerätes einzurichten oderdie Hard- oder Software des sicheren PIN-Eingabegerätes zu verändern.Solche Angriffe MÜSSEN am Gerät physischen Schaden in der Artanrichten, dass er vor der Wiederinbetriebnahme des Gerätes mithoher Wahrscheinlichkeit entdeckt wird.Für den Karteninhaber MUSS deutlich erkennbar sein, welche Anwendungenbzw. Daten und Schlüssel er mit seiner PIN freigibt. Insbesondereist dem Versicherten anzuzeigen, auf welche Anwendungzugegriffen wird und welche zugehörige PIN (PIN.CH, PIN.home)eingegeben werden soll.Die maximale Anzahl aufeinander folgender Fehlversuche bei derEingabe der PIN MUSS begrenzt sein (max. drei), um die Möglichkeitsystematischer Versuche zum Erraten der PIN einer Karte zu begrenzen.Nach zehnmaliger Nutzung (unabhängig von der richtigen oder falschenEingabe) der PUK, MUSS die Karte gesperrt bleiben, d.h. esMUSS eine neue Karte beantragt werdenE2.1.5 - PIN/PUK-ÄnderungEine Änderung einer PIN kann aus mehreren Gründen notwendig sein:• der Karteninhaber möchte die PIN wechseln,• der Karteninhaber hat die PIN vergessen,• die PIN ist (tatsächlich oder mutmaßlich) kompromittiert.Die Änderung einer PIN durch den Karteninhaber kann an einem Terminal z. B. bei einemLeistungserbringer oder einem eigenständigen Selbstbedienungsterminal erfolgen. Generellgilt, dass dabei die Verfahren zur Änderung einer PIN analog zu den Verfahren derPIN-Auswahl sein sollten. Die Änderung der PIN/PUK erfolgt an von der gematik zugelassenenTerminals.Nr.SP_PIN_MOD_1SP_PIN_MOD_2SP_PIN_MOD_3Anforderungen oder Maßnahme PIN ÄnderungJeder Karteninhaber MUSS die Möglichkeit zur Wahl der PIN seinerKarte haben.Wenn ein Karteninhaber eine PIN an einem unbedienten Terminal inder Telematikinfrastruktur ändert, so MUSS die aktuelle PIN eingegebenund verifiziert werden, bevor die vom Karteninhaber gewählteneue PIN ausgewählt und aktiviert wird. Die neue PIN MUSSvom Karteninhaber zweimal identisch eingegeben werden.Wenn ein Karteninhaber eine PIN an einem bedienten Terminal ändert,so MUSS dies auf die gleiche Art erfolgen, wie die Auswahleiner PIN beim Herausgeber. Insbesondere beim Ersatz einer ver-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 483 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_PIN_MOD_4SP_PIN_MOD_5Anforderungen oder Maßnahme PIN Änderunggessenen PIN MÜSSEN die Kriterien für die PIN-Auswahl erfülltwerden.Alle Funktionen während der PIN-Änderung, die Personal des Herausgebersbzw. eines Leistungserbringers benötigen, MÜSSEN demVieraugenprinzip gehorchen.Wenn von einer PIN/PUK angenommen wird, dass sie kompromittiertist, MUSS sie so schnell wie möglich deaktiviert bzw. gesperrt werden.Es MUSS einen praktikablen Prozess geben, um kompromittiertePINs zu sperren. Die Nutzer sind darüber ausreichend zu informieren.Der Karteninhaber MUSS über einen Ersatz informiert werden oderdie Möglichkeit erhalten, einen zu wählen.E2.1.6 - PIN/PUK-LöschungDie PIN/PUK darf nur für den vom Karteninhaber vorgesehenen Zweck verwendet werden.Um missbräuchliche Verwendung und Kompromittierungsmöglichkeiten zu verringern,MUSS eine nicht mehr benötigte PIN/PUK daher in allen Komponenten unverzüglichsicher gelöscht werden. In der Regel sind die PINs/PUKs nach dem einmaligen Gebrauchunverzüglich zu löschen. Für die ggf. notwendige Speicherung in zentralen Systemen inder Verantwortung des Kartenherausgebers sind die Anforderungen von 3.1.2 mindestenseinzuhalten.Nr.SP_PIN_DEL_1SP_PIN_DEL_2SP_PIN_DEL_3Anforderungen oder Maßnahme PIN/PUK LöschungNicht mehr benötigte elektronische PINs/PUKs bzw. zugeordneteSchlüssel MÜSSEN unverzüglich sicher gelöscht werden.Die unverzügliche sichere Löschung MUSS im Sicherheitskonzeptder jeweiligen Komponente und Dienste nachgewiesen werden.Insbesondere in den dezentralen Komponenten der TI, in denen diePIN nur einmal für die Prüfung im Chip zum Zugriff auf die freigegebenenAnwendungen, Daten und Schlüssel verwendet werden darf,MUSS die PIN nach der Weitergabe zur PIN-Prüfung an den Chipimmer sofort gelöscht werden. Eine unberechtigte Wiederverwendungbzw. Replay der PIN MÜSSEN ausgeschlossen werden.Es MÜSSEN Vorkehrungen getroffen werden, um die nicht mehr benötigtenKlartext-PINs so zerstören zu können, dass es nicht mehrmöglich ist, die PINs ganz oder teilweise zu rekonstruieren. InsbesondereMÜSSEN die Kartenherausgeber geeignete Sicherheitsmaßnahmentreffen in Bezug auf die interne Handhabung und Beseitigungvon zurückgesendeten PIN-Briefen und Material, das mitdem ursprünglichen Druck der PIN-Briefe verbunden ist. Dabei istdarauf zu achten, dass die Behandlung zurückgesandter PIN-Briefevon der Behandlung der zurückgesandten Karten organisatorischgetrennt sein MUSS.Karteneinzug:Die sichere Außerbetriebnahme der PIN und der damit verbundenengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 484 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.Anforderungen oder Maßnahme PIN/PUK LöschungKarten ist vom Kartenherausgeber zu regeln. Es MÜSSEN entsprechendepraxistaugliche Verfahren angeboten werden.Hinweis: Auch abgelaufene Karten bergen Risiken z. B. auf der eGKvorhandene medizinische Daten wie etwa Notfalldaten sowie imHBA noch verwendbare C2C-Authentisierungsschlüssel, die einenOffline-Zugriff auf geschützte medizinische Daten ermöglichen.E2.1.7 - PIN/PUK-AktivierungEin entsprechendes Kapitel ist aufzunehmen, falls Karten mit deaktivierten PINs ausgegebenwerden, die zunächst einen Aktivierungsprozess durchlaufen müssen, z. B. an einembedienten Terminal oder durch andere Verfahren.E2.1.8 - PIN/PUK-DeaktivierungEin entsprechendes Kapitel ist aufzunehmen, falls z. B. für Ersatz- und Notfallverfahrender Schaden durch eine PIN/PUK-Deaktivierung von online-erreichbaren Karten begrenztwird.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 485 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturE2.1.8 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03035A_03036A_03037A_03038A_03039SSP_PIN S_CRE_1SP_PIN S_CRE_2SP_PIN S_CRE_3SP_PIN S_CRE_4PIN_PUK_Policy_03: Prozessanforderungenfür Folgekarten.PIN_PUK_Erzeugung_01:Länder von PIN und PUK.PIN_PUK_Erzeugung_02:Mögliche Arten vonPINs/PUKs.PIN_PUK_Erzeugung_03:Anforderungen an den Zufalls- oderPseudozufallsgenerator.PIN_PUK_Erzeugung_04:Qualität der abgeleiteten PINs/PUKsEs MÜSSEN für Folgekarten mindestens Maßnahmen mit einerStärke „hoch“ für die einzelnen Prozessschritte zur Aushändigungder PIN/PUK-Briefe und der Gesundheitskarten von den Kartenherausgebernverwendet werden. Die Erreichung der Schutzziele unddie Wirksamkeit und Konsistenz der gewählten Prozesse sowie dereinzelnen Prozessschritte ist vom Kartenherausgeber zu gewährleistenPIN-LängeEine vom Kartenherausgeber zugewieseneo PIN DARF NICHT weniger als 6 und NICHT mehr als 8 Ziffernlang sein.o Eine PUK MUSS 8 Ziffern lang seinEine durch den Kunden gewählte PIN DARF NICHT weniger als 6und nicht mehr als 8 Ziffern lang sei4Die PIN-Auswahl MUSS gemäß einer der folgenden Techniken erfolgen:o zugewiesene echt zufällige oder pseudozufällige PIN, PUKo zugewiesene abgeleitete PIN, PUKo durch Kunden gewählte PINFalls die PINs, PUKs zufällig oder pseudozufällig erzeugt werden,so MUSS der dabei verwendete Zufalls- oder Pseudozufallsgeneratordie vorgegebenen Mindestanforderungen der gematik (sieheAnhang F) erfüllen.Falls die PINs, PUKs aus Kartendaten abgeleitet werden, MUSS dieabgeleitete PIN, PUK ohne Kenntnis des benutzten Schlüssels nichteinfacher bestimmt werden können als eine zufällig erzeugte PIN,PUK. Insbesondere DARF der Ableitungsprozess NICHT spezielleWerte bevorzugt erzeugen. Zugewiesene PINs, PUKs MÜSSENgleich verteilt sein, um das Erraten einer PIN, PUK zu erschweren.AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 486 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03040A_03041A_03042A_03043A_03044A_03045A_03046SP_PIN S PIN_PUK_Erzeugung_05: Ableitungvon PINs und PUKs /_CRE_5Ableitungsdaten.SP_PIN S_CRE_6SP_PIN S_CRE_7SP_PIN S_CRE_8SP_PIN_STO_1SP_PIN_STO_2SP_PIN_STO_3PIN_PUK_Erzeugung_06: Ableitungvon PINs und PUKs/Mindestanforderungen fürkryptographische AlgorithmenPIN_PUK_Erzeugung_07: BenutzeranweisungenPIN_PUK_Erzeugung_08: ErzeugungimSicherheitsmodulmit geprüften Algorithmen.S PIN_PUK_Storage_1:KeineSpeicherung/Wiederverwendungindezentralen Systemen.S PIN_PUK_Storage_2: VerschlüsselteSpeicherung außerhalbvon Sicherheitsmodulen.S PIN_PUK_Storage_3: Integritätsschutzbei Speicherungaußerhalb eines Sicherheitsmoduls.Falls die PINs, PUKs aus Kartendaten abgeleitet werden, MÜSSENsie kryptographisch von vollständigen Kartenidentifikationsdaten, dieeineindeutig dem Versicherten zugeordnet sind, abgeleitet werden.Falls die PINs, PUKs aus Kartendaten abgeleitet werden, MUSSsichergestellt werden, dass aus der Kenntnis der PIN, PUK und derInputdaten keine Informationen über den benutzten Schlüssel desKartenherausgebers abgeleitet werden können. Es MÜSSEN dieMindestanforderungen der gematik für die kryptographischen Algorithmenerfüllt werdenFalls die PINs durch die Karteninhaber gewählt werden, so MUSSder Herausgeber den Karteninhaber entsprechende Auswahlanweisungenund Warnungen geben und dem Karteninhaber bei der Kartenausgabezusenden.Die PINs bzw. PUKs MÜSSEN in einem Sicherheitsmodul mit geprüftenAlgorithmen gemäß der gematik Mindeststandards erzeugtoder abgeleitet werden, so dass sie nicht von Unbefugten ausgelesenoder manipuliert werden können.Eine Speicherung und damit eine Wiederverwendung vonPINs/PUKs in dezentralen Systemen (u. a. Konnektor, Kartenterminal,Primärsystemen) DARF NICHT erfolgen.Wenn eine PIN/PUK außerhalb eines Sicherheitsmoduls gespeichertwird, so MUSS sie verschlüsselt sein. Die dabei verwendetenkryptographischen Algorithmen MÜSSEN die jeweils aktuellen Mindestanforderungender gematik erfüllen.Wenn eine PIN/PUK außerhalb eines Sicherheitsmoduls gespeichertwird, so MUSS die Integrität der PIN/PUK geschützt sein. Diedabei verwendeten kryptographischen Algorithmen MÜSSEN diejeweils aktuellen Mindestanforderungen der gematik erfüllen.AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 487 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03047A_03048A_03049A_03050A_03051SP_PIN S PIN_PUK_Storage_4: Verwendungunterschiedlicher Ver-_STO_4schlüsselungsschlüssel fürPIN.CH, der PIN.home undPUK.SP_PIN S_STO_5SP_PIN S_STO_6SP_PIN S_STO_7SP_PIN S_STO_8PIN_PUK_Storage_5: VerschlüsselteSpeicherung identischerPINs.PIN_PUK_Storage_6: Wiederholteerschlüsselte Speicherungvon PINS.PIN_PUK_Storage_7: Schlüsselmanagement.PIN_PUK_Storage_8: Löschenvon PINs/PUKs.Für den Schutz der PIN.CH, der PIN.home und der PUK einer KarteMÜSSEN während der Speicherung verschiedene Verschlüsselungsschlüsselverwendet werden.Auch wenn zwei PINs zufällig den gleichen Wert aufweisen, DÜR-FEN sie bei der Verschlüsselung zur Speicherung beim HerausgeberNICHT auf den gleichen verschlüsselten Wert abgebildet werden.Falls dieselbe PIN wiederholt verschlüsselt wird, so MÜSSEN dieentsprechenden verschlüsselten Werte unterschiedlich sein. Für dasVerschlüsseln der PIN zur Speicherung MÜSSEN je Verwendungszweckbzw. Empfänger (u. a. PIN-Druck, Chip-Personalisierung,Speicherung) unterschiedliche Schlüssel verwendet werden.Die Schlüssel für die entsprechenden Verwendungszwecke bzw.Empfänger sind zu dokumentieren. Es MUSS durch geeignete organisatorischeund technische Maßnahmen (z. B. Schlüsseltrennung,getrennte HSMs) sichergestellt werden,PIN_PUK_Storage_1dass nur innerhalb der Sicherheitsmodule berechtigterEmpfänger und Komponenten die PIN entschlüsselt undim Klartext vorliegen kann.Das Schlüsselmanagement für die Schlüssel der PIN-SpeicherungMUSS die Mindestanforderungen für das Schlüsselmanagementmindestens der 2. Stufe in einer Schlüsselhierarchie (u. a. Key EncryptionKeys für kartenindividuelle Schlüssel, SUB-CA für Kartenschlüssel,Zertifikate) erfüllen (siehe Anhang F).Nach Ablauf der Speicherungsdauer für die PIN/PUK sind diese imDatenspeicher sicher zu löschen.AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 488 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03052A_03053A_03054A_03055SP_PIN_TRA_1SP_PIN_TRA_2SP_PIN_TRA_3SP_PIN_TRA_4SSPIN_PUK_Transport_1:Vetraulichkeit bei Transport /Verteilung.PIN_PUK_Transport_2:PIN/PUK muß verschlüsseltsein, wenn sie elektronischaußerhalb eines Sicherheitsmodulsvorliegt.S PIN_PUK_Transport_3: Integritätvon PIN/PUK muß gesichertsein, wenn sie elektronischaußerhalb eines Sicherheitsmodulsvorliegt.SPIN_PUK_Transport_4:Verschlüsselte Übertragung identischerPINs einer Karte.Die PIN MUSS nur dem Karteninhaber bekannt sein. Daher ist dieVertraulichkeit der PIN in Transport, Speicherung und Gebrauch vornicht autorisierter Aufdeckung und Weitergabe der PIN, PUK zuschützen, dies betrifft:PINs, PUKs DÜRFEN außerhalb geschützter Hardware NICHT unverschlüsseltauftreten. Ausnahme ist der einmalige Ausdruck desPIN-Briefes, der durch gesonderte organisatorische Maßnahmengesichert ist.Die Verteilung der PINs, PUKs MUSS auf das absolut notwendigeMaß eingeschränkt werden, um die Möglichkeiten zur Kompromittierungder PIN zu minimieren und potentielle Schäden zu beschränken.Eine PIN DARF NICHT mehr als einmal erstellt werden undMUSS dem Karteninhaber übermittelt werden.Während des elektronischen PIN/PUK-Transports außerhalb einersicheren Umgebung oder eines Sicherheitsmoduls MUSS die PINverschlüsselt sein. Die dabei verwendeten kryptographischen AlgorithmenMÜSSEN die jeweils aktuellen Mindestanforderungen dergematik erfüllen.Die PIN/PUK DARF NICHT außerhalb einer sicheren Umgebungoder eines Sicherheitsmoduls im Klartext erscheinen.Während der elektronischen PIN-Verteilung außerhalb einer sicherenUmgebung oder eines Sicherheitsmoduls MUSS die Integritätder PIN/PUK geschützt sein. Die dabei verwendeten kryptographischenAlgorithmen MÜSSEN die jeweils aktuellen Mindestanforderungender gematik erfüllen.Auch wenn zwei PINs einer Karte zufällig den gleichen Wert aufweisen,DÜRFEN sie bei der Verschlüsselung zum Transport NICHTauf den gleichen verschlüsselten Wert abgebildet werden. Für denSchutz der PIN.CH, der PIN.home und der PUK einer Karte MÜS-SEN für den verschlüsselten Transport z. B. verschiedene Schlüsseloder unterschiedliche Initiale Vektoren verwendet werden.AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 489 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03056A_03057A_03058A_03059A_03060SP_PIN_TRA_5SP_PIN_TRA_6SP_PIN_TRA_7SP_PIN_TRA_8SP_PIN_TRA_9S PIN_PUK_Transport_5: Einsatzunterschiedlicher Verschlüsselungsschlüssel/InitialisierungsvektorenfürPIN.CH, der PIN.home undPUK einer Karte.SSPIN_PUK_Transport_6: VerschlüsselteÜbertragung identischerPINs mehrerer Karten.PIN_PUK_Transport_7:Schlüsselmanagement.S PIN_PUK_Transport_8: Löschenvon PINs/PUKs nachder Übertragung.SPIN_PUK_Transport_9: Beachtungdes Vieraugenprinzipbeim PIN-Transport.Für den Schutz der PIN.CH, der PIN.home und der PUK einer KarteMÜSSEN für den verschlüsselten Transport z. B. verschiedeneSchlüssel oder unterschiedliche Initiale Vektoren verwendet werden.Auch wenn zwei PINs unterschiedlicher Karten zufällig den gleichenWert aufweisen, DÜRFEN sie bei der Verschlüsselung zum TransportNICHT auf den gleichen verschlüsselten Wert abgebildet werden.Die Verschlüsselung von PINs/PUKs während der Verteilung mussso erfolgen, dass jede PIN z. B. mit einem anderen Schlüssel bzw.Initiale Vektoren verschlüsselt wird. Die Wahl dieser SchlüsselMUSS so erfolgen, dass es nicht möglich ist, bei Kenntnis aller abeinem Zeitpunkt benutzten Schlüssel die vorher benutzten Schlüsselabzuleiten.Das Schlüsselmanagement für die Schlüssel des PIN-TransportsMUSS die Mindestanforderungen für das Schlüsselmanagementmindestens der 3. Stufe in einer Schlüsselhierarchie (u. a. Key EncryptionKeys für kartenindividuelle Schlüssel, SUB-CA für Kartenschlüssel,Zertifikate) erfüllen.Nach der Übertragung der PIN/PUK MÜSSEN diese in allen beteiligtenKomponenten sicher gelöscht werden.Alle Aktivitäten und die unterstützenden Systemfunktionen der PIN-Herausgabe, die die Zuordnung einer PIN zu einer Karte oder zueinem Karteninhaber betreffen und die Personal des Herausgebersbzw. Personal des vom Kartenherausgeber beauftragtenDienstleisters benötigen, MÜSSEN dem Vieraugenprinzip gehorchen.AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 490 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03061A_03062A_03063A_03064A_03065SP_PIN_TRA_10SP_PIN_USE_1SP_PIN S_USE_2SP_PIN S_USE_3SP_PIN S_USE_4S PIN_PUK_Transport_10: Beachtungdes Vieraugenprinzipsbei Rücksetzen des Fehlbedienungszählersbzw. der(De)Aktivierung einer Karte.S PIN_PUK_Verwendung_1:Unbeobachtete PIN/PUK Eingabe.PIN_PUK_Verwendung_2:Erkennbarkeit von Manipulationen.PIN_PUK_Verwendung_3:Erkennbarkeit der ZuordnungAnwendung zu PIN.PIN_PUK_Verwendung_4:Fehleingabezähler PIN/PUK.Alle Funktionen, die das Rücksetzen des Fehlbedienungszählersbzw. der (De)Aktivierung einer Karte oder Kartenanwendung betreffenund die Personal des Herausgebers benötigen, MÜSSEN demVieraugenprinzip gehorchen.Die Ausgestaltung der Kartenterminals bzw. der Umgebung MUSSso gestaltet sein, dass die PIN/PUK vom Karteninhaber unbeobachtetvon anderen eingegeben werden kann.Die Ausgestaltung der Kartenterminals bzw. der Umgebung MUSSso gestaltet sein, dass von der gematik nicht zugelassene odermöglicherweise kompromittierte Komponenten vom Karteninhabererkannt werden können. Es DARF NICHT möglich sein,o die geheimen Daten, die im sicheren PIN-Eingabegerät gespeichertsind (Schlüssel und PINs), in Erfahrung zu bringen oder zuverändern odero eine Abhörvorrichtung innerhalb des Gerätes einzurichten odero die Hard- oder Software des sicheren PIN-Eingabegerätes zu verändern.Solche Angriffe MÜSSEN am Gerät physischen Schaden in der Artanrichten, dass er vor der Wiederinbetriebnahme des Gerätes mithoher Wahrscheinlichkeit entdeckt wird.Für den Karteninhaber MUSS deutlich erkennbar sein, welche Anwendungenbzw. Daten und Schlüssel er mit seiner PIN freigibt.Insbesondere ist dem Versicherten anzuzeigen, auf welche Anwendungzugegriffen wird und welche zugehörige PIN (PIN.CH,PIN.home) eingegeben werden sollDie maximale Anzahl aufeinander folgender Fehlversuche bei derEingabe der PIN MUSS begrenzt sein (max. drei), um die Möglichkeitsystematischer Versuche zum Erraten der PIN einer Karte zubegrenzen.Nach zehnmaliger Nutzung (unabhängig von der richtigen oder fal-AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 491 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleschen Eingabe) der PUK, MUSS die Karte gesperrt bleiben, d.h. esMUSS eine neue Karte beantragt werdenA_03066A_03067A_03068A_03069A_03070A_03071SP_PIN_MOD_1SP_PIN_MOD_2SP_PIN_MOD_3SP_PIN_MOD_4SP_PIN_MOD_5SP_PIN_DEL_1SPIN_PUK_Änderung_1: Anderbarkeitder PIN.Karte haben.Jeder Karteninhaber MUSS die Möglichkeit zur Wahl der PIN seinerSWenn ein Karteninhaber eine PIN an einem unbedienten Terminal inder Telematikinfrastruktur ändert, so MUSS die aktuelle PIN eingegebenund verifiziert werden, bevor die vom Karteninhaber gewähltePIN_PUK_Änderung_2: Authentisierungvor PIN- neue PIN ausgewählt und aktiviert wird. Die neue PIN MUSS vomÄnderung.Karteninhaber zweimal identisch eingegeben werden.SWenn ein Karteninhaber eine PIN an einem bedienten Terminaländert, so MUSS dies auf die gleiche Art erfolgen, wie die Auswahleiner PIN beim Herausgeber. Insbesondere beim Ersatz einer vergessenenPIN MÜSSEN die Kriterien für die PIN-Auswahl erfülltPIN_PUK_Änderung_3: Identifizierungvor PIN-Änderung. werden.S PIN_PUK_Änderung_4: Beachtungdes 4-Augenprinzipss Alle Funktionen während der PIN-Änderung, die Personal des Herausgebersbzw. eines Leistungserbringers benötigen, MÜSSENseitens Hrsg. bei PIN-Änderung.dem Vieraugenprinzip gehorchen.SPIN_PUK_Änderung_5: SperrungkompromittierterPINs/PUKs.S PIN_PUK_Löschung_1: SichereLöschung nicht mehr benötigterPINs/PUKs.Wenn von einer PIN/PUK angenommen wird, dass sie kompromittiertist, MUSS sie so schnell wie möglich deaktiviert bzw. gesperrtwerden.Es MUSS einen praktikablen Prozess geben, um kompromittiertePINs zu sperren. Die Nutzer sind darüber ausreichend zu informieren.Der Karteninhaber MUSS über einen Ersatz informiert werden oderdie Möglichkeit erhalten, einen zu wählenNicht mehr benötigte elektronische PINs/PUKs bzw. zugeordneteSchlüssel MÜSSEN unverzüglich sicher gelöscht werden.Die unverzügliche sichere Löschung MUSS im SicherheitskonzeptAnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 492 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03072A_03073SP_PIN_DEL_2SPIN_PUK_Löschung_2: Zerstörungnicht mehr benötigterKlartext-PINs/Trägermedien.SP_PIN_DEL_3 S PIN_PUK_Löschung_3: Außerbetriebnahmevon PIN undKarte.der jeweiligen Komponente und Dienste nachgewiesen werden.Insbesondere in den dezentralen Komponenten der TI, in denen diePIN nur einmal für die Prüfung im Chip zum Zugriff auf die freigegebenenAnwendungen, Daten und Schlüssel verwendet werden darf,MUSS die PIN nach der Weitergabe zur PIN-Prüfung an den Chipimmer sofort gelöscht werden. Eine unberechtigte Wiederverwendungbzw. Replay der PIN MÜSSEN ausgeschlossen werden.Es MÜSSEN Vorkehrungen getroffen werden, um die nicht mehrbenötigten Klartext-PINs so zerstören zu können, dass es nichtmehr möglich ist, die PINs ganz oder teilweise zu rekonstruieren.Insbesondere MÜSSEN die Kartenherausgeber geeignete Sicherheitsmaßnahmentreffen in Bezug auf die interne Handhabung undBeseitigung von zurückgesendeten PIN-Briefen und Material, dasmit dem ursprünglichen Druck der PIN-Briefe verbunden ist. Dabeiist darauf zu achten, dass die Behandlung zurückgesandter PIN-Briefe von der Behandlung der zurückgesandten Karten organisatorischgetrennt sein MUSS.Karteneinzug:Die sichere Außerbetriebnahme der PIN und der damit verbundenenKarten ist vom Kartenherausgeber zu regeln. Es MÜSSEN entsprechendepraxistaugliche Verfahren angeboten werden.Hinweis: Auch abgelaufene Karten bergen Risiken z. B. auf der eGKvorhandene medizinische Daten wie etwa Notfalldaten sowie imHBA noch verwendbare C2C-Authentisierungsschlüssel, die einenOffline-Zugriff auf geschützte medizinische Daten ermöglichen.AnhangE.2.1AnhangE.2.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 493 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturE2.2 - Mindestanforderungen und Sicherheits-Policies für die Behandlungder Schlüssel zum Schutz der PIN/PUKDas sichere Management der Schlüssel für die Behandlung der PIN/PUK ist entscheidendfür die Einhaltung der Mindestanforderungen für PIN/PUK. Die Schlüsselverwendung unddie nachfolgenden Bereiche des Schlüsselmanagements MÜSSEN die Mindestanforderungender gematik erfüllen: Der Lebenszyklus der Schlüssel umfasst nach ISO 11770 dieSchlüsselerzeugung (generation) mit Registrierung des Schlüssels bzw. des Zertifikats,die Schlüsselableitung, die Schlüsselaktivierung (activation) mit der Installation, jeweilsoptional die Zertifikatserzeugung, die Schlüsselverteilung, die Schlüsselspeicherung sowiedie Schlüsseldeaktivierung (deactivation), die Reaktivierung (reactivation) und dieSchlüsselzerstörung (destruction).Die übergreifenden Mindestanforderungen für diese Schlüssel werden im Folgenden nochdefiniert.E2.2.1 - Allgemeine Anforderungen und einzuhaltende MindeststandardsDie Sicherheit aller §291a Anwendungen beruht auf der Verwendung der korrekten kryptographischenMethoden und der dabei eingesetzten Schlüssel. Aufgrund dieser zentralenFunktion erfordert das Keymanagement mindestens den Schutzbedarf der sensitivstenAnwendung. Dies beinhaltet den Schutz vor Fehlbedienung, Innentätern und unberechtigtemEindringen oder Ausspähen des Keymanagement-Systems. Daher MÜSSEN diekryptographischen Anforderungen und die festgelegten Algorithmen der gematik vomKeymanagement mindestens erfüllt bzw. umgesetzt werden oder sogar ein höheres Sicherheitsniveauerreichen.Der Betreiber gewährleistet die Integrität, die Verbindlichkeit und die Vertraulichkeit dereingesetzten Schlüssel sowie die Verfügbarkeit seiner eigenen und der ihm anvertrautenSchlüssel und Ressourcen. Dies gilt sowohl auf den eigenen Systemen als auch auf denSystemen, die der Verantwortung des Unternehmens unterstehen.Die Verteilung und Verwendung der Schlüssel MUSS auf das absolut notwendige Maßeingeschränkt werden, um die Möglichkeiten zur Kompromittierung von Schlüsseln zuminimieren und potentielle Schäden zu beschränken. Die Gültigkeitsdauer der Schlüsselist zu begrenzen und geplante Schlüsselwechsel bei Ablauf der Gültigkeit sowie ungeplanteSchlüsselwechsel als Notfall- und Ersatzmaßnahme sind vorzusehen.Der Sinn einer Schlüsselhierarchie liegt darin, einen automatischen Wechsel von häufiggebrauchten oder möglicherweise kompromittierbaren Schlüsseln zu ermöglichen und zuverhindern, dass durch erfolgreiche Angriffe auf Teile des Systems (z. B. einzelne Schlüssel,Karten oder Sicherheitsmodule) das Gesamtsystem oder größere Teile davon betroffenwerden. Die Mindestanforderungen ergeben sich durch die Zuordnung zur Schlüsselhierarchiebzw. durch die durch diese Schlüssel geschützten Daten der Versicherten:• Stufe 1: kryptographische Schlüssel bzw. kryptographisches Material, die einenZugriff auf einzelne Informationsobjekte eines Versicherten ermöglichen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 494 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Stufe 2: kryptographische Schlüssel bzw. kryptographisches Material, die einenZugriff auf alle Informationsobjekte eines Versicherten ermöglichen. 47• Stufe 3: kryptographische Schlüssel bzw. kryptographisches Material, die einenZugriff auf die Informationsobjekte einer Gruppe von Versicherten ermöglichen.Hier sind die PIN-Schlüssel einzuordnen und die nachfolgenden Anforderungensind daher auf diese Stufe ausgerichtet.• Stufe 4: kryptographische Schlüssel bzw. kryptographisches Material, die einenZugriff auf die Informationsobjekte aller Versicherten ermöglichen. 48Auf der Basis der nachfolgenden Mindestanforderungen sind für die Realisierung bestpractices für die Schlüsselverwaltung (siehe [BSI-GK], [SP800-57]) zu verwenden.Nr.SP_KEY_ALL_1SP_KEY_ALL_2SP_KEY_ALL_3Allgemeine Anforderungen an das KeymanagementVertraulichkeitDie verwendeten kryptographischen Verfahren zum Schutz derSchlüssel MÜSSEN mindestens den Mindestanforderungen der gematikgenügen, um den Schutz der Vertraulichkeit der Schlüsselwährend des Transports, der Speicherung sowie des Gebrauchs vornicht autorisierter Aufdeckung, Weitergabe und Nutzung zu gewährleisten.Integrität und AuthentizitätDie Integrität und Authentizität der Schlüssel MÜSSEN gewährleistetwerden. Das betrifft den Schutz vor Änderung und Ersetzung derSchlüssel. Außerhalb geschützter Hardware sind Schlüssel und dieihnen zugeordnete Informationen integritätsgeschützt zu speichernund zu übertragen.VerfügbarkeitEine hohe Serviceverfügbarkeit (24 h, 365 Tage) von Online Anwendungen(u. A. von Post-Issuing-Funktionalitäten) ist sicherzustellen.Die Verfügbarkeit der Anwendungen DARF durch den Zugriff auf diekryptographischen Methoden und die vorhandenen SchlüsselNICHT eingeschränkt werden.Backup und Recovery der Schlüssel: Um die Handhabbarkeit desSchlüsselverwaltungssystems und die Verfügbarkeit von Schlüsselnauch nach Fehlersituationen sicherzustellen, sind alle Schlüssel einemBackup-Prozess zu unterwerfen. Im Fehlerfall MUSS die Wiederherstellung(Recovery) von Schlüsseln innerhalb eines definiertenZeitraums möglich sein.47 Da die Datenhoheit der medizinischen Daten der §291a Anwendungen beim Versicherten liegt,ist die Verwendung dieser Schlüssel bzw. des kryptographischen Materials in der alleinigen Verfügungsgewaltdes Versicherten bzw. der von ihm persönlich Beauftragten. Durch die Prozessgestaltungenund die organisatorischen und technischen Schutzmassnahmen ist jegliche Verwendungdieser Schlüssel ohne Einverständnis und Autorisierung des Versicherten auszuschließen und dieWirksamkeit dieser Maßnahmen ist in einem spezifischen Sicherheitskonzept des jeweiligenBetreibers eines Dienstes oder Komponente nachzuweisen.48 Durch eine Schlüsseltrennung mindestens auf der Ebene der Kartenherausgeber DARF KryptographischesMaterial dieser Stufe 4 NICHT vorhanden sein.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 495 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_ALL_4SP_KEY_ALL_5Allgemeine Anforderungen an das KeymanagementArchivierung von Schlüsseln zur Rekonstruktion historischer Daten.Bei Ablösung eines Schlüssels sollte dieser nicht sofort gelöscht,sondern besser deaktiviert werden. Deaktivierte Schlüssel sollten füreinen Übergangszeitraum archiviert werden, so dass im Notfall aufsie zurückgegriffen werden kann. Nach Ablauf des ÜbergangszeitraumsMÜSSEN die Schlüssel dann physikalisch zerstört (gelöscht)werden.Nachvollziehbarkeit:Die Nachvollziehbarkeit aller relevanten Aktivitäten im System isteine unabdingbare Forderung, sowohl aus entsprechenden gesetzlichenbzw. geschäftlichen Anforderungen, wie auch aus Eigeninteressedes jeweiligen Unternehmens heraus. Der für eine Aktion VerantwortlicheMUSS eindeutig festgestellt werden können. Die Benutzerdes Schlüsselverwaltungssystems und die Nutzer des Schlüsseldiensteskönnen für ihre Handlungen verantwortlich gemacht unddamit auch vor ungerechtfertigten Beschuldigungen geschützt werden.Ebenso MUSS Beweismaterial für Streitfälle erstellt und sicherverwahrt werden.Dies betrifft beim Keymanagement die Nachweisbarkeit der Schlüsselverwendungoder die Nachvollziehbarkeit der vorgenommenHandlungen, vonim Einsatz befindlichen Schlüsseln. (z. B. Verteilung der Schlüssel,Empfänger des Schlüsselmaterials bei manueller Verteilung und derzugehörigen Hauptschlüssel bei elektronischer Verteilung, vorgesehenerund tatsächlicher Gültigkeitszeitraum, Einsatzzweck desSchlüssels)mit einem Schlüssel bearbeiteten bzw. geschützten Objekten.(z. B. verschlüsselte Daten, Schlüssel, PINs, PUKs).Die Verteilung und Verwendung der Schlüssel MUSS auf das absolutnotwendige Maß eingeschränkt werden, um die Möglichkeiten zurKompromittierung von Schlüsseln zu minimieren und potentielleSchäden zu beschränken.Minimale Verteilung: Eine Weitergabe MUSS nur an berechtigteOrganisationen und Personen erfolgen und es MUSS sichergestelltwerden, dass nur die Nutzung der freigegebenen Anwendungenmöglich ist.Gemeinsame symmetrische Schlüssel dürfen nur bei direkt beteiligtenKommunikationspartnern operativ verwendet werden.Session Keys zur Sicherung von Transaktionen SOLLEN nur einmaligverwendet werden.Schlüsseltrennung und minimale Funktionalität: Für jede Anwendungist ein eigener Schlüsselkreis zu definieren. Ein SchlüsselMUSS entsprechend seines Verwendungszweckes eingesetzt werden.Beschränkte Gültigkeitsdauer: Die zeitliche Gültigkeit von SchlüsselnMUSS eingeschränkt sein. Es MUSS ein regelmäßiger Schlüsselwechselaller Schlüssel erfolgen. Für jeden Schlüssel MÜSSENZeiträume definiert sein, in denen ein Schlüssel gültig ist. Nach Ablaufdieser Zeitspanne MÜSSEN die Schlüssel gewechselt werdenund die Verwendung abgelaufener Schlüssel MUSS verhindert wer-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 496 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_ALL_6SP_KEY_ALL_7SP_KEY_ALL_8SP_KEY_ALL_9Allgemeine Anforderungen an das Keymanagementden.Die Schlüsselhierarchie MUSS eindeutig definiert sein, wobei einSchlüssel K H1 eine höhere Stufe hat als ein Schlüssel K H2 , wenn K H2mit Hilfe von K H1 verschlüsselt, signiert oder abgeleitet wird.Ein Schlüssel höherer Hierarchiestufe MUSS mindestens die maximaleLänge aller ihm in der Schlüsselhierarchie untergeordnetenSchlüssel aufweisen. Falls es sich dabei um Schlüssel für unterschiedlicheAlgorithmen handelt, muss dies sinngemäß für die effektivenSchlüssellängen gelten.Die Kompromittierung von Schlüsseln niedrigerer HierarchiestufenDARF NICHT oder nur unter einem Aufwand, der dem Brechen deszugrunde liegenden Verschlüsselungsalgorithmus entspricht, zueiner Kompromittierung von Schlüsseln höherer Hierarchiestufenführen.Nur Schlüssel der untersten Hierarchiestufen SOLLEN zum Schutzvon Daten, die selbst keine Schlüssel sind, verwendet werden.E2.2.2 - Schlüssel-ErzeugungSämtliche kryptographischen Verfahren basieren auf der Gleichverteilung der Schlüsselund auf der Qualität des zugrunde liegenden Zufallszahlengenerators. Unabhängig vonder Schlüssellänge und der mathematischen bzw. algorithmischen Qualität eines Algorithmusbildet ein schlechter Zufallszahlengenerator die Grundlage für erfolgreiche kryptoanalytischeAngriffe. Die Mindestanforderungen der gematik sind einzuhalten.Nr.Anforderungen oder Maßnahme Schlüssel-ErzeugungSP_KEY_CRE_1 Schlüssel ab der zweiten Hierarchieebene bzw. mit langer Lebensdauer(größer als 1 Jahr) MÜSSEN mit Hilfe eines unbeeinflussbaren(echten) Zufallsprozesses gleich verteilt und statistisch unabhängigerzeugt werden.Die übrigen Schlüssel können zufällig oder pseudozufällig erzeugtoder mit Hilfe anderer Schlüssel berechnet werden.SP_KEY_CRE_2 Die Berechnung von Schlüsseln MUSS mit Hilfe eines kryptographischenAlgorithmus so erfolgen, dassder berechnete Schlüssel ohne Kenntnis des für die Berechnungbenutzten Schlüssels nicht einfacher bestimmt werden kann als einzufällig erzeugter Schlüssel.aus der Kenntnis des berechneten Schlüssels und der übrigen Inputdatenkeine Informationen über den für die Berechnung benutztenSchlüssel abgeleitet werden können, ohne den zugrunde liegendenkryptographischen Algorithmus zu brechen.SP_KEY_CRE_3 Alle Schlüssel MÜSSEN in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen erzeugt oder berechnetwerden, so dass sie nicht von Unbefugten ausgelesen oder manipuliertwerden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 497 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.Anforderungen oder Maßnahme Schlüssel-ErzeugungSP_KEY_CRE_4 Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertzu erzeugen, verhindern.E2.2.3 - Schlüssel-SpeicherungDie Schlüssel dürfen während der Speicherung nicht ausgelesen, verändert, ersetzt oderunautorisiert benutzt werden.Nr.SP_KEY_STO_1SP_KEY_STO_2SP_KEY_STO_3SP_KEY_STO_4SP_KEY_STO_5Anforderungen oder Maßnahme Schlüssel-SpeicherungKryptographische Schlüssel DÜRFEN nur in einer der folgendenFormen gespeichert werden:In Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul.Verschlüsselt mit einem Schlüssel höherer Hierarchiestufe.Wenn Schlüssel in Klartext gespeichert werden, MÜSSEN zusätzlichzu den Schlüsseln Hashwerte zur Sicherstellung der Integrität gespeichertwerden.Wenn Schlüssel in verschlüsselter Form gespeichert werden, MUSSzusätzlich zur Vertraulichkeit auch die Authentizität und Integrität derSchlüssel durch ein geeignetes kryptographisches Verfahren sichergestelltwerden. Das Verfahren MUSS auch erlauben, das Wiedereinspielenalter Schlüssel zu erkennen.Einer einzelnen Person DARF es NICHT möglich sein, auf einengeheimen Schlüssel in voller Länge in Klartext zuzugreifen, diesenauszulesen, zu verändern oder zu ersetzen.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertauszulesen, zu verändern, zu ersetzen oder zu benutzen, verhindern.E2.2.4 - Schlüssel-VerteilungDie Schlüssel müssen vertraulich und authentisch verteilt werden, d. h. es muss sichergestelltwerden, dass jeder Schlüssel an die richtige Systemkomponente und nur an dieseverteilt wird. Insbesondere dürfen Schlüssel während der Verteilung auch nicht durch alteVersionen ersetzt werden können (replay).Nr.SP_KEY_TRA_1Anforderungen oder Maßnahme Schlüssel-VerteilungKryptographische Schlüssel DÜRFEN nur in einer der folgendenFormen verteilt werden:In Klartext in mindestens zwei getrennten Komponenten. Der Schlüsselmuss von jedem Bit beider Komponenten abhängen. Jede Komponentemuss mindestens dieselbe Länge wie der vollständigegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 498 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_TRA_2SP_KEY_TRA_3SP_KEY_TRA_4SP_KEY_TRA_5SP_KEY_TRA_6SP_KEY_TRA_7Anforderungen oder Maßnahme Schlüssel-VerteilungSchlüssel aufweisen. Die Komponenten müssen getrennt verteilt werden.Unautorisierter Zugriff darauf muss mit hoher Wahrscheinlichkeitentdeckt werden.In Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).Verschlüsselt mit einem Schlüssel höherer Hierarchiestufe.Es dürfen nur Schlüssel der obersten Hierarchiestufe, die nicht selbstverschlüsselt werden können (z. B. Transportschlüssel), im Klartext(in mindestens zwei getrennten Komponenten) außerhalb eines Sicherheitsmodulsoder einer sicheren Umgebung auftreten, und nursoweit und solange dies für die Verteilung und Initialisierung unbedingterforderlich ist. Die Verbreitung und Gültigkeitsdauer dieserSchlüssel muss so gering wie möglich gehalten werden.Wenn Schlüssel oder Schlüsselkomponenten in Klartext verteilt werden,MÜSSEN zusätzlich zu den Schlüsseln und SchlüsselkomponentenHashwerte zur Sicherstellung der Integrität übermitteltwerden.Wenn Schlüssel in verschlüsselter Form verteilt werden, MUSS zusätzlichzur Vertraulichkeit auch die Authentizität und Integrität derSchlüssel durch ein geeignetes kryptographisches Verfahren sichergestelltwerden. Das Verfahren MUSS auch erlauben, das Wiedereinspielenalter Schlüssel zu erkennen.In der Systemdokumentation MUSS genau beschrieben werden,welcher Schlüssel in welcher Phase in den einzelnen Systemkomponentenbenötigt wird. Die Schlüssel DÜRFEN nur an diejenigenSystemkomponenten verteilt werden, in denen sie tatsächlich benötigtwerden.Der Schutz der Schlüssel bei der Verteilung MUSS durchgehendzwischen den Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere DARF ein Schlüssel zwischen Verteilung undInstallation NICHT in einem den Kriterien für die Speicherung vonSchlüsseln nicht genügenden Zustand zwischengespeichert werden.Ein Schlüssel DARF NICHT in ein Gerät geladen werden, wenn nichtfeststeht, dass die Speicherung des Schlüssels in diesem Gerät dendafür geltenden Kriterien entspricht.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertzu verteilen, verhindern.E2.2.5 – Schlüssel-AktivierungSchlüssel werden in der Regel im deaktivierten Zustand erzeugt und durch die Aktivierungin den operativen Betrieb genommen. Im deaktivierten Zustand ist eine Nutzung desSchlüssels nicht möglich. Ausnahmen sind der Nachweis des Besitzes des Schlüsselsbzw. die Quittierung des Schlüsselerhalts. Die Schlüsselaktivierung kann nach dem Erreicheneines Aktivierungsdatums oder durch ein externes Ereignis durchgeführt werden.Schlüssel die für die sofortige Nutzung erzeugt werden gehen sofort in den aktiven Zustandüber.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 499 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.Anforderungen oder Maßnahme Schlüssel-AktivierungSP_KEY_ACT_1 Alle Funktionen, die die Aktivierung eines Schlüssels betreffen unddie Personal des Herausgebers benötigen, MÜSSEN dem Vieraugenprinzipgehorchen.E2.2.6 – Schlüssel-VerwendungDie Sicherheit einer Anwendung kann potentiell dadurch beeinträchtigt werden, dassSchlüssel auf nicht vorgesehene Art benutzt werden. Dies kann dadurch verhindert werden,dass jedem Schlüssel sein Verwendungszweck eindeutig zugewiesen wird, und dieseZuweisung im Betrieb durchgesetzt und überwacht wird.Nr.SP_KEY_USE_1SP_KEY_USE_2Anforderungen oder Maßnahme Schlüssel-VerwendungJeder Schlüssel MUSS jeweils nur für einen einzigen, in der Spezifikationdes Systems eindeutig definierten kryptographischen Zweckverwendet werden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel für einenanderen Zweck als den vorhergesehenen zu verwenden, erkennenund verhindern.E2.2.7 - Schlüssel-Deaktivierung und Schlüssel-WechselAuch beim Einsatz von Verschlüsselungsalgorithmen, bei denen die Bestimmung derSchlüssel durch Brechen des Verfahrens sehr unwahrscheinlich ist, muss dennoch auchweiterhin mit anderen Angriffen auf die Schlüssel gerechnet werden. Beispiele für solcheGefährdungspotentiale sind etwa physische Zugriffe auf ein Sicherheitsmodul, Bestechung,Erpressung, etc. Aus diesem Grund müssen alle Schlüssel sowohl regelmäßig alsauch notfallmäßig ausgewechselt werden können. Ein regelmäßiger Schlüsselwechselbegrenzt den Schaden im Falle von unentdeckten Kompromittierungen. Ein notfallmäßigerSchlüsselwechsel begrenzt den Schaden im Falle von entdeckten Kompromittierungen.Nr.SP_KEY_DEA_1SP_KEY_DEA_2SP_KEY_DEA_3SP_KEY_DEA_4Anforderungen oder Maßnahme Schlüssel-Deaktivierung,Schlüssel-WechselEs MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumregelmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumnotfallmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertauszuwechseln, verhindern.Im Fall einer erkannten (oder angenommenen) KompromittierungMÜSSEN geeignete Maßnahmen ergriffen werden können,um alle Daten und Schlüssel zu bestimmen, die mit dem kompromittiertenSchlüssel oder davon abgeleiteten Schlüsseln geschützt wurden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 500 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.Anforderungen oder Maßnahme Schlüssel-Deaktivierung,Schlüssel-Wechselum die weitere Verwendung des kompromittierten Schlüssels undaller davon abgeleiteten bzw. geschützter Schlüssel bzw. PIN/PUKzu verhindern.E2.2.8 - Schlüssel-ZerstörungEin Schlüssel DARF NICHT außerhalb der Gültigkeitsdauer und MUSS für den vomSchlüsselinhaber vorgesehenen Zweck verwendet werden. Um missbräuchliche Verwendungund Kompromittierungsmöglichkeiten zu verringern MUSS der Schlüssel daher inallen Komponenten unverzüglich sicher gelöscht werden, wenn die die Gültigkeitsdauerabläuft oder in einer Komponente wenn er dort nicht mehr benötigt wird.Nr.SP_KEY_DEL_1SP_KEY_DEL_2Anforderungen oder Maßnahme Schlüssel-ZerstörungNicht mehr benötigte Schlüssel MÜSSEN unverzüglich sicher gelöschtwerden.Die unverzügliche sichere Löschung ist im Sicherheitskonzept derjeweiligen Komponente und Dienste nachzuweisen.SchlüsselzerstörungEs MÜSSEN Vorkehrungen getroffen werden, um nicht mehr benötigteSchlüssel oder aktive Schlüssel im Fall der drohenden Kompromittierungso zerstören zu können, dass es nicht mehr möglichist, die Schlüssel ganz oder teilweise zu rekonstruieren.E2.2.9 - Prozessgestaltung und spezifisches Sicherheitskonzept des BetreibersDer Betreiber MUSS für das Keymanagement ein spezifisches Sicherheitskonzept erstellen.Das spezifische Sicherheitskonzept eines Betreibers für die Betriebsumgebung desKeymanagements SOLL mindestens folgende Inhalte (vgl. z.B. § 2 SigV) enthalten. DieseAnforderungen sind auf elf Bereiche nach ISO27001 (vgl. BSI Standards 100-1,2,3). aufgeteilt:Nr.SP_KEY_PRO_1SP_KEY_PRO_2Übergreifende Anforderungen an die Prozessgestaltung unddas spezifisches Sicherheitskonzept des BetreibersInformation Security PolicyAlle sicherheitsrelevanten Aktivitäten werden in Standards undRegelwerken niedergelegt, die ständig an alle sich ändernden Anforderungenangepasst und ggf. erweitert werden MÜSSEN. EineBeschreibung aller erforderlichen technischen, baulichen und organisatorischenSicherheitsmaßnahmen und deren EignungMUSS erfolgen.Die Einhaltung der Standards und Regelwerke MUSS von denUnternehmen gewährleistet werden. Das Keymanagement wirdbeeinflusst von den aktuell gültigen Mindeststandards der gematikOrganisationgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 501 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_3SP_KEY_PRO_4SP_KEY_PRO_5SP_KEY_PRO_6Übergreifende Anforderungen an die Prozessgestaltung unddas spezifisches Sicherheitskonzept des BetreibersEine Übersicht über die Aufbau- und Ablauforganisation für denBetrieb des Sicherheitsmanagements MUSS erstellt werden indem die Verantwortlichkeiten, Rechte und Pflichten des Bedienungspersonalseindeutig festgelegt sind.Durch personelle und organisatorische Maßnahmen MUSS sichergestelltwerden, dass nur ausdrücklich autorisierten Personen undAnwendungen der Umgang und die Verwendung der Schlüsselmöglich ist.Für die Anwendung besonders sensitiver Kryptoverfahren undSchlüssel (beispielsweise manuelle Verteilung initialer Transportschlüssel)MÜSSEN Personen gesondert ermächtigt werden.AssetmanagementEine Festlegung der Verantwortlichkeiten für alle Funktionen desSchlüsselmanagements mit den notwendigen organisatorischenTrennungen und Unvereinbarkeiten von Rollen sowie eine Abschätzungund Bewertung verbleibender Restrisiken MUSS erfolgenEine Person DARF dabei NICHT zu einem Zeitpunkt die vollständigeKontrolle oder die Kenntnis über die in einem Bereich verwendetenSchlüssel besitzen. Daher ist eine Aufspaltung derFunktionen und Definition von Rollen notwendig, sodass das Vier-Augen-Prinzip gewährleistet ist. Dies bietet einerseits einenSchutz vor Innentätern, andererseits lassen sich somit unberechtigteVerdachtsmomente und unbegründete Anschuldigungen vonMitarbeitern vermeiden.Die Aufbau- und Ablauforganisation MÜSSEN vollständig definiertund dokumentiert sein. Die Trennung und die Unvereinbarkeit vonfunktionalen, operativen und administrativen Tätigkeiten sind dabeiim Sicherheitskonzept des Betreibers zu berücksichtigen.Human resources securityDas eingesetzte Verfahren zur Beurteilung und Sicherstellung derZuverlässigkeit des eingesetzten Personals MUSS beschriebenwerden. Eine Auswahl besonders vertrauenswürdiger Personenals Schlüsselbeauftragte (für den Umgang mit Schlüsselmaterial)ist zu treffen.Schlüsselbeauftragte und ggf. der Benutzer von KryptoverfahrenMÜSSEN regelmäßig bezüglich der Einhaltung des Kryptoverfahrensund aller weiteren Festlegungen zur Schlüsselsicherheit geschultwerden.Physical and Environmental SecurityEine Beschreibung aller vorhandenen baulichen und organisatorischenSicherheitsmaßnahmen der Zutrittskontrolle und deren EignungMUSS vorhanden sein.Communications and Operations ManagementEine Übersicht über die eingesetzten Produkte und entsprechendeErklärungen zu den dadurch realisierten Sicherheitsfunktionenund deren Eignung MUSS erstellt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 502 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_7SP_KEY_PRO_8Übergreifende Anforderungen an die Prozessgestaltung unddas spezifisches Sicherheitskonzept des BetreibersDie manuelle Ausgabe, Verteilung und Eingabe von SchlüsselnMUSS auf das unvermeidbar notwendige Maß zu beschränkenund ist nach dem Vier-Augen-Prinzip zu realisieren.Access ControlAlle vorhanden technischen und organisatorischen Sicherheitsmaßnahmender Zugriffskontrolle und deren Eignung MÜSSENbeschrieben werden.Information systems acquisition, development and maintenanceDie Maßnahmen der Systementwicklung, des Tests, und der WartungSOLLEN beschrieben sein. Das Schlüsselverwaltungssystemund der Schlüsseldienst werden vor ihrer Einführung getestet, undihre Vertrauenswürdigkeit wird nachgewiesen. Bei einem Übergangvom Testbetrieb zum Produktionsbetrieb bzw. vom Produktionsbetriebzur Instandhaltung und umgekehrt sollen spezielle Sicherheitsmaßnahmenergriffen, um diese Phasen zu trennen unddie Sicherheit des Produktionsbetriebs zu gewährleisten. Die folgendenMindestanforderungen SOLLEN eingehalten werden:Die Hersteller von Geräten oder Programmen MÜSSEN nachweisen,dass sie nach einer bewährten Entwicklungsmethodik arbeiten,die mindestens die folgenden drei (oder zu diesen äquivalente)Stufen umfasst:Funktionale SpezifikationArchitekturentwurf (oder Grobentwurf)FeinentwurfDie sicherheitsrelevanten Komponenten und Schnittstellen, sowiederen Abgrenzung zu nicht sicherheitsrelevanten KomponentenMÜSSEN klar bezeichnet werden. Die in der angewandten Entwicklungsmethodikdefinierten Stufen MÜSSEN zumindest fürjede sicherheitsrelevante Komponente und Schnittstelle ausführlichund nachvollziehbar dokumentiert sein. Die DokumentationMUSS den zuständigen Stellen zur Prüfung der Sicherheit zurVerfügung gestellt werden.Die Entwicklungsunterlagen MÜSSEN während ihrer Erstellung,Speicherung, Übermittlung, Lagerung und Prüfung gegen unbefugtenZugriff und insbesondere gegen unbemerkte Veränderunggeschützt werden.Die Implementierung MUSS in einer Weise strukturiert erfolgenund dokumentiert werden, dass die im Feinentwurf identifiziertensicherheitsrelevanten Komponenten und Schnittstellen im Gerätoder Programm eindeutig identifizierbar sind.Software-Implementierungen sind in einer gut dokumentiertenProgrammiersprache durchzuführen. Der dokumentierte Quellcodeist den zuständigen Stellen zur Prüfung zur Verfügung zu stellen.Die Hersteller von Geräten oder Programmen MÜSSEN nachweisen,dass sie während der gesamten Implementierungs- und Wartungsphasemit einem bewährten Konfigurationskontrollsystemgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 503 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_9Übergreifende Anforderungen an die Prozessgestaltung unddas spezifisches Sicherheitskonzept des Betreibersarbeiten.Die Hersteller MÜSSEN nachweisen, dass bei der Implementierungdie Verantwortlichkeiten und Zugriffsrechte klar definiertsind und die Arbeiten in einer Umgebung und mit Werkzeugenausgeführt werden, die eine Kontrolle von Zuständigkeitenund Zugriffsrechten jederzeit gewährleisten.Die Hersteller MÜSSEN umfassende Tests der Funktionalität undPrüfungen der Sicherheit durchführen. Insbesondere MUSS nachgewiesenwerden, dass die beabsichtigten Funktionen nicht missbrauchtoder umgangen werden können, und dass nur die beabsichtigtenFunktionen ausgeführt werden können. Die Testdatenund Testergebnisse sind zu dokumentieren und den zuständigenStellen zur Prüfung zur Verfügung zu stellen.Die Hersteller MÜSSEN nachweisen, dass sie die notwendigenWartungsarbeiten, den Ersatz und das Update von Komponentenin einer Weise organisieren und durchführen können, die eine unautorisierteVeränderung der Geräte oder Programme zuverlässigverhindert.Nachträgliches Herunterladen von Programm-Updates von sicherheitsrelevantenDiensten darf nur nach gegenseitiger kryptographischerAuthentifikation der kommunizierenden Parteienstattfinden. Die Integrität der Programm-Updates MUSS geschütztsein.Die Hersteller MÜSSEN für alle Komponenten Installationsprozedurendefinieren und ggf. Werkzeuge mitliefern, die gewährleisten,dass die Geräte und Programme auf dem gesamtenWeg von der Implementierungs- bis in die Betriebsumgebungdurchgehend gegen unbemerkte Manipulationen gesichert sind.Information security incident managementEs ist nicht möglich, ein System vollständig gegen Angriffe abzusichern.Deshalb muss eine wichtige Sicherheitsfunktion, zumindestdas Erkennen von Angriffen und Angriffsversuchen gegen dasSystem unterstützen. Mit Hilfe dieser Funktion wird die Analyseder Angriffe erleichtert. Entsprechend notwendige Alarmbehandlungenund Schadensabwehrmaßnahmen können durchführenwerden.Beim Auftreten bestimmter, durch die Beweissicherung erfassterEreignisse wird unverzüglich Sicherheitsalarm ausgelöst und einbestimmter Benutzer / eine bestimmte Rolle benachrichtigt.Es muss im Sicherheitskonzept des Betreibers festgelegt sein,welche Situationen zu Alarmen führen.Für alle definierten Alarme MUSS folgendes gelten:Es MUSS festgelegt sein, wer für die Bearbeitung des Alarms zuständigist.Es MÜSSEN Verfahren existieren, um festzustellen, welcherSchaden angerichtet worden ist. Die dazu notwendigen InformationenMÜSSEN gesammelt und bereitgestellt werden.Es MUSS festgelegt sein, welche Notfallprozeduren und Abwehr-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 504 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_10SP_KEY_PRO_11Übergreifende Anforderungen an die Prozessgestaltung unddas spezifisches Sicherheitskonzept des Betreibersstrategien ablaufen sollen. Insbesondere MÜSSEN die maximalenReaktionszeiten, die Informations- und Entscheidungsprozessefestgelegt sein.Es muss mindestens dann ein Alarm ausgelöst werden, wennSchlüssel oder PINs bei der Erzeugung, Verteilung, Speicherungoder im Betrieb kompromittiert wurden. Die gematik MUSS unverzüglichinformiert werden.Business Continuity ManagementEs MÜSSEN Maßnahmen für einen notfallmäßigen Schlüsselwechselvorgesehen werden.ComplianceDie Einhaltung der rechtlichen Vorgaben, der Sicherheitsrichtliniemuss durch unabhängige Audits geprüft werden. Es MÜSSEN regelwidrigeHandlungen von eigentlich autorisierten Personen zumindestnachträglich entdeckt und nachgewiesen werden können.Dazu ist das Führen von Audit 49 Trails und Log-Aufzeichnungennotwendig.Darin MÜSSEN z. B. Verletzungen von Sicherheitsregeln und Unregelmäßigkeitenim System (z. B. unkorrekte Übertragung, mehrfacheInitialisierung von individuellen Systemkomponenten, mehrfacheunkorrekte Eingabe von PINs, wiederholte Meldungen) aufgezeichnetwerden. Diese Aufzeichnungen MÜSSEN so geführtwerden, dass es möglich ist, relevante Operationen, die mit sensitivenDaten durchgeführt wurden, und die dabei betroffenen Datenzu rekonstruieren. Diese Aufzeichnungen MÜSSEN so ausgewertetwerden, dass sie innerhalb einer akzeptablen Frist zu geeignetenAlarmbehandlungen führen.Es MUSS ein Dienst geschaffen werden, der alle sicherheitsrelevantenAktionen von Benutzern und Anwendungen protokolliert.Hierzu gehören u. a.Anmeldungen von Benutzern am System,Rollenwechsel,fehlgeschlagene Authentifikationen undversuchte unberechtigte Zugriffe auf ObjekteZusätzlich SOLLEN die protokollierten Daten regelmäßig gesichtet,aufbereitet und ausgewertet werden, so dass Lücken im Sicherheitssystem(z. B. Ausnutzung verdeckter Kanäle, etc.) frühzeitigaufgedeckt werden können. Der Zugriff auf AuditdatenMUSS auf einen kleinen Personenkreis beschränkt bleiben.49 In diesem Audit werden die sicherheitsrelevanten Aktionen der Schlüsselverwaltung aufgezeichnet,,ein Zusammenhang mit dem versichertenzentrierten Audit des Versicherten ist nicht vorhanden“.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 505 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturE2.2.9 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03074A_03075A_03076SP_KEY_ALL_1SP_KEY_ALL_2SP_KEY_ALL_3SSSKEY_Managnemant_01: Vertraulichkeitder Schlüssel.KEY_Managnemant_02: Integritätund Authentizität der Schlüssel.KEY_Managnemant_03: Verfügbarkeitder Schlüssel.VertraulichkeitDie verwendeten kryptographischen Verfahren zum Schutz derSchlüssel MÜSSEN mindestens den Mindestanforderungen dergematik genügen, um den Schutz der Vertraulichkeit der Schlüsselwährend des Transports, der Speicherung sowie des Gebrauchs vornicht autorisierter Aufdeckung, Weitergabe und Nutzung zu gewährleistenIntegrität und AuthentizitätDie Integrität und Authentizität der Schlüssel MÜSSEN gewährleistetwerden. Das betrifft den Schutz vor Änderung und Ersetzung derSchlüssel. Außerhalb geschützter Hardware sind Schlüssel und dieihnen zugeordnete Informationen integritätsgeschützt zu speichernund zu übertragenVerfügbarkeitEine hohe Serviceverfügbarkeit (24 h, 365 Tage) von Online Anwendungen(u. A. von Post-Issuing-Funktionalitäten) ist sicherzustellen.Die Verfügbarkeit der Anwendungen DARF durch denZugriff auf die kryptographischen Methoden und die vorhandenenSchlüssel NICHT eingeschränkt werden.o Backup und Recovery der Schlüssel: Um die Handhabbarkeit desSchlüsselverwaltungssystems und die Verfügbarkeit von Schlüsselnauch nach Fehlersituationen sicherzustellen, sind alle Schlüsseleinem Backup-Prozess zu unterwerfen. Im Fehlerfall MUSS dieWiederherstellung (Recovery) von Schlüsseln innerhalb eines definiertenZeitraums möglich sein.o Archivierung von Schlüsseln zur Rekonstruktion historischer Daten.Bei Ablösung eines Schlüssels sollte dieser nicht sofort gelöscht,sondern besser deaktiviert werden. Deaktivierte Schlüsselsollten für einen Übergangszeitraum archiviert werden, so dass imNotfall auf sie zurückgegriffen werden kann. Nach Ablauf des Über-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 506 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03077A_03078SP_KEY_ALL_4SP_KEY_ALL_5SSKEY_Managnemant_04: Nachvollziehbarkeitaller Tätigkeitenbeim Schlüsselmanagement.KEY_Managnemant_05: Beachtungdes Minimalitätsprinzipsbeim Umgang mit Schlüsselmitteln.gangszeitraums MÜSSEN die Schlüssel dann physikalisch zerstört(gelöscht) werden.Nachvollziehbarkeit:Die Nachvollziehbarkeit aller relevanten Aktivitäten im System isteine unabdingbare Forderung, sowohl aus entsprechenden gesetzlichenbzw. geschäftlichen Anforderungen, wie auch aus Eigeninteressedes jeweiligen Unternehmens heraus. Der für eine AktionVerantwortliche MUSS eindeutig festgestellt werden können. DieBenutzer des Schlüsselverwaltungssystems und die Nutzer desSchlüsseldienstes können für ihre Handlungen verantwortlich gemachtund damit auch vor ungerechtfertigten Beschuldigungen geschütztwerden. Ebenso MUSS Beweismaterial für Streitfälle erstelltund sicher verwahrt werden.Dies betrifft beim Keymanagement die Nachweisbarkeit der Schlüsselverwendungoder die Nachvollziehbarkeit der vorgenommenHandlungen, vono im Einsatz befindlichen Schlüsseln. (z. B. Verteilung der Schlüssel,Empfänger des Schlüsselmaterials bei manueller Verteilung undder zugehörigen Hauptschlüssel bei elektronischer Verteilung, vorgesehenerund tatsächlicher Gültigkeitszeitraum, Einsatzzweck desSchlüssels)o mit einem Schlüssel bearbeiteten bzw. geschützten Objekten.(z. B. verschlüsselte Daten, Schlüssel, PINs, PUKs).Die Verteilung und Verwendung der Schlüssel MUSS auf das absolutnotwendige Maß eingeschränkt werden, um die Möglichkeitenzur Kompromittierung von Schlüsseln zu minimieren und potentielleSchäden zu beschränken.o Minimale Verteilung: Eine Weitergabe MUSS nur an berechtigteOrganisationen und Personen erfolgen und es MUSS sichergestelltwerden, dass nur die Nutzung der freigegebenen Anwendungenmöglich ist.Gemeinsame symmetrische Schlüssel dürfen nur bei direkt beteilig-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 507 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03079A_03080A_03081A_03082A_03083SP_KEY_ALL_6SP_KEY_ALL_7SP_KEY_ALL_8SP_KEY_ALL_9SP_KEY_CRESSSSSKEY_Managnemant_06: Definitioneiner eindeutigen Schlüsselhierarchie.KEY_Managnemant_07: Hierarchiestufenund Schlüssellängen.KEY_Managnemant_08: Kompromittierungvon Schlüsselnniedrigerer HierarchiestufenKEY_Managnemant_09: Nutzungder untersten Hierarchiestufefür Datenschlüssel.KEY_Erzeugung_01: Schlüsselgenerierungmittels echterten Kommunikationspartnern operativ verwendet werden.o Session Keys zur Sicherung von Transaktionen SOLLEN nur einmaligverwendet werden.o Schlüsseltrennung und minimale Funktionalität: Für jede Anwendungist ein eigener Schlüsselkreis zu definieren. Ein SchlüsselMUSS entsprechend seines Verwendungszweckes eingesetzt werden.o Beschränkte Gültigkeitsdauer: Die zeitliche Gültigkeit von SchlüsselnMUSS eingeschränkt sein. Es MUSS ein regelmäßiger Schlüsselwechselaller Schlüssel erfolgen. Für jeden Schlüssel MÜSSENZeiträume definiert sein, in denen ein Schlüssel gültig ist. Nach Ablaufdieser Zeitspanne MÜSSEN die Schlüssel gewechselt werdenund die Verwendung abgelaufener Schlüssel MUSS verhindert werden.Die Schlüsselhierarchie MUSS eindeutig definiert sein, wobei einSchlüssel KH1 eine höhere Stufe hat als ein Schlüssel KH2, wennKH2 mit Hilfe von KH1 verschlüsselt, signiert oder abgeleitet wird.Ein Schlüssel höherer Hierarchiestufe MUSS mindestens die maximaleLänge aller ihm in der Schlüsselhierarchie untergeordnetenSchlüssel aufweisen. Falls es sich dabei um Schlüssel für unterschiedlicheAlgorithmen handelt, muss dies sinngemäß für die effektivenSchlüssellängen gelten.Die Kompromittierung von Schlüsseln niedrigerer HierarchiestufenDARF NICHT oder nur unter einem Aufwand, der dem Brechen deszugrunde liegenden Verschlüsselungsalgorithmus entspricht, zueiner Kompromittierung von Schlüsseln höherer Hierarchiestufenführen.Nur Schlüssel der untersten Hierarchiestufen SOLLEN zum Schutzvon Daten, die selbst keine Schlüssel sind, verwendet werden.Schlüssel ab der zweiten Hierarchieebene bzw. mit langer Lebensdauer(größer als 1 Jahr) MÜSSEN mit Hilfe eines unbeeinflussba-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 508 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03084A_03085A_03086A_03087A_03088A_03089_1 Zufallszahlen. ren (echten) Zufallsprozesses gleich verteilt und statistisch unabhängigerzeugt werden.Die übrigen Schlüssel können zufällig oder pseudozufällig erzeugtoder mit Hilfe anderer Schlüssel berechnet werden.SP_KEY_CRE_2SP_KEY_CRE_3SP_KEY_STO_1SP_KEY_STO_2SP_KEY_STO_3SSSSSSKEY_Erzeugung_02: Berechnungvon Schlüsseln.KEY_Erzeugung_03: Erzeugung/Berechnungin einer sicherenUmgebung.KEY_Erzeugung_04: Verhindernunautorisierter Nutzung.KEY_Storage_01: GesicherteSpeicherung.KEY_Storage_02: Integritätssicherungbei Klartextspeicherung.KEY_Storage_03:Vertaulichkeits/Integritäts-/Authentizitätssicherung beiverschlüsselter Speicherung.Die Berechnung von Schlüsseln MUSS mit Hilfe eines kryptographischenAlgorithmus so erfolgen, dasso der berechnete Schlüssel ohne Kenntnis des für die Berechnungbenutzten Schlüssels nicht einfacher bestimmt werden kann als einzufällig erzeugter Schlüssel.o aus der Kenntnis des berechneten Schlüssels und der übrigenInputdaten keine Informationen über den für die Berechnung benutztenSchlüssel abgeleitet werden können, ohne den zugrundeliegenden kryptographischen Algorithmus zu brechen.Alle Schlüssel MÜSSEN in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen erzeugt oder berechnetwerden, so dass sie nicht von Unbefugten ausgelesen oder manipuliertwerden könnenDie Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertzu erzeugen, verhindern.Kryptographische Schlüssel DÜRFEN nur in einer der folgendenFormen gespeichert werden:o In Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul.o Verschlüsselt mit einem Schlüssel höherer HierarchiestufeWenn Schlüssel in Klartext gespeichert werden, MÜSSEN zusätzlichzu den Schlüsseln Hashwerte zur Sicherstellung der Integritätgespeichert werden.Wenn Schlüssel in verschlüsselter Form gespeichert werden, MUSSzusätzlich zur Vertraulichkeit auch die Authentizität und Integritätder Schlüssel durch ein geeignetes kryptographisches Verfahrensichergestellt werden. Das Verfahren MUSS auch erlauben, dasWiedereinspielen alter Schlüssel zu erkennen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 509 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03090A_03091A_03092A_03093A_03094SP_KEY_STO_4SP_KEY_STO_5SP_KEY_TRA_1SP_KEY_TRA_2SP_KEY_TRA_3SSSSSKEY_Storage_04: Schutz vorKompomittierung durch einzelnePersonen.KEY_Storage_05: Schutz vorunautorisierter Schlüsselnutzung.KEY_Transport_01: Schutz vonSchlüsseln bei Verteilung/Transport.KEY_Transport_02: Integritätssicherungbei Verteilung imKlartext.KEY_Transport_03:Integritäts-/Authentizitätssicherung beiVerteilung im verschlüsselterVerteilung.Einer einzelnen Person DARF es NICHT möglich sein, auf einengeheimen Schlüssel in voller Länge in Klartext zuzugreifen, diesenauszulesen, zu verändern oder zu ersetzen.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertauszulesen, zu verändern, zu ersetzen oder zu benutzen, verhindern.Kryptographische Schlüssel DÜRFEN nur in einer der folgendenFormen verteilt werden:o In Klartext in mindestens zwei getrennten Komponenten. DerSchlüssel muss von jedem Bit beider Komponenten abhängen. JedeKomponente muss mindestens dieselbe Länge wie der vollständigeSchlüssel aufweisen. Die Komponenten müssen getrennt verteiltwerden. Unautorisierter Zugriff darauf muss mit hoher Wahrscheinlichkeitentdeckt werden.o In Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).o Verschlüsselt mit einem Schlüssel höherer Hierarchiestufe.Es dürfen nur Schlüssel der obersten Hierarchiestufe, die nichtselbst verschlüsselt werden können (z. B. Transportschlüssel), imKlartext (in mindestens zwei getrennten Komponenten) außerhalbeines Sicherheitsmoduls oder einer sicheren Umgebung auftreten,und nur soweit und solange dies für die Verteilung und Initialisierungunbedingt erforderlich ist. Die Verbreitung und Gültigkeitsdauer dieserSchlüssel muss so gering wie möglich gehalten werden.Wenn Schlüssel oder Schlüsselkomponenten in Klartext verteiltwerden, MÜSSEN zusätzlich zu den Schlüsseln und SchlüsselkomponentenHashwerte zur Sicherstellung der Integrität übermitteltwerden.Wenn Schlüssel in verschlüsselter Form verteilt werden, MUSS zusätzlichzur Vertraulichkeit auch die Authentizität und Integrität derSchlüssel durch ein geeignetes kryptographisches Verfahren sichergestelltwerden. Das Verfahren MUSS auch erlauben, das Wie-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 510 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelledereinspielen alter Schlüssel zu erkennen.A_03095A_03096A_03097A_03098A_03099A_03100A_03101A_03102SP_KEY_TRA_4SP_KEY_TRA_5SP_KEY_TRA_6SP_KEY_TRA_7SP_KEY_ACT_1SP_KEY_USE_1SP_KEY_USE_2SP_KEY_DEA_1SSSSSSSSKEY_Transport_04: Dokumentationder Schlüsselverteilungund Beachtung des Minimalitätsprinzips.KEY_Transport_05: Durchgängigsicherer Verteilungsprozess.KEY_Transport_06: Kein Einbringenvon Schlüsseln in ungeeigneteGeräte.KEY_Transport_07: Schutz vorunautorisierter Verteilung.KEY_Aktivierung_01: Beachtungdes Vieraugenprinzip beider Schlüsselaktivierung.KEY_Verwendung_01: Zweckbindungvon Schlüsseln.KEY_Verwendung_02:Systemtechnische Sicherstellung derZweckbindung von SchlüsselnKEY_Deaktivierung_01: Möglichkeitenzum regelmäßigenSchlüsselwechsel müssen vorgesehenwerden.In der Systemdokumentation MUSS genau beschrieben werden,welcher Schlüssel in welcher Phase in den einzelnen Systemkomponentenbenötigt wird. Die Schlüssel DÜRFEN nur an diejenigenSystemkomponenten verteilt werden, in denen sie tatsächlich benötigtwerden.Der Schutz der Schlüssel bei der Verteilung MUSS durchgehendzwischen den Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere DARF ein Schlüssel zwischen Verteilung undInstallation NICHT in einem den Kriterien für die Speicherung vonSchlüsseln nicht genügenden Zustand zwischengespeichert werden.Ein Schlüssel DARF NICHT in ein Gerät geladen werden, wennnicht feststeht, dass die Speicherung des Schlüssels in diesem Gerätden dafür geltenden Kriterien entspricht.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertzu verteilen, verhindern.Alle Funktionen, die die Aktivierung eines Schlüssels betreffen unddie Personal des Herausgebers benötigen, MÜSSEN dem Vieraugenprinzipgehorchen.Jeder Schlüssel MUSS jeweils nur für einen einzigen, in der Spezifikationdes Systems eindeutig definierten kryptographischen Zweckverwendet werden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel für einenanderen Zweck als den vorhergesehenen zu verwenden, erkennenund verhindern.Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumregelmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 511 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03103A_03104A_03105A_03106A_03107A_03108SP_KEY_DEA_2SP_KEY_DEA_3SP_KEY_DEA_4SSSSP_KE SY_DEL_1SP_KE SY_DEL_2SP_KEY_PRO_1SKEY_Deaktivierung_02:KEY_Deaktivierung_01: Möglichkeitenzum Schlüsselwechselin Notfällen.KEY_Deaktivierung_03: Schutzvor unautorisiertem Schlüsselwechsel.KEY_Deaktivierung_04: DeaktivierungkompromittierterSchlüssel.KEY_Löschung_01: SichereLöschung nicht mehr benötigterSchlüssel.KEY_Löschung_02: SichereZerstörung nicht mehr benötigterSchlüssel und aktiverSchlüssel, die von Kompromittierungbedroht sind.KEY_Prozesse_01: InformationSecurity PolicyEs MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumnotfallmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertauszuwechseln, verhindern.Im Fall einer erkannten (oder angenommenen) KompromittierungMÜSSEN geeignete Maßnahmen ergriffen werden können,o um alle Daten und Schlüssel zu bestimmen, die mit dem kompromittiertenSchlüssel oder davon abgeleiteten Schlüsseln geschütztwurden.• um die weitere Verwendung des kompromittierten Schlüssels undaller davon abgeleiteten bzw. geschützter Schlüssel bzw. PIN/PUKzu verhindern.Nicht mehr benötigte Schlüssel MÜSSEN unverzüglich sicher gelöschtwerden.Die unverzügliche sichere Löschung ist im Sicherheitskonzept derjeweiligen Komponente und Dienste nachzuweisen.SchlüsselzerstörungEs MÜSSEN Vorkehrungen getroffen werden, um nicht mehr benötigteSchlüssel oder aktive Schlüssel im Fall der drohenden Kompromittierungso zerstören zu können, dass es nicht mehr möglichist, die Schlüssel ganz oder teilweise zu rekonstruierenInformation Security PolicyAlle sicherheitsrelevanten Aktivitäten werden in Standards und Regelwerkenniedergelegt, die ständig an alle sich ändernden Anforderungenangepasst und ggf. erweitert werden MÜSSEN. Eine Beschreibungaller erforderlichen technischen, baulichen und organisatorischenSicherheitsmaßnahmen und deren Eignung MUSS erfolgen.Die Einhaltung der Standards und Regelwerke MUSS von den Un-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 512 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03109A_03110SP_KEY_PRO_2SP_KEY_PRO_3SSKEY_Prozesse_02: AufbauundAblauforganisationKEY_Prozesse_03: Assetmanagementternehmen gewährleistet werden. Das Keymanagement wird beeinflusstvon den aktuell gültigen Mindeststandards der gematikOrganisationEine Übersicht über die Aufbau- und Ablauforganisation für den Betriebdes Sicherheitsmanagements MUSS erstellt werden in dem dieVerantwortlichkeiten, Rechte und Pflichten des Bedienungspersonalseindeutig festgelegt sind.Durch personelle und organisatorische Maßnahmen MUSS sichergestelltwerden, dass nur ausdrücklich autorisierten Personen undAnwendungen der Umgang und die Verwendung der Schlüsselmöglich ist.Für die Anwendung besonders sensitiver Kryptoverfahren undSchlüssel (beispielsweise manuelle Verteilung initialer Transportschlüssel)MÜSSEN Personen gesondert ermächtigt werden.AssetmanagementEine Festlegung der Verantwortlichkeiten für alle Funktionen desSchlüsselmanagements mit den notwendigen organisatorischenTrennungen und Unvereinbarkeiten von Rollen sowie eine Abschätzungund Bewertung verbleibender Restrisiken MUSS erfolgenEine Person DARF dabei NICHT zu einem Zeitpunkt die vollständigeKontrolle oder die Kenntnis über die in einem Bereich verwendetenSchlüssel besitzen. Daher ist eine Aufspaltung der Funktionenund Definition von Rollen notwendig, sodass das Vier-Augen-Prinzipgewährleistet ist. Dies bietet einerseits einen Schutz vor Innentätern,andererseits lassen sich somit unberechtigte Verdachtsmomenteund unbegründete Anschuldigungen von Mitarbeitern vermeiden.Die Aufbau- und Ablauforganisation MÜSSEN vollständig definiertund dokumentiert sein. Die Trennung und die Unvereinbarkeit vonfunktionalen, operativen und administrativen Tätigkeiten sind dabeiim Sicherheitskonzept des Betreibers zu berücksichtigen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 513 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03111A_03112A_03113A_03114A_03115SP_KEY_PRO_4SP_KEY_PRO_5SP_KEY_PRO_6SP_KEY_PRO_7SP_KEY_PRO_8SSSSSKEY_Prozesse_04: Humanresources securityKEY_Prozesse_05: Physicaland Environmental SecurityKEY_Prozesse_06: Communicationsand Operations ManagementKEY_Prozesse_07: AccessControlKEY_Prozesse_08: Informationsystems acquisition, developmentand maintenanceHuman resources securityDas eingesetzte Verfahren zur Beurteilung und Sicherstellung derZuverlässigkeit des eingesetzten Personals MUSS beschriebenwerden. Eine Auswahl besonders vertrauenswürdiger Personen alsSchlüsselbeauftragte (für den Umgang mit Schlüsselmaterial) ist zutreffen.Schlüsselbeauftragte und ggf. der Benutzer von KryptoverfahrenMÜSSEN regelmäßig bezüglich der Einhaltung des Kryptoverfahrensund aller weiteren Festlegungen zur Schlüsselsicherheit geschultwerden.Physical and Environmental SecurityEine Beschreibung aller vorhandenen baulichen und organisatorischenSicherheitsmaßnahmen der Zutrittskontrolle und deren EignungMUSS vorhanden sein.Communications and Operations ManagementEine Übersicht über die eingesetzten Produkte und entsprechendeErklärungen zu den dadurch realisierten Sicherheitsfunktionen undderen Eignung MUSS erstellt werden.Die manuelle Ausgabe, Verteilung und Eingabe von SchlüsselnMUSS auf das unvermeidbar notwendige Maß zu beschränken undist nach dem Vier-Augen-Prinzip zu realisieren.Access ControlAlle vorhanden technischen und organisatorischen Sicherheitsmaßnahmender Zugriffskontrolle und deren Eignung MÜSSEN beschriebenwerden.Information systems acquisition, development and maintenanceDie Maßnahmen der Systementwicklung, des Tests, und der WartungSOLLEN beschrieben sein. Das Schlüsselverwaltungssystemund der Schlüsseldienst werden vor ihrer Einführung getestet, undihre Vertrauenswürdigkeit wird nachgewiesen. Bei einem Übergangvom Testbetrieb zum Produktionsbetrieb bzw. vom Produktionsbetriebzur Instandhaltung und umgekehrt sollen spezielle Sicher-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 514 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleheitsmaßnahmen ergriffen, um diese Phasen zu trennen und dieSicherheit des Produktionsbetriebs zu gewährleisten. Die folgendenMindestanforderungen SOLLEN eingehalten werden:o Die Hersteller von Geräten oder Programmen MÜSSEN nachweisen,dass sie nach einer bewährten Entwicklungsmethodik arbeiten,die mindestens die folgenden drei (oder zu diesen äquivalente) Stufenumfasst:o Funktionale Spezifikationo Architekturentwurf (oder Grobentwurf)o Feinentwurfo Die sicherheitsrelevanten Komponenten und Schnittstellen, sowiederen Abgrenzung zu nicht sicherheitsrelevanten KomponentenMÜSSEN klar bezeichnet werden. Die in der angewandten Entwicklungsmethodikdefinierten Stufen MÜSSEN zumindest für jede sicherheitsrelevanteKomponente und Schnittstelle ausführlich undnachvollziehbar dokumentiert sein. Die Dokumentation MUSS denzuständigen Stellen zur Prüfung der Sicherheit zur Verfügung gestelltwerden.o Die Entwicklungsunterlagen MÜSSEN während ihrer Erstellung,Speicherung, Übermittlung, Lagerung und Prüfung gegen unbefugtenZugriff und insbesondere gegen unbemerkte Veränderung geschütztwerden.o Die Implementierung MUSS in einer Weise strukturiert erfolgenund dokumentiert werden, dass die im Feinentwurf identifiziertensicherheitsrelevanten Komponenten und Schnittstellen im Gerätoder Programm eindeutig identifizierbar sind.o Software-Implementierungen sind in einer gut dokumentiertenProgrammiersprache durchzuführen. Der dokumentierte Quellcodeist den zuständigen Stellen zur Prüfung zur Verfügung zu stellen.o Die Hersteller von Geräten oder Programmen MÜSSEN nachweisen,dass sie während der gesamten Implementierungs- und Wartungsphasemit einem bewährten Konfigurationskontrollsystem ar-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 515 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03116SP_KEY_PRO_9SKEY_Prozesse_09: Informationsecurity incident managementbeiten.o Die Hersteller MÜSSEN nachweisen, dass bei der Implementierungdie Verantwortlichkeiten und Zugriffsrechte klar definiert sindund die Arbeiten in einer Umgebung und mit Werkzeugen ausgeführtwerden, die eine Kontrolle von Zuständigkeiten und Zugriffsrechtenjederzeit gewährleisten.o Die Hersteller MÜSSEN umfassende Tests der Funktionalität undPrüfungen der Sicherheit durchführen. Insbesondere MUSS nachgewiesenwerden, dass die beabsichtigten Funktionen nicht missbrauchtoder umgangen werden können, und dass nur die beabsichtigtenFunktionen ausgeführt werden können. Die Testdaten undTestergebnisse sind zu dokumentieren und den zuständigen Stellenzur Prüfung zur Verfügung zu stellen.o Die Hersteller MÜSSEN nachweisen, dass sie die notwendigenWartungsarbeiten, den Ersatz und das Update von Komponenten ineiner Weise organisieren und durchführen können, die eine unautorisierteVeränderung der Geräte oder Programme zuverlässig verhindert.o Nachträgliches Herunterladen von Programm-Updates von sicherheitsrelevantenDiensten darf nur nach gegenseitiger kryptographischerAuthentifikation der kommunizierenden Parteien stattfinden.Die Integrität der Programm-Updates MUSS geschützt sein.o Die Hersteller MÜSSEN für alle Komponenten Installationsprozedurendefinieren und ggf. Werkzeuge mitliefern, die gewährleisten,dass die Geräte und Programme auf dem gesamten Weg von derImplementierungs- bis in die Betriebsumgebung durchgehend gegenunbemerkte Manipulationen gesichert sind.Information security incident managementEs ist nicht möglich, ein System vollständig gegen Angriffe abzusichern.Deshalb muss eine wichtige Sicherheitsfunktion, zumindestdas Erkennen von Angriffen und Angriffsversuchen gegen das Systemunterstützen. Mit Hilfe dieser Funktion wird die Analyse der An-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 516 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03117A_03118SP_KEY_PRO_10SP_KEY_PRO_11SSKEY_Prozesse_10: BusinessContinuity Managementgriffe erleichtert. Entsprechend notwendige Alarmbehandlungen undSchadensabwehrmaßnahmen können durchführen werden.Beim Auftreten bestimmter, durch die Beweissicherung erfassterEreignisse wird unverzüglich Sicherheitsalarm ausgelöst und einbestimmter Benutzer / eine bestimmte Rolle benachrichtigt.Es muss im Sicherheitskonzept des Betreibers festgelegt sein, welcheSituationen zu Alarmen führen.Für alle definierten Alarme MUSS folgendes gelten:o Es MUSS festgelegt sein, wer für die Bearbeitung des Alarms zuständigist.o Es MÜSSEN Verfahren existieren, um festzustellen, welcherSchaden angerichtet worden ist. Die dazu notwendigen InformationenMÜSSEN gesammelt und bereitgestellt werden.o Es MUSS festgelegt sein, welche Notfallprozeduren und Abwehrstrategienablaufen sollen. Insbesondere MÜSSEN die maximalenReaktionszeiten, die Informations- und Entscheidungsprozessefestgelegt sein.Es muss mindestens dann ein Alarm ausgelöst werden, wennSchlüssel oder PINs bei der Erzeugung, Verteilung, Speicherungoder im Betrieb kompromittiert wurden. Die gematik MUSS unverzüglichinformiert werden.Business Continuity ManagementEs MÜSSEN Maßnahmen für einen notfallmäßigen Schlüsselwechselvorgesehen werden.KEY_Prozesse_11: Compliance ComplianceDie Einhaltung der rechtlichen Vorgaben, der Sicherheitsrichtliniemuss durch unabhängige Audits geprüft werden. Es MÜSSEN regelwidrigeHandlungen von eigentlich autorisierten Personen zumindestnachträglich entdeckt und nachgewiesen werden können.Dazu ist das Führen von AuditTrails und Log-Aufzeichnungen notwendig.Darin MÜSSEN z. B. Verletzungen von Sicherheitsregeln und Unre-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 517 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellegelmäßigkeiten im System (z. B. unkorrekte Übertragung, mehrfacheInitialisierung von individuellen Systemkomponenten, mehrfacheunkorrekte Eingabe von PINs, wiederholte Meldungen) aufgezeichnetwerden. Diese Aufzeichnungen MÜSSEN so geführt werden,dass es möglich ist, relevante Operationen, die mit sensitivenDaten durchgeführt wurden, und die dabei betroffenen Daten zurekonstruieren. Diese Aufzeichnungen MÜSSEN so ausgewertetwerden, dass sie innerhalb einer akzeptablen Frist zu geeignetenAlarmbehandlungen führen.Es MUSS ein Dienst geschaffen werden, der alle sicherheitsrelevantenAktionen von Benutzern und Anwendungen protokolliert. Hierzugehören u. a.o Anmeldungen von Benutzern am System,o Rollenwechsel,o fehlgeschlagene Authentifikationen undo versuchte unberechtigte Zugriffe auf ObjekteZusätzlich SOLLEN die protokollierten Daten regelmäßig gesichtet,aufbereitet und ausgewertet werden, so dass Lücken im Sicherheitssystem(z. B. Ausnutzung verdeckter Kanäle, etc.) frühzeitigaufgedeckt werden können. Der Zugriff auf Auditdaten MUSS aufeinen kleinen Personenkreis beschränkt bleiben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 518 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang F – KryptographiekonzeptF1 - ZusammenfassungDas übergreifende Kryptographiekonzept der gematik überträgt die Vorgaben des BSI fürempfohlene Algorithmen der eCard Projekte der Bundesregierung [BSI TR-03116] auf diekonkrete Umsetzung der Telematikinfrastruktur im Gesundheitswesen. Es ist auf den Ergebnissender Abstimmungen zwischen BSI und gematik aufgebaut. Diese Abstimmungenspiegeln die gemeinsame Verantwortung von BSI und gematik für die Sicherheit derVerfahren wider.Dieses Dokument legt normativ für einzelne Anwendungsbereiche die zu verwendendenAlgorithmen sowie mindestens einzuhaltende Vorgaben für wesentliche Eigenschaftendes Schlüsselmaterials und der Einsatzumgebung fest. Für die verwendeten Schlüsseltypenwerden in folgenden Punkten normative Mindeststandards festgelegt:• Beschreibung des eingesetzten Schlüsselmaterials• Beschreibung und Mindestanforderungen während des Lebenszyklus des eingesetztenSchlüsselmaterials• Beschreibung, Annahmen und Mindestanforderungen zur Einsatzumgebung• Anforderung an Notfallmaßnahmen• Vorgaben zur Alarmierunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 519 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF1.1 - Zusammenfassung der SicherheitsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_03119SKrypto_Technische_Richtlinie_03116: Verbindlichkeitder TR-03116Die Vorgaben der Technischen Richtlinie 03116 sind verbindlich, es gibtaber in der Regel für jede Grundanwendung mehrere Verfahren zurAuswahl.Ist die Zulassung eines weiteren Verfahrens notwendig, so ist diesdurch die gematik dem BSI mitzuteilen. Nach erfolgreicher Prüfungdurch das BSI wird dann das weitere Verfahren aufgenommenAnhangF 1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 520 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF2 - EinführungIn dieser Einführung wird das Zusammenspiel der Technischen Richtlinie des BSI, demKryptographiekonzept der gematik und den Festlegungen von Algorithmen in den Spezifikationenund Facharchitekturen beschrieben.F2.1 - Verwendung der Technischen Richtlinie TR-03116 des BSIZiel der Technischen Richtlinie [BSI TR-03116] zu Sicherheitsvorgaben für den Einsatzkryptographischer Verfahren der elektronischen Gesundheitskarte, des Heilberufsausweisesund technischer Komponenten der Telematikinfrastruktur des Gesundheitswesens(Sicherheitsvorgaben Kryptokatalog für das Gesundheitswesen) ist:„Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt mit dieserTechnischen Richtlinie eine Bewertung der Sicherheit und eine langfristige Orientierungfür den Einsatz kryptographischer Verfahren der elektronischen Gesundheitskarte,des Heilberufsausweises, der technischen Komponenten und derDienste der Telematikinfrastruktur des Gesundheitswesens.Diese Technische Richtlinie richtet sich an die gematik, den Herstellern von technischenKomponenten und den Herausgebern von eGK, HBA und SMC und istverbindlich bei der Auswahl der kryptographischen Algorithmen.Die in dieser Technischen Richtlinie betrachteten kryptographischen Verfahrenwurden unter Berücksichtigung ihrer Sicherheit und Vertrauenswürdigkeit und desgegenwärtigen Standes der Spezifikationen ausgewählt.“Die Technische Richtlinie 03116 des BSI gibt also eine Auswahl zugelassener Algorithmen,den Einsatzzeitraum der Algorithmen und die maximale Gültigkeitsdauer derSchlüssel für bestimmte Grundanwendungen an. Dabei lehnt sich die Technische Richtliniean die Vorgaben der BNetzA zu Algorithmen bei Signaturen [BNetzA] an.Die Vorgaben der Technischen Richtlinie sind verbindlich, es gibt aber in der Regel fürjede Grundanwendung mehrere Verfahren zur Auswahl.Ist die Zulassung eines weiteren Verfahrens notwendig, so ist dies durch die gematik demBSI mitzuteilen. Nach erfolgreicher Prüfung durch das BSI wird dann das weitere Verfahrenaufgenommen.Die Technische Richtlinie soll jährlich fortgeschrieben werden.F2.2 - Zielsetzung und Einordnung des Kryptographiekonzepts der gematikDieses Dokument legt normativ für einzelne Anwendungsbereiche die zu verwendendenAlgorithmen sowie mindestens einzuhaltende Vorgaben für wesentliche Eigenschaftendes Schlüsselmaterials und der Einsatzumgebung fest. Für die verwendeten Schlüsseltypenwerden in folgenden Punkten normative Mindeststandards festgelegt:• Die Angabe der für die jeweilige Anwendung zugelassenen kryptographischenVerfahren (i. d. R. Auswahl aus BSI TR-03116) sowie Festlegung wesentlicherEigenschaften des Schlüsselmaterials und der Einsatzumgebung. (siehe KapitelF4)• Für die verwendeten Schlüsseltypen werden in folgenden Punkten normativeeinheitliche Mindeststandards festgelegt:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 521 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturo Beschreibung, Rahmenbedingungen und Mindestanforderungen zurEinsatzumgebung (siehe Kapitel F4)ooBeschreibung und einzuhaltende Mindestanforderungen während des Lebenszyklusdes eingesetzten Schlüsselmaterials (siehe Kapitel F6)Anforderung an Notfallmaßnahmen und Vorgaben zur Alarmierung (sieheKapitel F7)o Beschreibung des eingesetzten Schlüsselmaterials (siehe Kapitel F8)Das Kryptographiekonzept als Teil des Sicherheitskonzepts stellt Anforderungen, schreibtaber meist keine konkreten Maßnahmen vor.F2.3 - Spezifikationen und FacharchitekturenIn den Spezifikationen und Facharchitekturen der gematik werden, wo es nötig ist, unterBerücksichtigung des Kryptographiekonzepts, konkret die einzusetzenden Verfahren festgelegt.Dabei muss in allen miteinander kommunizierenden Teilen der TI die Kompatibilitätund Interoperabilität gewahrt bleiben. Zur Gewährleistung des notwendigen Sicherheitsniveaussind die Mindestvorgaben des Kryptographiekonzepts der gematik für dasSchlüsselmaterial und die Einsatzumgebung einzuhalten.F3 - Mindestanforderungen und Rahmenbedingungen für Krypto-AlgorithmenDie Festlegung der Eignung der kryptographischen Algorithmen [BSI TR-03116] hat Auswirkungenauf die nachfolgenden Spezifikationen und Arbeiten der gematik.Migrations- und Releaseplanung - Der zeitliche Horizont des BSI TR-03116 für die Gültigkeitkryptographischer Verfahren ist 6 Jahre und eine jährliche Aktualisierung wirddurchgeführt werden.Bei einer Kartenlaufzeit von 5 Jahren ist nur ein Jahr für Planung, Spezifikation, Test, Zertifizierungund Abnahme und Start der produktiven Nutzung der neuen Verfahren undKomponenten (Karten, Krypto-Komponenten der TI) möglich. Eine erste Zusammenfassungder sich daraus ergebenden Anforderungen ist in Kapitel 7.8 dargestellt.Wesentliche Rahmenbedingungen für die Festlegung der kryptographischen Algorithmensind die Spezifikationen, die Verfügbarkeit und die Migration der existierenden Karten(eGK, HBA/SMC) Folgende Rahmenbedingungen und Zielplanung sind bei der Festlegungder Krypto-Algorithmen für die Telematikinfrastruktur zu berücksichtigen:• Von der Festlegung der Spezifikation bis zur Verfügbarkeit der eGk werden 18Monate veranschlagt.Bis Ende 2008 können eGk der aktuellen Spezifikation für die Testvorhabenausgegeben werden, Diese Karten müssen nach Ablauf der Übergangsfrist fürdie Testvorhaben eingezogen werden,Ab Mitte 2008 müssen eGk der Generation 1 gemäß der Spezifikation Version2.0 ausgegeben werdenBei der Festlegung für die eGK ergeben sich Abhängigkeiten für die Heilberufsausweise:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 522 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Das Konzept wird mit den Herausgebern der HBA abgestimmt.Ziel muss es sein, abgestimmte Versionen von eGK und HBA im Feld zu haben,wobei idealerweise die Ausgabe einer neuen HBA-Generation einen geeignetenVorlauf vor der nächsten eGK-Generation haben sollte.F3.1 - Betrachtungszeitraum der Technischen Richtlinie TR-03116 des BSIDer zeitliche Horizont des BSI TR-03116 für die Gültigkeit kryptographischer Algorithmenund Verfahren ist 6 Jahre und eine jährliche Aktualisierung wird durchgeführt werden. Beiden symmetrischen und asymmetrischen Verschlüsselungsverfahren für Dokumente wirdein Zeitraum von 10 Jahren noch ausreichend gesichert sein.„Abgesehen von unvorhergesehenen kryptographischen Durchbrüchen, die nichtvollkommen ausgeschlossen werden können aber unwahrscheinlich sind, lassensich über einen Zeitraum von ca. 6 Jahren relativ verlässliche Aussagen machen.“„Die langfristige Vertraulichkeit verschlüsselter Daten wirft grundsätzliche Problemeauf. Bei Verwendung der bis Ende 2013 als geeignet eingestuften Verfahrenzur Schlüsseleinigung und zur symmetrischen bzw. asymmetrischen Verschlüsselungdürfte die Vertraulichkeit der verschlüsselten Daten nach Einschätzung desBSI im Zeitraum von ca. 10 Jahren (bis Ende 2017) noch ausreichend gesichertsein. Diese Einschätzung ist allerdings schon mit einem höheren Maß an Spekulationverbunden als die Aussagen über 6 Jahre und daher weniger belastbar. Aussagenzur Sicherheit über mehr als ein Jahrzehnt sind dagegen kaum möglich.“(BSI TR-03116)Jeder in der Telematikinfrastruktur verwendete kryptographische Algorithmus muss daherinnerhalb von 6 Jahren vollständig gewechselt werden können (siehe AS-Krypt-MOD-01).Die Sicherheitsfunktionen und Krypto-Algorithmen auf Anwendungsebene (sieheAbbildung 33: Verwendung der Sicherheitsdienste und Sicherheitsfunktionen auf Anwendungsebene)stellen die Sicherheit der medizinischen Daten eines Versicherten sicherund sind daher wesentlich von dieser einzuhaltenden Anforderung betroffen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 523 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPrimärsysteme•PVS, AVS, KISaktive Patiententerm.PC-Term., SB-Term.•Versicherter@homeAnwendungsKonnektor•Nutzung•Anw. des Vers.•Rechte-Mgmt.Anwendungsgateway•Audit für Nicht-AbstreitbarkeitAnonymisierung,•Anwendungsverwaltung•§291a Fachdienste (Pflicht &Freiwillig)• VSDM, VODM, Notfalldaten, AMTS,• Patientenfach, Patientenquittung• Arztbrief, ePatientenakteMehrwertdiensteSicherheitsdienste (fachdienstbezogen)• Authentisierung, Autorisierung• RechteverwaltungPrimärsystemAnwendungs-KonnektorBrokerFachdienstListeAnwendungListeElementReq./Res.SOAP Req./Res.CRUDLSmed.DateneGKHBASMCAudit,SAK,ver/entschlüsselnKryptofunktionenSchlüsselAudit,TSSVS, SCS, SAKKryptofunktionenSchlüsselIn 6 Jahren zu migrierende Komponenten und DiensteAuth., Autor.SAK, …..KryptofunktionenSchlüsselIdentitätenRechte,TicketsAbbildung 33: Verwendung der Sicherheitsdienste und Sicherheitsfunktionen auf AnwendungsebeneIn den folgenden allgemeinen Migrationsbetrachtungen wird davon ausgegangen, dassvom Ablauf eines Krypto-Algorithmus in der Regel alle in Abbildung 33: Verwendung derSicherheitsdienste und Sicherheitsfunktionen auf Anwendungsebene dargestellten Komponentender Sicherheitsarchitektur betroffen sind.Bei einer Kartenlaufzeit von 5 Jahren für die eGK ist nur ein Jahr für Planung, Spezifikation,Test, Zertifizierung, Abnahme und Start der produktiven Nutzung der neuen Verfahrenin den betroffenen Komponenten (eGK, Krypto-Komponenten der TI) möglich (siehe AS-Krypt-MOD-05).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 524 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturMigrationsplanung für Änderung kryptographischer VerfahrenAktivitätenRealisierung krypt. VerfahrenInitialisierung, PlanungSpezifikationImplementierungTest, Evaluierung und ZulassungBetriebsübernahme (dez., zen.)Produktionstests und FreigabeRealisierungneuesVerfahrenJahr 1Jahr 2Koexistenz beider VerfahrenJahr 3Jahr 4Jahr 5Jahr 6AblösungaltesVerfahrenJahr 7Q2 Q1Q3 Q2Q3 Q4 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1Q2 Q3 Q4 Q1Q2 Q3 Q4Q1 Q2 Q3 Q4Ausgabe eGK (neues Verfahren)Ausgabe eGK (altes Verfahren)eGKs mit verkürzter LaufzeitKartenlaufzeit5 Jahre4 JahreAblauf eGK (altes Verfahren)Außerbetriebnahme SchlüsselEntfernen AlgorithmusAbstimmung & KoordiniationAbbildung 34: Migrationsplanung bei Änderung von Krypto-Algorithmen der eGK.Für die Realisierung des neuen kryptographischen Verfahrens sind innerhalb eines Jahresdie folgenden Aktivitäten durchzuführen:Spezifikation der betroffenen Krypto-Komponenten - eGK, HBA, SMC, Konnektor (SAK,ENC), Broker (SVS, SCS, SAK, HSM), Fachdienste (Auth., Autor., SAK, HSM)Test, Evaluierung und Zulassung Bei einem Zeitraum von 3 Monaten für denTest und die Evaluierung der Krypto-Komponenten wird davon ausgegangen, dass einverkürztes Verfahren verwendet werden kann. Die zu betrachtenden Änderungen sind aufdie Krypto-Komponenten beschränkt und eine vollständige Evaluierung der betroffenenKomponenten und Dienste (z. B. des Konnektors, der Fachdienste und des TrustedServicedes Brokers) ist nicht notwendig. Interoperable Dienstschnittstellen der TelematikinfrastrukturDÜRFEN von einer Änderung eines Krypto-Algorithmus NICHT geändertwerden.Übernahme in den Betrieb in den dezentralen und zentralen Komponenten der TIUpdate der Krypto-Funktionen aller Konnektoren und Fachdienste.Bei einem Zeitraum von 3 Monaten für die Übernahme der zugelassenen Krypto-Komponenten in den Wirkbetrieb wird davon ausgegangen, dass automatisierte Verfahrenbei den dezentralen Komponenten (z. B. Konnektor) verwendet werden können. Ein sichererUpdate der Krypto-Module MUSS daher in der Grundfunktionalität des Konnektorsvorhanden und evaluiert sein. Bei einem lokalen Verfahren zum Update der dezentralenKomponenten in der TI kann vermutlich ein Zeitraum von 3 Monaten nicht eingehaltenwerden.Die zentralen Komponenten der TI und die Fachdienste von den Betreibern MÜSSEN imRahmen eines Changes alle umgestellt werden. Die spezifischen Sicherheitskonzepte derBetreiber MÜSSEN die Umstellungsprozesse beschreiben und die Wirksamkeit der getroffenenMaßnahmen ist nachzuweisen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 525 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturProduktionstests und Freigabe des neuen Verfahren und der Kartenproduktion eGKFür die Produktionsfreigabe der eGK mit dem neuen Verfahren sind folgende Voraussetzungenerforderlich:Die eGK mit dem neuen Verfahren wird an allen dezentralen Komponenten der TI erkanntund kann ohne Einschränkung der Funktionalität verwendet werden.Alle zentralen Komponenten der Telematikinfrastruktur können das neue Verfahren parallelzum alten Verfahren verarbeiten.Die Umstellung aller betroffener Daten und gespeicherter Informationsobjekte in der Telematikinfrastrukturvom alten auf das neue Verfahren ist getestet und die korrekte Funktionsfähigkeitder Produktionsschlüssel MUSS gezeigt sein.In Anbetracht der notwendigen Zeiten für die Realisierung, Evaluierung und Freigabe derKomponenten sowie der Komplexität des Betriebsübernahme (das neue Verfahren MUSSin allen Konnektoren sowie in allen Fachdiensten verfügbar und verwendbar sein) wirdeine Verkürzung der Laufzeiten der auszugebenden eGK (altes Verfahren) in einem Ü-bergangszeitraum von einem Jahr zu erwarten sein (siehe AS-Krypt-MOD-06).Tabelle 48: Abgeleitete Anforderungen aus BSI TR-03116 für die Migration kryptographischerVerfahren in der TelematikinfrastrukturAnforderungsnr.AS-Krypt-MOD-01BeschreibungMigration kryptographischer Komponenten und Sicherheitsdienste:(siehe [BSI TR-03116], AS-Krypt-01, AS-Krypt-02, AS-Krypt-03,AS-Krypt-05)Jeder in der Telematikinfrastruktur verwendete kryptographischeAlgorithmus MUSS innerhalb von 6 Jahren planmäßig vollständiggewechselt werden können.Konsequenzen:AS-Krypt-MOD-02AS-Krypt-MOD-03AS-Krypt-MOD-04AS-Krypt-MOD-05Alle Schlüssel der TI SOLLEN eine maximale Gültigkeitsdauer von6 Jahren NICHT überschreiten.Die aktive Schlüsselgültigkeitsdauer aller noch ausgegebenenSchlüssel eines abzulösenden Verfahrens in der TelematikinfrastrukturDÜRFEN das festgelegte Ende des Krypto-Verfahrens NICHT überschreiten.Nach einem Jahr MÜSSEN eGK mit den neuen Algorithmen flächendeckendin der TI akzeptiert werden. Daher MÜSSEN die betroffenenKrypto-Komponenten in den dezentralen und zentralenDiensten der Telematikinfrastruktur spätestens nach einem Jahrdie neuen Verfahren im produktiven Betrieb unterstützen.Begründung: Bei einer Kartenlaufzeit von 5 Jahren für die eGK istnur ein Jahr für Planung, Spezifikation, Test, Zertifizierung, Abnahmeund Start der produktiven Nutzung der neuen Verfahren inden betroffenen Komponenten – u. A. Karten, Krypto-Komponenten der TI - möglich.Nach einem Jahr SOLLEN die ersten eGK mit den neuen Algorithmenausgegeben werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 526 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAS-Krypt-MOD-06AS-Krypt-MOD-07AS- Krypt-MOD-08AS- Krypt-MOD-09Falls nach einem Jahr noch eGK mit dem alten Verfahren ausgegebenwerden, MUSS die Lebensdauer dieser Karten entsprechendverkürzt werden.Über eine Zeitraum von 5 Jahren MÜSSEN abzulösende und neueAlgorithmen parallel in den betroffenen Krypto-Komponenten derTelematikinfrastruktur unterstützt werden.Nach 5 Jahren sind die letzten eGK mit dem abzulösenden Verfahrenungültig und die Verwendung des abgelösten kryptographischenAlgorithmus in der Telematikinfrastruktur wird ausgeschlossen,indem sofort nach Ablauf des Gültigkeitszeitraums des Verfahrensalle Schlüssel zu diesem Verfahren aus dem produktivenSystemen entfernt werden und damit die Nutzung der Schlüsselnicht mehr möglich ist.Danach SOLLEN die Algorithmen aus den KryptographischenKomponenten entfernt werden und durch die Sicherheitsdiensteder Telematikinfrastruktur nicht mehr angesprochen werden können.Bei Nutzungsversuchen des abgelaufenen AlgorithmusMÜSSEN entsprechende Alarme erzeugt werden.Wesentliche Anforderungen an die Dienste und Komponenten ergeben sich aus dem Zeitraumvon einem Jahr für die produktive Bereitstellung des neuen Verfahrens in allenKomponenten und Diensten der TI.Tabelle 49: Anforderungen an die Migrationsfähigkeit der Krypto-Komponenten und Sicherheitsdienste.Anforderungsnr.AS-Krypt-MOD-10BeschreibungNach einem Jahr MÜSSEN eGK mit den neuen Algorithmen flächendeckendin der TI akzeptiert werden. Daher MÜSSEN die betroffenenKrypto-Komponenten in den dezentralen und zentralenDiensten der Telematikinfrastruktur spätestens nach einem Jahrdie neuen Verfahren im produktiven Betrieb unterstützen.Konsequenzen:AS-Krypt-MOD-1001 Separation: Die interoperablen Schnittstellen der TI sind so gestaltet,dass sich eine Änderung der Krypto-Algorithmen nur auf dieKrypto-Provider und Krypto-Module beschränkt. Eine Änderungder interoperablen Dienstschnittstellen ist nicht notwendig.Hinweis: Die Abgrenzung der Sicherheitsdienste und Verwendungkonkreter Krypto-Algorithmen von der Anwendungsfunktionalität istdie zwingende Grundvoraussetzung für die Migration. Wenn nochzusätzlich Anwendungsfunktionalität betroffen ist, dann ist eineÄnderung im vorgegebenen Zeitraum nicht mehr möglich.AS-Krypt-MOD-1002 Evaluierung: Bei einem Zeitraum von 3 Monaten für den Test unddie Evaluierung der Krypto-Komponenten wird davon ausgegangen,dass ein verkürztes Verfahren verwendet werden kann. Diezu betrachtenden Änderungen sind auf die Krypto-Komponentenbeschränkt und eine vollständige Evaluierung der betroffenenKomponenten und Dienste (z. B. des Konnektors, der Fachdienstegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 527 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturund des TrustedService des Brokers) ist nicht notwendig.AS-Krypt-MOD-1003 Automatisierter Update dezentraler Komponenten: AutomatisierteVerfahren SOLLEN bei den dezentralen Komponenten (z. B.Konnektor) verwendet werden.Hinweis: Bei einem lokalen Verfahren zum Update der dezentralenKomponenten in der TI kann vermutlich ein Zeitraum von 3 Monatennicht eingehalten werdenAS-Krypt-MOD-1004 Der Update zentrale Komponenten ist im Sicherheitskonzeptdes Betreibers zu beschreiben: Die zentralen Komponenten derTI und die Fachdienste von den Betreibern MÜSSEN im Rahmeneines Changes innerhalb von 3 Monaten umgestellt werden. Diespezifischen Sicherheitskonzepte der Betreiber MÜSSEN die Umstellungsprozessebeschreiben und die Wirksamkeit der getroffenenMaßnahmen ist nachzuweisen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 528 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF3.2 - Umsetzungsprobleme mit der TR-03116Bestimmte Anforderungen aus dem Kryptokatalog TR-03116 sind mit den derzeit spezifiziertenund am Markt befindlichen Produkten nicht oder nur sehr schwer umsetzbar.Dies wird in den nachfolgenden Unterkapiteln dargestellt.F3.2.1 - CV-Authentifizierung: Konflikte mit der eGK SpezifikationFür den Schlüssel der CV-Root wird in der TR-03116 bei RSA prinzipiell 2048 BIT gefordert.Damit muss jede Karte, die eine CV-Authentifizierung durchführt also eGK, HBA, SMC-B,2048-BIT RSA können.• Nicht alle zugelassene Karten können 2048 BIT- CV-Authentifikation• In der eGK-Spec Teil 1 Stand Sommer 2007 wird nur 1024 Bit für CVC verlangt.Für die Signatur des CV-Zertifikats von CV-CA-Zertifikaten ist eine Hashfunktion nötig.Hier gilt „Hashfunktionen zum Signieren von CV-Zertifikaten: SHA-1, RIPEMD-160: bisEnde 2009, (bzw. 2010); SHA-224, SHA-256, SHA-384, SHA-512: bis Ende 2013“. D.h.Karten, die in der CV-Authentifikation nur SHA-1 anwenden, sind bis Ende 2009 auszutauschen.Nach der eGK-Spec wird die CV-Root durch ein Zertifikat in die eGK eingebrachtnicht nur durch den öffentlichen Schlüssel.Da das Zertifikat der CV-Root länger als 2009 gelten muss, muss für die Signatur desZertifikats eine Hashfunktion aus der SHA-2 Familie benutzt werden.• Nicht alle zugelassene Karten können Hashfunktion aus der SHA-2 Familie• In der eGK-Spec Teil 1 (Seite 29) wird nur SHA-1 verlangt.F3.2.2 - Technische Schwierigkeiten mit SHA-2 im Zusammenhang mit XML StandardsXML Standard: Die Verwendung von SHA-2 ist im XML-DSIG Standard nicht vorgesehenund es besteht aus diesem Grund auch keine normierte Kennzeichnung (wie z. B.http://www.w3.org/2000/09/xmldsig#rsa-SHA-1 für eine RSA SHA-1 Signatur). Neben dertechnischen Verfügbarkeit des Algorithmus müsste also auch noch eine herstellerübergreifendeNamenskonvention bestehen. Gemäß RFC 4051 soll der Algorithmus alshttp://www.w3.org/2001/04/xmldsig-more#rsa-SHA-256 bezeichnet werden, es ist abernicht bekannt wer diese Nomenklatur auch wirklich nutzt..NET: Die Verwendung von SHA-2 ist unter Microsoft WCF oder anderen .NET Technologienohne die Verwendung zusätzlicher Bibliotheken nicht möglich. Diese Aussage wurdedurch Microsoft bestätigt. Das bezieht sich sowohl auf SHA-2 Zertifikate als auch aufSHA-2 Signaturen.Die Aussagen von MS zum zeitlichen Rahmen sind an dieser Stelle nicht belastbar, aberes kann davon ausgegangen werden, dass die Verwendung SHA-2 Signaturen frühestensEnde dieses Jahres (2007) zur Verfügung stehen und SHA-2 Zertifikate frühestens Mittenächsten Jahres (2008)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 529 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturJAVA: Seit JDK 1.4.2 unterstützt der eingebaute „SUN“-Provider den Algorithmus SHA-256 prinzipiell. Aussage von SUN zur Sun-Implementierung im Rahmen von ProjektGlassFish: “GlassFish unterstützt – obwohl nur noch 1% dazu fehlt – SHA-256 als MessageDigestaktuell (noch) nicht –eine interne Anfrage wurde gestartet“Die Apache XML-Security-Implementierung in Version 1.4 unterstützt SHA-256.Die bekannten Java Implementierungen sind von der Nomenklatur her allerdings nicht zuRFC 4051 konform und verwenden den Identifier für eine SHA-1 Signatur.F3.2.3 - Konflikte mit Schlüssellänge und Hashalgorithmus für IPSec ZertifikateDie derzeitigen Vorgaben für Hashalgorithmen gemäß [BSI TR-03116] erlauben den Einsatzvon SHA-1 in Verbindung mit der Zertifikatssignatur nur noch für Zertifikate, derenGültigkeit noch im Jahre 2007 endet. Zusätzlich bestehen für die kommenden Jahre steigendeAnforderungen an die zulässigen Schlüssellängen.Dabei ist folgendes zu beachten:• Die derzeitigen am Markt verfügbaren VPN-Konzentratoren verwenden alleSHA-1.• Schlüssellängen über 1024 Bit könnten den Austausch der Zugangskomponentenbei Mehrkomponentenkonnektoren erzwingen.• Die Konnektoren müssen im ersten Jahr mit SHA-1 und danach mit SHA-256arbeiten.F3.2.4 - Konflikte mit Schlüssellänge und Hashalgorithmus für TLS(SSLZertifikate)Die derzeitigen Vorgaben für Hashalgorithmen gemäß [BSI TR-03116] erlauben den Einsatzvon SHA-1 in Verbindung mit der Zertifikatssignatur nur noch für Zertifikate derenGültigkeit noch im Jahre 2007 endet. Zusätzlich bestehen für die kommenden Jahre steigendeAnforderungen an die zulässigen Schlüssellängen.Dabei ist folgendes zu beachten:• Die derzeitigen am Markt verfügbaren HSMs für den Broker verwenden alleSHA-1.• Schlüssellängen über 1024 Bit sind für diese HSMs nicht sehr performant.F3.2.5 - Fehlende VerfahrenDiffie Hellman Gruppen Diffie Hellman Gruppen für IPsec-Zwecke sind in der TR-03116 nicht vorgesehen: Im GA-Algorithmen-Dokument steht aber: Die Verwendung vonDiffie-Hellman Gruppen für den Schlüsseltausch gemäß Tabelle 50: Diffie Hellman Gruppenfür den Schlüsseltausch ist verpflichtend.Tabelle 50: Diffie Hellman Gruppen für den SchlüsseltauschAlgorithmen Typ Diffie Hellman Gruppe 2007 2008 2009 2010 2011 2012 2013Diffie Hellman Gruppe5 M M M E E E E14 O O M M M M MGruppen auf Basis Elliptischer Kur- P P P P P P Pgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 530 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturvenHashfunktion MD5 Zur Absicherung der DNS Daten wird gemäß [gemNamD] die Verwendungvon DNSSEC verwendet. Bei zwei Verfahren in [gem_Spec_Krypt] wird HMACMD5 verwendet. Die Hashfunktion MD5 ist in der TR-03116 nicht vorgesehen und kaumgenehmigungsfähig.• Es ist nicht vorgesehen im Rahmen dieses Projekts DNSSEC zu überarbeiten.F3.2.6 – Unterschiedliche Gültigkeitszeiträume für Signaturen für Dokumente oder für AuthentikationenDie Ablaufdaten der Schlüssellängen für qualifizierte Signaturen und der Authentisierungsind vom TR-03116 gleich festgelegt worden. Ebenso werden an die Dokumentenverschlüsselungmedizinischer Daten und der Sessionverschlüsselung gleiche Maßstäbeangelegt.Anwendung Card-to-Card AuthentisierungRSA:bis Ende 2007: 1024 BitSignaturalgorithmen –DokumenteRSA:bis Ende 2007: 1024 Bitbis Ende 2008: 1280 Bitbis Ende 2009: 1536 Bitbis Ende 2010: 1728 Bitbis Ende 2013: 1976 Bitbis Ende 2013: 1976 Bitempfohlen2048 BitDSA:DSA:bis Ende 2007:p: 1024Bit, q: 160Bitbis Ende 2007: p: 1024Bit, q: 160Bitbis Ende 2008: p: 1280Bit, q: 160Bitbis Ende 2009: p: 1536Bit, q: 160Bitbis Ende 2013:p: 2048 Bit, q: 224Bitbis Ende 2013: p: 2048Bit, q: 224BitECDSA:bis Ende 2007: q: 160 BitECDSAbis Ende 2007: q: 160 Bitbis Ende 2009: q: 180 Bit, p 192 Bitbis Ende 2013: q: 224 Bitbis Ende 2013: q: 224 Bitgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 531 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturCV-Zertifikate (RSA):Für Karten, die nach 2010 ausgegebenwerden und deren Gültigkeit über 2013hinausreicht wird eine Schlüssellänge von2048 Bit empfohlen.Session Verschlüsselung (C2S, C2C)Verschlüsselung 2TDES CBC mitzufälligem Initialisierungsvektor bisEnde 2009.Verschlüsselung DokumenteAsymmetrische Verschlüsselung desDokumentenschlüsselsRSA:bis Ende 2007: 1024 BitVerschlüsselung 3TDES CBC oderAES-128 CBC oder AES-192 CBCoder AES-256 CBC mit zufälligemInitialisierungsvektor bis Ende 2013.bis Ende 2013: 2048 BitVerschlüsselung der Dokumentendaten:AES-256 CBC mit zufälligem Initialisierungsvektorbis Ende 2013Die zeitlichen Anforderungen für Signaturen zur Authentisierung in der TI oder für Signaturenfür Dokumente nach SigG sind sehr unterschiedlich. Die Gültigkeit einer Signaturzur Authentisierung in der TI wird augenblicklich entschieden und bedarf (aus dem Loggingwie für alle Aktionen) keiner weiteren Dokumentation.Maximale Lebensdauersignierter DokumenteAblaufdatumdesSignatur-AlgorithmusDokumentensignaturfortgeschritten,qualifiziertNutzung privater SchlüsselNutzung ZertifikatPrüfung DokumentensignaturErgänzendeVerfahrenZeitstempelNachsignierenAuthentisierungC2C, C2SXML-NachrichtenNutzung privater SchlüsselNutzung ZertifikatKeineNachnutzungZeitAnsteigen der CPU Leistunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 532 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 35: Nutzung eines Algorithmus für Dokumentensignatur und AuthentisierungDie Gültigkeit der Signaturen für Dokumente muss u. U. lebenslang überprüfbar bleiben.Daher sollten die Signaturen für Nachrichtenauthentisierung anders als die Dokumentsignaturenbetrachtet werden.Festlegung der Gültigkeit für Authentisierungsverfahren RSA-1024:Für Authentisierungsverfahren (XML-Nachrichtensignaturen, C2C, C2S) können die kryptographischenAlgorithmen bis zum Ablauf der Gültigkeit der Prüfung der qualifiziertenSignatur ohne ergänzende Verfahren eingesetzt werden.F3.2.7 – Verschlüsselung und Signatur langfristig gespeicherter medizinischer DokumenteEs wird von einer maximalen Nutzungsdauer von 6 Jahren qualifiziert signierter Dokumenteausgegangen, bevor ergänzende Verfahren wie Zeitstempel oder Nachsignierennotwendig werden. Derartige ergänzende Verfahren für qualifiziert signierte Dokumentesind in der Telematikinfrastruktur derzeit nicht vorgesehen.Die langfristige Gültigkeit qualifiziert signierter und in der Telematikinfrastruktur gespeichertermedizinischer Dokumente ist derzeit nicht gegeben. Spätestens wenn bestimmteAlgorithmen nicht mehr benutzt werden dürfen, kann diese Signatur im Rahmen der TInicht mehr geprüft werden.Hinweis: Die in Release 1 betrachteten medizinischen Verordnungen sind aufgrund derbeschränkten zeitlichen Gültigkeit nicht von dieser Anforderung betroffenEs ist davon auszugehen, dass die Lebensdauer mancher signierter Dokumente länger istals die Nutzungsdauer des asymmetrischen Verfahrens. Zur Verifikation der Signaturmuss für einen definierten Zeitraum weiter das Zertifikat zur Verfügung stehen. Ist dasVerfahren auch dafür zu unsicher geworden, müssen ergänzende Maßnahmen getroffenwerden (Zeitstempeln, Nachsignieren mit anderen Verfahren…)Ergänzende Verfahren für die qualifizierte Signatur langfristig gespeicherter Dokumente freiwilliger Anwendungen in derTelematikinfrastruktur:Derzeit sind keine ergänzenden Verfahren für die qualifizierte Signatur gespeicherter Dokumente freiwilliger Anwendungenvorgesehen in der Telematikinfrastruktur. Diese Speicherdauern können die maximale Eignungsdauer der Nutzung derAlgorithmen übersteigen. Die Signaturen werden in der Telematikinfrastruktur in dem für den Versicherten/Berechtigtenverschlüsselten Teil gespeichert und eine für die Benutzer prüfbare Möglichkeit zum Einsatz ergänzender Verfahren ist nurbei Umschlüsseln bei Ablauf der Schlüsseleignung bzw. der Algorithmeneignung der Verschlüsselungsschlüssel der medizinischenDokumente möglich.Da die medizinischen Dokumente in der Telematikinfrastruktur immer verschlüsselt abgelegt werden und die Gültigkeit derSignatur immer bei der Übergabe an den Versicherten und dem Einstellen in die TI geprüft wird, werden derartige ergänzendeVerfahren für die langfristige Nutzbarkeit der medizinischen Dokumente in der Telematikinfrastruktur derzeit jedochnicht für notwendig gehalten.Hinweis: Die in Release 1 betrachteten medizinischen Verordnungen sind aufgrund der beschränkten zeitlichen Gültigkeitnicht von dieser Anforderung betroffen.Hinweis: Die Notwendigkeit ergibt sich schon aus AS-Krypt-06 Übersteigt die Lebensdauer kryptographisch behandelterDaten die Dauer der Sicherheitseignung der eingesetzten Algorithmen und Parameter so MÜSSEN die Daten vordem Ablauf der Sicherheitseignung durch eine erneute Verschlüsselung bzw. Nachsignatur entsprechend geschützt werden.Diese Verfahren könnten jedoch beim Umschlüsseln bei Ablauf der Schlüsseleignung bzw. der Algorithmeneignungder Verschlüsselungsschlüssel in die Architektur der Telematikinfrastruktur integriert werden und im Rahmen des Datenerhaltsmit betrachtet werden, denn auch die Erhaltung wichtiger Dokumenteneigenschaften (Nachweisbarkeit des Urhebers)sollte im Zusammenhang der weiteren Nutzung der medizinischen Anwendungen betrachtet werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 533 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF3.2.8 - Symmetrische Card-to-Server Authentisierung. CAMS oder VSDDZulässigkeit der symmetrischen Verfahren zur Authentisierung: 2TDES: bis Ende 2009,3TDES: bis Ende 2013Eine Migration 2TDES für C2S Authentifizierung ist notwendig bis 2010.Da 2TDES zurzeit verwendet wird, ist auch hier eine Migration notwendig.F3.3 - Ergebnis der Abstimmung zwischen BMG, BSI und gematikDie Technische Richtlinie TR-03116 wird weiter Voraussagen nur für 6 Jahre machen undvom BSI jährlich angepasst werden. Die gematik muss und wird aber in längeren Zeiträumenplanen. Dabei wird sie vom BSI unterstützt, das signalisiert, bei welchen Verfahrendas BSI zum Zeitpunkt der Planung in den über 6 Jahres-Horizont hinausgehendenZeiträumen keine Schwierigkeiten erwartet.Das BSI stuft 1024 Bit RSA und 2TDES (Triple-DES mit 112 Bit langem Schlüssel) nichtmehr als sicher genug ein, um im Wirkbetrieb mit großen Mengen von Patientendateneingesetzt zu werden. Für die verschiedenen räumlich und zeitlich begrenzten Tests werdendiese Verfahren aber noch als sicher genug angesehen.Daher ist bis zum Ende des zweiten Quartals 2008 auf RSA in der Größenordnung von2048 Bit und symmetrische Verschlüsselung auf 3TDES (Triple-DES mit 168 Bit langemSchlüssel) zu migrieren. Eine entsprechende Generationenfolge ist auch für HBA undSMC vorzusehen. Laufzeiten der eGKs von derzeit maximal 5 Jahren sind zu berücksichtigen.Durch diese Erhöhung der Schlüssellängen Mitte 2008 werden die eGK der Generation1 bis Anfang 2016 im Wirkbetrieb verwendet werden. Diese Algorithmen werdenvom BSI bis 2013 als sicher angesehen - das BSI sieht zurzeit jedoch keine Hemmnisse,dass diese Algorithmen nicht bis Anfang 2016 eingesetzt werden könnten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 534 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTest-, eGK-Generation 1SpezifikationeGK Generation 2HBA/SMC Generation 2Bereiche20072008Q2 Q1Q3 Q2Q3 Q4 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1 Q2Q3 Q4 Q1Q2 Q3 Q4XML DokumenteSignatur (qual., fortgeschritten) RSA-1024 RSA-1280 RSA-1536 RSA-1728 RSA-1976//2048Verschlüsselung (Dokumente) AES-256AES-256Verschlüsselung (Schlüssel) RSA-1024 RSA-2048 ECC-256 .PKI(CAs, TSL) RSA-1024 RSA-2048 ECC-256 .20092010201120122013XML NachrichtenAuthentisierungRSA-1024 RSA-2048 ECC-256 .C2C AuthentisierungIdentität (CV-Schlüssel)PKI(CV-Zertifikate)CVC root (Root, ….)C2S AuthentisierungIdentitätenVerschlüsselung (TC)RSA-1024 RSA-2048 ECC-256 .RSA-1024 RSA-2048 ECC-256 .RSA-1024 RSA-2048 ECC-256 .2TDES 3TDES AES-1282TDES 3TDES AES-128Abbildung 36: Kryptographische Algorithmen in der TelematikinfrastrukturDamit sind, wie inAbbildung 36: Kryptographische Algorithmen in der Telematikinfrastruktur), und Abbildung37: Migrationsplanung der Kartengenerationen und der zugehörigen Algorithmen. dargestellt,drei Generationen von eGK derzeit langfristig für den Einsatz bis 2020 vorgesehen:• Generation Testkarten– eGK Version 1.2 für die Testvorhaben• eGK Generation 1 – eGK Version 2.X für den Beginn des Rollouts und ErstePhase Wirkbetrieb• eGK Generation 2 - Migration auf Elliptische Kurven ECC im Wirkbetrieb.In der Migrationsplanung muss der notwendige Vorlauf der HBA/SMC vor der Einführungder eGK der Generation 2 in 2011 vorgesehen und von Kartenherausgebern und Trustcenternumsetzbar sein. Der Übergang auf Verfahren mit Elliptischen Kurven ist daherfrühestens für den Jahreswechsel 2010/2011 geplant. Details (u. A. die Kurvengröße,geplant sind 256 Bit) müssen dazu noch festgelegt werden. Weitere Kartengenerationen(2+) sind dann durch eine Vergrößerung der Schlüssellänge innerhalb eines Kryptoalgorithmuszu späteren Zeitpunkten (eGK ab 2016) möglich.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 535 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKartengenerationen undAlgorithmenGesundheitskarten• eGK – Generation 1• eGK – Generation 2• eGK – Generation 2+Heilberufsausweise (HBA/SMC)• HBA Gen.1 interop. eGK Gen1• HBA Gen.2 interop. eGK G1&G2, SMC G1• HBA Gen.2+Algorithmen für Authentisierung• RSA 1024/2048, SHA-1 für C2C; 2/3TDESfür C2S; CVC-root RSA-1024/2048,• ECC 256 für C2C, CVCmit CVC –Root ECC• ECC xxx für C2C, CVCmit CVC –Root ECC xxxNotfall und Ersatzverfahren• Krypto-AlgorithmenHash-Verfahren.Generation 1 Generation 22007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019SpezifikationZulassungEnde AusgabeEnde AusgabeErstausgabeErstausgabeEnde LaufzeitSpezifikationErstausgabeZulassungRSA 1024/2048SHA-2562/3TDESEnde LaufzeitEnde AusgabeSpezifikationErstausgabeZulassungEnde AusgabeECC-256SHA-256Ende LaufzeitKeine Ersatzverfahren vorgesehenErsatzverfahren ist festzulegenGeneration 2+ECC-xxxSHA-xxx2020Ende LaufzeitEnde LaufzeitEnde AusgabeAbbildung 37: Migrationsplanung der Kartengenerationen und der zugehörigen Algorithmen.Für die Verschlüsselung auf Netzwerkebene (VPN) werden vom BSI langfristig geeignetekryptographische Algorithmen festgelegt. Die IPSEC-Kommunikation zwischen Konnektorund VPN-Konzentrator und die TLS-Kommunikation zwischen dem Konnektor und Brokerdürfen nur langfristig geeignete Kryptoalgorithmen gemäß Kapitel 3 verwenden. Derzeitigverfügbare Standardprodukte unterstützen diese Algorithmen nur in sehr beschränktemMaße. Zudem ist durch die Verwendung langfristig geeigneter Algorithmen auf Anwendungsebeneein starker Schutz der Vertraulichkeit, der Integrität und der Authentizität derübertragenen Daten vorhanden, so dass die gematik hier nur von einem mittleren Schutzbedarfder übertragenen Daten ausgeht.Die genaue Verwendung der Mechanismen auf Netzwerkebene und der Schutzbedarf der Daten sind noch von der gematikdarzustellen, damit das BSI dann die notwendigen Beurteilungen durchführen kann. Es wird jedoch kein grundsätzlichesProblem gesehen. Die derzeitigen Festlegungen auf Netzwerkebene im [BSI TR-03116] gehen von ansonsten ungeschütztenübertragenen Daten aus.Wesentlich für den Schutz der medizinischen Daten in der Telematikinfrastruktur sind dieSchlüssel zum Schutz der Daten auf Anwendungsebene (siehe Kapitel F4.1). Aufgrundder gestuften Sicherheitszonen der Telematikinfrastruktur (siehe AS_EP_06) wird eineUnabhängigkeit der Anwendungssicherheit von den Schlüsseln der darunter liegendenSchichten der Transport- und Netzwerkschicht (siehe Kapitel F4.2) erreicht. Diese Abstufungenwerden bei der Festlegungen der Kryptoalgorithmen und Schlüssellängen berücksichtigtund durch die Separation der einzelnen Schlüssel und Schlüsselgruppen (sieheSP_KEY_ALL) werden zusätzlich Abhängigkeiten beim Wechsel von einzelnen Schlüsselnund Algorithmen im laufenden Betrieb minimiert. So sollte auch der Wechsel vonSchlüsseln und Algorithmen im laufenden Betrieb praktikabel ermöglicht werden. Dabeiwerden die Auswirkungen auf die involvierten Komponenten und Fachdienste detaillierterin Kapitel F4 betrachtet.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 536 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF3.3.1 - Generation Testkarten: RSA und 2TDESDiese Generation wird durch [gemSpec_eGK_P1] spezifiziert.F3.3.2 - Generation 1: RSA und 3TDES, Ausgabe ab Q2 / 2008Die derzeitigen Spezifikationen werden moderat weiterentwickelt und nur geringfügig verändert.Die RSA Moduluslänge 1024 Bit wird lediglich aus Kompatibilitätsgründen erwähntund DARF NICHT bei der eGK eingesetzt werden.• BasisalgorithmenoooRSA mit Moduluslängen aus der Menge {1024, 2048} Bit, 2 16 < public Exponent< 2 323TDESSHA–1, SHA–256• Client / Server Authentisierungo Authentisierungsalgorithmus analog zu [gemSpec_eGK_P1] Anhang E.6ooÜbergabe von Authentisierungsdaten T, die gemäß PKCS#1_v1.5 zu paddensind.Moduluslänge stets 2048 bit• HybridverschlüsselungoooKarte rekonstruiert den symmetrischen Dokumentschlüssel mittels PSODecipherDatenformat PKCS#1_v1.5Moduluslänge stets 2048 bit• SignaturerzeugungoooHashen innerhalb der Karte mittels SHA–256 und Übergabe eines externerzeugten HashwertesEMSA-PSS gemäß PKCS#1_v2.1 und ISO 9796-2 PaddingModuluslänge stets 2048 bit• CV–ZertifikateoNicht selbstbeschreibende Zertifikategematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 537 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturoooooModulus des enthaltenen öffentlichen Schlüssels und Länge der Signatursind stets identischDer enthaltene öffentliche Schlüssel hat als Verwendungszweck entweder„Prüfung von CV–Zertifikaten“ oder „Card-2-Card Authentisierung“Zur Prüfung der Zertifikatssignatur wird SHA–256 50 verwendet.Zugriffsrechte werden per Rollenkennungen CHA angegebenCOS muss für CV–Zertifikate alle Moduluslängen aus der folgenden Mengeunterstützen: {1024, 2048} bit• Asymmetrische Authentisierung ohne SM–Schlüsselvereinbarungo Authentisierungsprotokoll analog zu [gemSpec_eGK_P1] Anhang E.2ooHashalgorithmus SHA–256Zur RSA Schlüssellänge siehe CV–Zertifikate• Asymmetrische Authentisierung mit SM–SchlüsselvereinbarungoooAuthentisierungsprotokoll gemäß [prEN14890-1] Kapitel 8.4 (entspricht[gemSpec_eGK_P1] Anhang E.3 und [DINSIG-4] Anhang D.1)Hashalgorithmus SHA–256Zur RSA Schlüssellänge siehe CV–Zertifikate• Symmetrische Authentisierung ohne SM–Schlüsselvereinbarungo Authentisierungsprotokoll analog zu [gemSpec_eGK_P1] Anhang E.5o3TDES Verschlüsselung eines 8 Byte TokensDieser Fall wird in [BSI TR–03116] nicht behandelt.• Symmetrische Authentisierung mit SM–Schlüsselvereinbarungo Authentisierungsprotokoll gemäß [prEN14890-1] Kapitel 8.8oo3TDES Verschlüsselung ohne Padding im CBC Mode mit IV gleich´00…00´3TDES Retail–MAC mit ISO 7816-4 Padding• Session Key Berechnung bei symmetrischer und asymmetrischer Authentisierung50 Spätere Abstimmung.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 538 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturoo[BSI TR–03116] 3.1.2 verlangt DINSIG-4 Annex D 4.1. Daraus resultierenaber lediglich 2TDES SchlüsselExterne Welt liefert 32 Byte KD.IFD, Karte liefert 32 Byte:KD.ICC KD = KD.IFD XOR KD.ICCo hash1 = SHA–256( KD || ´0000 0001´ )Die 24 MSB bilden ENC Schlüssel, die 8 LSB bildenSSCenc.o hash2 = SHA–256( KD || ´0000 0002´ )Die 24 MSB bilden MAC Schlüssel Kmac, die 8 LSB werden nicht benutzt,SSCmac=´00…00´.o [BSI TR–03116] Kapitel 3.1.1 verlangt ANSI X9.63 Abschnitt 5.6.3• Secure Messagingoo3TDES Retail–MAC mit SSCWird in [BSI TR–03116] 3.2.2 nicht erwähnt.[BSI TR–03116] verlangt ab Ende 2009 AES–128 CMAC3TDES CBC Verschlüsselung mit IV identisch zum SSC der MAC BerechnungDiese IV Variante wird in [BSI TR–03116] 3.3.1 nicht erwähnt.F3.3.3 - Generation 2: Elliptische Kurven (ELC) und AES, Ausgabe ab etwa 2011Die derzeit in der Gesundheitskarte verwendeten kryptographischen Algorithmen werdenfast komplett ausgetauscht.• BasisalgortihmenoELC basierend auf GF(p) mit 256 bit• Das COS muss alle Kurven unterstützen, welche die Anforderungenaus [BrainPool] Kapitel 3 erfüllen. Zusätzliche Kurven können unterstütztoder abgelehnt werden.• Domainparameter müssen im Feld nachladbar sein (herstellerspezifisch).• ECDSA gemäß [BSI TR–03111] Kapitel 4.2• EC–KAEG gemäß [BSI TR–03111] Kapitel 4.3ooAES–128, AES–256SHA–256• Client / Server Authentisierungo Internal Authenticategematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 539 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturoooKommando enthält Token T, welches gemäß ECDSA signiert wird.Response APDU enthält diese SignaturVerwendete Kurve [BrainPool] brainpoolP256r1• Hybridverschlüsselung: Die Karte rekonstruiert den symmetrischen Dokumentenschlüssel.oPSO Decipher mit öffentlichem Schlüssel und verschlüsseltem Dokumentenschlüsselin den Kommandodateno Schritt 1: Verfahren gemäß EC–KAEG, siehe [BSI TR–03111] Kapitel 4.3,erzeugt gemeinsames Geheimnis,• EC–KAEG wird in [BSI TR–03116] 3.3.2 erwähnt, nicht aber in4.4.2ooooSchritt 2: aus gemeinsamen Geheimnis werden AES–256 Schlüssel gebildetSchritt 3: AES–256 Schlüssel entschlüsseln DokumentenschlüsselResponse APDU enthält den symmetrischen DokumentenschlüsselVerwendete Kurve [BrainPool] brainpoolP256r1• SignaturerzeugungoooHashen innerhalb der Karte mittels SHA–256 und Übergabe eines externerzeugten HashwertesECDSAVerwendete Kurve [BrainPool] brainpoolP256r1• CV–ZertifikateooooooSelbstbeschreibende ZertifikateDer enthaltene öffentlichen Schlüssels und der Schlüssel zur Prüfung derZertifikatssignatur verwenden dieselben DomainparameterDer enthaltene öffentliche Schlüssel hat als Verwendungszweck entweder„Prüfung von CV–Zertifikaten“ oder „Card-2-Card Authentisierung“Zur Prüfung der Zertifikatssignatur wird SHA–256 verwendet.Zugriffsrechte werden per „Bitliste“ im CHA angegebenVerwendete Kurve [BrainPool] brainpoolP256r1• Asymmetrische Authentisierung ohne SM–Schlüsselvereinbarunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 540 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturoooAuthentisierungsprotokoll TODOHashalgorithmus SHA–256Zu Domainparameter siehe CV–ZertifikateWird in [BSI TR–03116] nicht eigens behandelt, erscheint hier nicht notwendig,da es auf Signaturerzeugung und Signaturprüfung hinausläuft.• Asymmetrische Authentisierung mit SM–SchlüsselvereinbarungoProtokoll [prEN14890-1] Kapitel 8.5 „Device authentication with privacyprotection“[BSI TR–03116] 3.1.2 verlangt DINSIG-4 Annex D 4, das ist anders als[prEN14890-1]Kapitel 8.5!ooHashalgorithmus SHA–256Zu Domainparameter für Diffie Hellman und Authentisierungsschlüsselnsiehe CV–Zertifikate• Symmetrische Authentisierung ohne SM–Schlüsselvereinbarungo Authentisierungsprotokoll analog zu [gemSpec_eGK_P1] Anhang E.5oAES–128 Verschlüsselung eines 16 Byte Tokens im ECB ModeWird in [BSI TR–03116] nicht behandelt.• Symmetrische Authentisierung mit SM–Schlüsselvereinbarungo Authentisierungsprotokoll gemäß [prEN14890-1] Kapitel 8.8ooAES–128 Verschlüsselung CTR Mode mit startCounter gleich 16 Byte Tokender GegenseiteAES–128 CMAC• Session Key BerechnungoBeiosymmetrischer Authentisierung liefert externe Welt 32 Byte KD.IFD, Karteliefert 32 Byte KD.ICCKD = KD.IFD XOR KD.ICCoasymmetrischer Authentisierung mit Diffie Hellman Key ExchangeKD ist das (256 bit) gemeinsame Geheimnis zwischen externerWelt und Kartegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 541 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturo hash1 = SHA–256( KD || ´0000 0001´ )Die 16 MSB bilden ENC Schlüsselo hash3 = SHA–256( KD || ´0000 0003´ )Die 16 MSB bilden startCounter für ENC Schlüsselo hash2 = SHA–256( KD || ´0000 0002´ )Die 16 MSB bilden MAC Schlüsselo hash4 = SHA–256( KD || ´0000 0004´ )Die 16 MSB bilden SSC für MAC Schlüsselo[BSI TR–03116] Kapitel 3.1.2 verlangt entweder [DINSIG-4], aber dies sindnur 2TDESSchlüssel, oder ANSI X9.63• Secure MessagingooAES–128 CMAC mit 16 Byte SSC als Präfix vor den zu „MACenden“ DatenAES–128 CTR Mode Verschlüsselung mit fortgeschriebenem Counter,Startwert aus SessionkeyberechnungACHTUNG: [BSI TR–03116] Kapitel 4.5.2 verlangt AES im CBC Mode, obwohlin [BSI TR–03116] 3.3.1 auch CTR Mode zugelassen wird.Ende des Auszugs aus der Anlage zu diesem abgestimmten Protokoll: AlgorithmenpaketeChipkartenspezifikationen V0.4 vom 8.8.07.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 542 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF3.4- Zusammenfassung der SicherheitsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03120 AS-Krypt-MOD-01A_03121 AS-Krypt-MOD-02A_03122 AS-Krypt-MOD-03A_03123 AS-Krypt-MOD-04SSSSKrypto_Migration_01: Migration Migration kryptographischer Komponenten und Sicherheitsdienste:kryptographischer Komponenten (siehe [BSI TR-03116], AS-Krypt-01, AS-Krypt-02, AS-Krypt-03, ASundSicherheitsdienste Krypt-05)Jeder in der Telematikinfrastruktur verwendete kryptographischeAlgorithmus MUSS innerhalb von 6 Jahren planmäßig vollständiggewechselt werden können.Krypto_Migration_02:Maximale Alle Schlüssel der TI SOLLEN eine maximale Gültigkeitsdauer von 6Gültigkeitsdauer von Schlüsseln. Jahren NICHT überschreiten.Krypto_Migration_03: AktiveSchlüsselgültigkeitsdauer allernoch ausgegebenen Schlüsseleines abzulösendenKrypto_Migration_04: Akzeptanzneu ausgegebener eGKs.Die aktive Schlüsselgültigkeitsdauer aller noch ausgegebenenSchlüssel eines abzulösenden Verfahrens in der TelematikinfrastrukturDÜRFEN das festgelegte Ende des Krypto-Verfahrens NICHTüberschreiten.Nach einem Jahr MÜSSEN eGK mit den neuen Algorithmen flächendeckendin der TI akzeptiert werden. Daher MÜSSEN die betroffenenKrypto-Komponenten in den dezentralen und zentralen Diensten derTelematikinfrastruktur spätestens nach einem Jahr die neuen Verfahrenim produktiven Betrieb unterstützen.Anhang F3Anhang F3Anhang F3Anhang F3Begründung: Bei einer Kartenlaufzeit von 5 Jahren für die eGK istnur ein Jahr für Planung, Spezifikation, Test, Zertifizierung, Abnahmeund Start der produktiven Nutzung der neuen Verfahren in den betroffenenKomponenten – u. A. Karten, Krypto-Komponenten der TI -möglich.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 543 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03124 AS-Krypt-MOD-05A_03125 AS-Krypt-MOD-06A_03126 AS-Krypt-MOD-07A_03127 AS-Krypt-MOD-08A_03128 AS-Krypt-MOD-09A_03129 AS-Krypt-MOD-10SSSSSSKrypto_Migration_05: Ausgabeneuer eGKs mit neuen AlgorithmenKrypto_Migration_06: Verkürzungder Lebensdauer.Krypto_Migration_07: Parallelbetriebfür 5 Jahre.Krypto_Migration_08: Ungültigkeitvon eGK mit abzulösendenverfahren.Krypto_Migration_09: Nutzungalgelaufener Algorithmen.Krypto_Migration_10: Akzeptanzvon eGKs mit neuen Algorithmen.Nach einem Jahr SOLLEN die ersten eGK mit den neuen Algorithmenausgegeben werden.Falls nach einem Jahr noch eGK mit dem alten Verfahren ausgegebenwerden, MUSS die Lebensdauer dieser Karten entsprechendverkürzt werden.Über eine Zeitraum von 5 Jahren MÜSSEN abzulösende und neueAlgorithmen parallel in den betroffenen Krypto-Komponenten derTelematikinfrastruktur unterstützt werden.Nach 5 Jahren sind die letzten eGK mit dem abzulösenden Verfahrenungültig und die Verwendung des abgelösten kryptographischenAlgorithmus in der Telematikinfrastruktur wird ausgeschlossen, indemsofort nach Ablauf des Gültigkeitszeitraums des Verfahrens alleSchlüssel zu diesem Verfahren aus dem produktiven Systemen entferntwerden und damit die Nutzung der Schlüssel nicht mehr möglichist.Danach SOLLEN die Algorithmen aus den Kryptographischen Komponentenentfernt werden und durch die Sicherheitsdienste der Telematikinfrastrukturnicht mehr angesprochen werden können. BeiNutzungsversuchen des abgelaufenen Algorithmus MÜSSEN entsprechendeAlarme erzeugt werden.Nach einem Jahr MÜSSEN eGK mit den neuen Algorithmen flächendeckendin der TI akzeptiert werden. Daher MÜSSEN die betroffenenKrypto-Komponenten in den dezentralen und zentralen Diensten derTelematikinfrastruktur spätestens nach einem Jahr die neuen Verfahrenim produktiven Betrieb unterstützen.Anhang F3Anhang F3Anhang F3Anhang F3Anhang F3Anhang F3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 544 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03130 AS-Krypt-MOD-1001A_03131 AS-Krypt-MOD-1002A_03132 AS-Krypt-MOD-1003A_03133 AS-Krypt-MOD-1004SSSSKrypto_Migration_11: Separationvon interoperablen Schnittstellenund Krypto-Providern/Krypto-Modulen.Krypto_Migration_12: Evaluierung:Krypto_Migration_13: AutomatisierterUpdate dezentraler KomponentenKrypto_Migration_14:Updatezentraler KomponentenSeparation: Die interoperablen Schnittstellen der TI sind so gestaltet,dass sich eine Änderung der Krypto-Algorithmen nur auf die Krypto-Provider und Krypto-Module beschränkt. Eine Änderung der interoperablenDienstschnittstellen ist nicht notwendig.Hinweis: Die Abgrenzung der Sicherheitsdienste und Verwendungkonkreter Krypto-Algorithmen von der Anwendungsfunktionalität istdie zwingende Grundvoraussetzung für die Migration. Wenn nochzusätzlich Anwendungsfunktionalität betroffen ist, dann ist eine Änderungim vorgegebenen Zeitraum nicht mehr möglich.Evaluierung: Bei einem Zeitraum von 3 Monaten für den Test und dieEvaluierung der Krypto-Komponenten wird davon ausgegangen,dass ein verkürztes Verfahren verwendet werden kann. Die zu betrachtendenÄnderungen sind auf die Krypto-Komponenten beschränktund eine vollständige Evaluierung der betroffenen Komponentenund Dienste (z. B. des Konnektors, der Fachdienste und desTrustedService des Brokers) ist nicht notwendig.Automatisierter Update dezentraler Komponenten: AutomatisierteVerfahren SOLLEN bei den dezentralen Komponenten (z. B. Konnektor)verwendet werden.Hinweis: Bei einem lokalen Verfahren zum Update der dezentralenKomponenten in der TI kann vermutlich ein Zeitraum von 3 Monatennicht eingehalten werdenDer Update zentraler Komponenten ist im Sicherheitskonzept desBetreibers zu beschreiben: Die zentralen Komponenten der TI unddie Fachdienste von den Betreibern MÜSSEN im Rahmen einesChanges innerhalb von 3 Monaten umgestellt werden. Die spezifischenSicherheitskonzepte der Betreiber MÜSSEN die Umstellungsprozessebeschreiben und die Wirksamkeit der getroffenen Maßnahmenist nachzuweisen.Anhang F3Anhang F3Anhang F3Anhang F3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 545 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF4 - Anwendungen und EinsatzumgebungenZiel dieses Kapitels ist die Erstellung eine möglichst vollständigen Liste aller Anwendungen,Beschreibung, Annahmen und Mindestanforderungen zur jeweiligen Einsatzumgebung,ggf. die Festlegung eine Gruppe von zulässigen Algorithmen für den jeweiligenEinsatzzweck (Auswahl aus der TR-03116)Die Gliederung erfolgt entsprechend den Anwendungen und Einsatzumgebungen. Wesentlichfür den Schutz der medizinischen Daten in der Telematikinfrastruktur sind dieSchlüssel zum Schutz der Daten auf Anwendungsebene (siehe Kapitel F4.1). Aufgrundder gestuften Sicherheitszonen der Telematikinfrastruktur (siehe AS_EP_06) wird eineUnabhängigkeit der Anwendungssicherheit von den Schlüsseln der darunter liegendenSchichten der Transport- und Netzwerkschicht (siehe Kapitel F4.2) erreicht.Die Anwendungen und Einsatzumgebungen, die dazugehörigen Sicherheitsobjekte undSicherheitsinfrastrukturen werden erst nach Anwendungs-Ebenen und dann entsprechendder Schlüsselverwendung aufgeteilt.F4.1 - AnwendungsebeneZur Anwendungsebene gehören alle UseCases, die zur Änderungen der fachlichen Inhalteder §291a Fachanwendungen (VSDM, VODM, NFDM, AMTS,…) in den Fachdienstender Telematikinfrastruktur bzw. auf der Gesundheitskarte führen. Ebenso liegen die Verwaltungder freiwilligen Anwendungen und der Berechtigungen auf der Anwendungsebene.Damit gehören auch die C2C- und C2S-Authentifizierung zur Anwendungsebene.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 546 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturServiceConsumerTierTelematik TierdezentralTelematikTierzentralService ProviderTier1.3 Zutrittbeschränkt 1.1.1:AnwendungsDiensteReq.TrustedViewerRes.sign encodeverify decode2.4: BenutzerindividuelleDiensteAnwendungskonnektorBroker-Servicesignverifysign grantverify deny4.1: AnwendungsdienstePrimärsystemDienstschnittstelleFachdienstverschlüsseltemedizinischeDaten1.4 überwachtTVSSAKTicket-ServiceAuditTSSCSSVSSAKAuditSSAKTicket-ServiceIdentitätenRechte,TicketsSMCHSMHSM1.2 öffentlichTSLOCSP1.1.4: SicherheitsdiensteOCSP3.4: SicherheitsdiensteOCSP4.4: SicherheitsdiensteKryptographischungeschützteNetzverbindungKryptographischgeschützteNetzverbindungHSMKrypto-ProviderKarten (eGK, HBA, SMC),HSMAbbildung 38: Sicherheitsdienste und Sicherheitsfunktionen auf Anwendungsebene 51Die Einsatzumgebungen der Schlüssel sind in Abbildung 38 übersichtsartig dargestellt.Dabei sind die zusätzlichen kryptographischen Verbindungen auf Netzwerkebene dargestellt.Die Herausgeber-CAs der asymmetrischen Schlüssel zum Signieren und Verschlüsselnauf Anwendungsebene sind in der Trusted Service Status List TSL als Vertrauensraumzu finden. Bei der der Nachrichten-Authentisierung sind die Vertrauensankerder Schlüssel in Chipkarten in der TSL-PKI und die Vertrauensanker der Schlüssel inDiensten in der TCL-PKI zu finden (siehe Abbildung 39). Es MUSS eine sichere Überprüfungder Gültigkeit der Zertifikate gewährleistet werden.51 Antworten der OCSP-Server zum Zertifikatsstatus sind signiertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 547 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 39: Struktur der PKI mit TSL und beteiligten Akteuren [gemX509_TSP]F4.1.1 – Signatur von Dokumenten• Qualifizierte elektronische Signatur• Fortgeschrittene elektronische SignaturenEinsatzumgebung Private Schlüssel zur Signatur in ChipkartenIn den Chipkarten liegt der private Schlüssel in einem geschützten Bereich eines Sicherheitsmoduls(Umgebung U2 s. u.). Der private Schlüssel ist durch einespezielle Signatur-PIN geschützt. Die Karteninhaber wurden über die Handhabung der Karte und der PINbelehrt. Der Kartenleser ist geprüft und zugelassen, er hat entweder ein sicheres (tamperresponse)Gehäuse und steht unter Aufsicht (TR und Umgebung U8 s. u.) oder er hat einGehäuse, das nur Manipulationen sichtbar macht und er steht unter ständiger Kontrolle(TE und Umgebung U9 s. u.).Eine Signaturanwendungskomponente (SAK) unterteilt in Trusted Viewer auf dem Arbeitsplatzdes Primärsystems und SAK auf den Konnektor unterstützt den Signierer beider Auswahl, dem Kontrollieren der Daten und dem eigentlichen Signieren der zu signierendenDaten. Details stehen in der Konnektorspezifkation.Für Qualifizierte Signaturen muss die SAK und die Chipkarte evaluiert sein, es werdenSchlüssel und Zertifikate verwendet, die ausdrücklich für QES zugelassen sind.Besondere Einsatzumgebung im Rahmen der StapelsignaturDie Einsatzbedingungen des Heilberufsausweises (HBA) führen zu folgenden weiterenRandbedingungen:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 548 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturzentrale Aufbewahrung des HBA:Leistungserbringer wollen ihren HBA nicht den ganzen Tag mit sich führen, sondern ihnan einer zentralen Stelle in einem gesicherten Bereich (siehe Abschnitt 1.4) in einen Kartenleserstecken. Dieser Kartenleser wird per LAN angeschlossen.entfernte PIN-Eingabe:Leistungserbringer wollen zur PIN-Eingabe nicht das Kartenterminal im gesicherten Bereichaufsuchen, in welchem der HBA gesteckt ist, sondern wollen dafür ein Kartenterminalnutzen, welches sich im Behandlungszimmer befindet. Die PIN soll also entfernt eingegebenwerden.Bindung der Stapelsignatur an die gesicherte Einsatzumgebung:Die Funktionalität, Stapelsignaturen erstellen zu können, soll technisch an die gesicherteEinsatzumgebung in den Geschäftsräumen des Leistungserbringers gebunden werden.Wird der HBA in einer anderen als der speziell gesicherten Einsatzumgebung betrieben,sollen weiterhin Einzelsignaturen erstellt werden können, aber die Funktionalität der Stapelsignatursoll technisch gesperrt sein.Der HBA muss die Einsatzumgebung nicht aktiv erkennen können. Es reicht aus, wenndie gesicherte Einsatzumgebung einen zusätzlichen Authentisierungsschritt durchführt,den der HBA verifizieren kann und der in einer ungesicherten Einsatzumgebung auch voneinem Angreifer nicht erfolgreich vorgetäuscht werden kann. In diesem Konzept wird vorgeschlagen,dass sich als Zeichen für die gesicherte Einsatzumgebung die SMC Typ Bgegenüber dem HBA authentisiert. Dieser Vorschlag erleichtert es, anschließend dieDTBS via SMC Typ B per Secure Messaging an den HBA zu übermitteln.Diese spezielle SMC Typ B wird also erst nach Überprüfung der besonderen Einsatzumgebung(U_OP_batchsig) ausgehändigt und eingesetzt.Der HBA muss für Stapelsignatur vorbereitet und zugelassen sein, sonst ändert sich dieAnforderung an die Chipkate nicht: In den Chipkarten liegt der private Schlüssel in einemgeschützten Bereich eines Sicherheitsmoduls (Umgebung U2 s. u.). Der private Schlüsselist durch eine spezielle Signatur-PIN geschützt. Die Karteninhaber wurden über dieHandhabung der Karte und der PIN belehrt. Der Kartenleser ist geprüft und zugelassen,er hat entweder ein sicheres (tamper-response) Gehäuse und steht unter Aufsicht (TRund Umgebung U8 s. u.) oder er hat ein Gehäuse, das nur Manipulationen sichtbar machtund er steht unter ständiger Kontrolle (TE und Umgebung U9 s. u.).Auch die Signaturanwendungskomponente (SAK) für Stapelsignatur unterteilt in TrustedViewer auf dem Arbeitsplatz des Primärsystems und SAK auf den Konnektor unterstütztden Signierer bei der der Auswahl, dem Kontrollieren der Daten und den eigentlichen Signierender zu signierenden Dateien. Details stehen in der TR-03114.Für Qualifizierte Signaturen muss die SAK und die Chipkarte evaluiert sein, es werdenSchlüssel und Zertifikate verwendet, die ausdrücklich für QES zugelassen sind.• Einsatzumgebung der SAKDie Einsatzumgebung der SAK wird standardisiert werden, um dem Leistungserbringerdie Schaffung eines definierten Sicherheitsniveaus zu ermöglichen und zum anderen denHerstellern der SAK eine Auslegung der Produkte für eine definierte Zielumgebung zuermöglichen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 549 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDas Dokument „Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten– Arbeitsgrundlage für Entwickler / Hersteller und Prüf- / Bestätigungsstellen“[BNetzA_ESES] ist Basis der Einteilung der Einsatzumgebungen in der verschiedeneKlassen 52 :• Ungeschützte Einsatzumgebung: Die SAK muss sich vor signaturspezifischenBedrohungen – auch aus dem Internet – komplett selber schützen.• Geschützte Einsatzumgebung: Die Einsatzumgebung schützt in Kombinationmit den Mechanismen der SAK mit hoher Sicherheit gegen potenzielle Angriffeüber das Netz und insbesondere auch das Internet, einen manuellenZugriff Unbefugter sowie einen Datenaustausch per Datenträger.• Isolierte Einsatzumgebung: Die Einsatzumgebung ist von allen Kommunikationsnetzengetrennt und schützt mit hoher Sicherheit gegen einen manuellenZugriff Unbefugter sowie einen Datenaustausch per Datenträger.Der Leistungserbringer wird die SAK immer in einer geschützten Einsatzumgebungbetreiben.Die Anforderungen der SAK für Stapelsignaturen an die Einsatzumgebung sind höher alsdiejenigen der SAK für die Einzelsignatur, da es spezifische Bedrohungen beim Einsatzder Stapelsignatur gibt.In Zukunft wird noch eine normative Beschreibung der Anforderungen an die geschützte Einsatzumgebungfolgen.F4.1.2 – Verschlüsselung von DokumentenHybrid VerschlüsselungBei der hybriden Verschlüsselung von Dokumenten wird zuerst auf sicherem Wege einsymmetrischer Schlüssel erzeugt (Objektschlüssel). Mit diesem symmetrischer Schlüsselwird das Dokument selbst dann symmetrisch verschlüsselt. Der verwendete Schlüsselwird danach asymmetrisch für alle vorgesehenen Empfänger verschlüsselt, deren Zertifikatemüssen dafür vorliegen.Einsatzumgebung Hybrid VerschlüsselungDie Erzeugung des symmetrischen Schlüssels hat nach einem geprüften hochwertigenZufallsverfahren zu erfolgen, denn die statischen Objektschlüssel werden jahrelang imEinsatz sein. Danach ist der Schlüssel auf höchstem Niveau zu schützen.Erzeugung und Anwendung des Objektschlüssels finden im Konnektor statt. Ein Konnektorin einer Betriebsumgebung steht zumindest in einer Umgebung ohne Publikumsverkehrund ist entweder durch ein Gehäuse geschützt, das Manipulationen anzeigt oder ersteht ständig unter Aufsicht. Ein Konnektor in einer geschützten Rechzentrumsumgebungoder im Sicherheitsbereich eines Rechenzentrums, benötigt weder spezielle Gehäusenoch besondere Aufsicht.52 Der Begriff „Einsatzumgebung“ wird hier verwendet, da daraus Vorgaben für Umgebungen abgeleitetwerden. Die SAK wird dann einen „Einsatzbereich“ haben, d.h. in bestimmten „Einsatzumgebungen“eingesetzt werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 550 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie Auswahl der Empfänger ist sicherheitskritisch, denn ein „untergeschobener“ Empfängerkann die u. U. die medizinischen Daten lesen. Die Auswahl MUSS auf einem sehrhohen Sicherheitsniveau stattfinden.Wird der Objektschlüssel im Rahmen von „Umschlüsselung und Datenerhalt“ erneut verschlüsselt,geschieht dies im geschützten Bereich eines HSM.Einsatzumgebung Hybrid EntschlüsselungDie Entschlüsselung des asymmetrisch verschlüsselten Objektschlüssels findet in derChipkarte statt. Danach ist der Objektschlüssel auf höchstem Niveau zu schützen. DerObjektschlüssel wird dem Konnektor zugesandt, der mit Hilfe des Objektschlüssels daseigentliche Dokument entschlüsselt.In den Chipkarten liegt der private Schlüssel zur Entschlüsselung in einem geschütztenBereich eines Sicherheitsmoduls (Umgebung U2 s. u.). Der private Schlüssel ist durch diePIN geschützt. Die Karteninhaber wurden über die Handhabung der Karte und der PINbelehrt. Der Objektschlüssel wird entschlüsselt und im Klartext an den Kartenleser übergeben.Der Kartenleser ist geprüft und zugelassen, er hat entweder ein sicheres (tamperresponse)Gehäuse und steht unter Aufsicht (TR und Umgebung U8 s. u.). oder er hat einGehäuse, das nur Manipulationen sichtbar macht und er steht unter ständiger Kontrolle(TE und Umgebung U9 s. u.). Die Verbindung vom Kartenleser zum Konnektor ist verschlüsselt.Der Schlüssel wird vom Konnektor empfangen, der Konnektor entschlüsseltdas eigentliche Dokument. Der Konnektor sendet das Dokument am das Primärsystemweiter.Konnektor in einer Betriebsumgebung steht zumindest in einer Umgebung ohne Publikumsverkehrund ist entweder durch ein Gehäuse geschützt, das Manipulationen anzeigtoder er steht ständig unter Aufsicht. Ein Konnektor in einer geschützten Rechenzentrumsumgebungoder im Sicherheitsbereich eines Rechenzentrums, benötigt weder spezielleGehäuse noch besondere Aufsicht.Wird der Objektschlüssel im Rahmen von „Umschlüsselung und Datenerhalt“ temporärentschlüsselt, geschieht dies im geschützten Bereich eines HSM.Umschlüsselung und DatenerhaltDie planmäßige Umschlüsselung langfristig (> 1Jahr) gespeicherter medizinischer Datenund Dokumente MUSS vorgesehen werden. Siehe Nachfolgende Anforderungen aus derTR-03116• Da ein Angreifer die über das Internet übertragenen Daten langfristig speichernkann, um sie später zu entschlüsseln, kann ein langfristiger Schutz solcherDaten grundsätzlich nicht gewährleistet werden. Daraus ergeben sichfolgende Konsequenzen:ooDie über das Internet übertragene vertrauliche Information ist auf das notwendigeMaß zu beschränken.Die Infrastruktur muss für einen Übergang auf stärkere Kryptoverfahrenausgelegt sein. Insbesondere sind (z. B. auf Servern) gespeicherte vertraulicheDaten bei einem solchen Übergang neu zu verschlüsseln und die altenDatensätze zu löschen.Die Risiken für einen kryptographischen Angriff auf verschlüsselte medizinische Daten inder TI sind zu begrenzen, so dass die verbleibenden Restrisiken kleiner als das derzeitigeNiveau sind:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 551 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Datensparsamkeit bei der Übertragung der Daten über das Internet.• Umschlüsselung medizinischer Daten eines Versicherten MUSS vorgesehenwerden.Mindestanforderungen für ergänzende Maßnahmen sind zu beschreiben.Hinweis: Es ist davon auszugehen, dass die Lebensdauer mancher verschlüsselter/signierterDokumente länger ist als die Nutzungsdauer der verwendeten Schlüsselbzw. des eingesetzten Verfahrens. Ist das Verfahren zu unsicher geworden, müssen ergänzendeMaßnahmen getroffen werden (Zeitstempeln, Nachverschlüsseln/Nachsignierenmit anderen Verfahren…).F4.1.3 – Nachrichten-Authentisierung der Telematik-Core MessageFür Webservices werden die Sicherheitsservices durch Webservices Security, XML-Signature-, XML-Encryption-Mechanismen und einen Webservice basierten Datenzugriffauditserviceimplementiert. XML-Signature- und XML-Encryption-Mechanismen könnenauch Offline genutzt werden.Der mit dem Zertifikat korrespondierende private Schlüssel liegt entweder in Chipkartenvor (HBA, SMC-B oder eGK) oder in Diensten d. h. in Fachdiensten oder technischenDiensten wie Broker, Audit.Hinweis: Damit sind bei der Nachrichten-Authentisierung die Schlüssel in Chipkarten inder TSL-PKI und die Schlüssel in Diensten in der TCL-PKI organisiert. Trotzdem ist einesichere Überprüfung der Gültigkeit der Zertifikate zu gewährleisten.OSI SchichtTabelle 51: Kryptographische Identitäten Webservice SecurityZertifikat und kryptographischeIdentitätZertifikat zugeordneter Akteur,Service oder NetzwerkkomponenteHerausgebende CASchicht 7X.509-Zertifikate und Schlüsseleiner HBA oder SMC-BHeilberufler oder Institution (HBAoder SMC-B)X.509 CA für HBAs oder SMC-BX.509-Zertifikate und Schlüsseleiner eGKVersicherter (eGK)X.509 CA für eGKsX.509-Service-Zertifikat undSchlüssel von Diensten (Fachdienstenund technischen Dienstenwie Broker, Audit).Service der Telematik oder ServiceProvider TierX.509 Telematik Services CAEinsatzumgebung Private Schlüssel zur Nachrichten-Authentisierung in ChipkartenIn den Chipkarten liegt der private Schlüssel in einem geschützten Bereich eines Sicherheitsmoduls(Umgebung U2 s. u.). Der private Schlüssel ist durch die PIN geschützt. DieKarteninhaber wurden über die Handhabung der Karte und der PIN belehrt. Der Kartenleserist geprüft und zugelassen, er hat entweder ein sicheres (tamper-response) Gehäuseund steht unter Aufsicht (TR und Umgebung U8 s. u.) oder er hat ein Gehäuse, das nurManipulationen sichtbar macht und er steht unter ständiger Kontrolle (TE und UmgebungU9 s. u.).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 552 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 52: Zulässige Verwendung Kryptographischer Identitäten 53Verwendungszweck Identität BeschreibungNachrichtensignatureneGK – AUT.NeGK – AUTSMC-B – OSIGHBA – AUTSMC-B – AUTVerwendung zur Signatur als Datenbearbeiter oder Datenautorität fürPflichtanwendungen sofern der eGK-Inhaber auf seine eigenen Datenzugreift.Verwendung zur Signatur als Datenbearbeiter oder Datenautorität fürPflichtanwendungen sofern der eGK Inhaber als Berechtigter für einenanderen Versicherten aktiv wird.Verwendung zur Signatur als Datenbearbeiter. Diese Rolle wird für diemeisten Pflichtanwendungen zur rollenbasierten Autorisierung gegenüberden Fachdiensten verwendet, sofern nicht explizit die Signatur einesHeilberuflers gefordert ist.Verwendung zur Signatur als Datenautorität, sofern für diese Identität eineBerechtigung mittels eines Tickets hinterlegt wurde.Verwendung zur Signatur als Datenbearbeiter, sofern explizit die Rolle desHeilberuflers zur Autorisierung am Fachdienst benötigt wird. Es solltegeprüft werden, ob die Autorisierung mittels der Rolle der Organisationebenfalls möglich wäre und die Verwendung der SMC-B oSIG ist zu bevorzugensofern dies fachlich zulässig ist.Verwendung zur Signatur als Datenautorität, sofern für diese Identität eineBerechtigung mittels eines Tickets hinterlegt wurde.Analog zur Verwendung HBA-AUTEinsatzumgebung Private Schlüssel zur Nachrichten-Authentisierung in DienstenIn den Diensten (Fachdienste, Broker, Audit, weitere…) gibt es in der Regel ein AUT- Zertifikatund den zugehörigen privaten Schlüssel für die Signatur von Nachrichten (Antwortnachrichten,eigenen Nachrichten) und ggf. weiteren Daten durch den Dienst. Das Zertifikatbzw. der Schlüssel wird für manche technische Dienste wie SDS nicht benötigt.Nach GA kann es ggf. auch mehrere AUT-Zertifikate für einen Dienst (zu unterschiedlichenprivaten Schlüsseln) geben, wenn innerhalb des Dienstes Signaturen für verschiedeneZwecke und/oder mit verschiedenen Sicherheitsniveaus unterschieden werdenmüssen.Im Broker (genauer im SCS) und im Auditdienst wird der private Schlüssel im geschütztenBereich eines HSM (Umgebung U6 s. u.) aufbewahrt und eingesetzt. Dieses HSM stehtzumindest im geschützten Bereich eine Rechenzentrums (Umgebung U12 s. u.). DerZugriff zum Schlüsselmaterial des HSM ist durch eine hochwertige Policy (siehe Kap.F6.1.16 mit 4 Augen-Prinzip oder zumindest gleichwertig) geschützt.Für die privaten Schlüssel in Fachdiensten gelten dieselben Anforderungen an dieEinsatzumgebung wie für Broker und Auditdienst.Zumindest in den folgenden Diensten gibt es ein AUT-Zertifikat: VSDM, VODM, CAMS,UFS, NFDM, AMDOK, OCSP; Auditdienst (AuditS), Trusted Service (Broker) mit SVS undSCS, Ticketservice/Datenerhalt, Anwendungen des Versicherten (AdV), Verwaltung freiwilligerAnwendungen (VfA)53 Die Aufgeführte Tabelle stellt in einer Übersicht die zulässigen Verwendungszwecke gemäß derGesamtarchitektur dar.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 553 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF4.1.4 – Session Authentisierung und sicherer Kanal (C2S)C2S Authentisierung mit symmetrischen Verfahren mit Etablierung des sicheren Kanalszwischen der eGK und• CAMS,• VSDD,Hinweis: Eine Änderung der fachlichen Datenstrukturen auf der Karte (z. B. VSDD) bzw.ein Anlegen neuer Filestrukturen (Kartenapplikationen) wird als eine Funktion der Anwendungsebenegesehen.Einsatzumgebung Symmetrische Authentikationsschlüssel in ChipkartenIn den Chipkarten liegt der Symmetrische Authentikationsschlüssel in einem geschütztenBereich eines Sicherheitsmoduls (Umgebung U2 s. u.). Der Symmetrische Authentikationsschlüsselist nicht durch die PIN geschützt, d.h. die Authentifikation kann gleich nachStecken der Karte durchgeführt werden. Der Kartenleser ist geprüft und zugelassen, erhat entweder ein sicheres (tamper-response) Gehäuse und steht unter Aufsicht (TR undUmgebung U8 s. u.) oder er hat ein Gehäuse, das nur Manipulationen sichtbar macht under steht unter ständiger Kontrolle (TE und Umgebung U9 s. u.).Einsatzumgebung Symmetrische Authentikationsschlüssel in den Dienstenin den Diensten CAMS und VSDD wird der Symmetrische Authentikationsschlüssel imgeschützten Bereich eines HSM (Umgebung U6 s. u.) aufbewahrt und eingesetzt. DiesesHSM steht zumindest im geschützten Bereich eine Rechenzentrums (Umgebung U12s. u.). Der Zugriff zum Schlüsselmaterial des HSM ist durch eine hochwertige Policy (sieheKap. F6.1.16 mit 4 Augen-Prinzip oder zumindest gleichwertig) geschütztF4.1.5 – Session Authentisierung und sicherer Kanal (C2C mit SMC/HBA)C2C Authentisierung mit Etablierung sicherer Kanal zwischen HBA/SMC-B/SMC-A und• eGk,• HBA, SMC-BEinsatzumgebung Private CV-Schlüssel in ChipkartenIn den Chipkarten liegt der private Schlüssel in einem geschützten Bereich eines Sicherheitsmoduls(Umgebung U2 s. u.). Der private Schlüssel ist nicht durch die PIN geschützt,d. h. die Authentifikation kann gleich nach Stecken beider Karten durchgeführt werden.Der Kartenleser ist geprüft und zugelassen, er hat entweder ein sicheres (tamperresponse)Gehäuse und steht unter Aufsicht (TR und Umgebung U8 s. u.) oder er hateine Gehäuse, das nur Manipulationen sichtbar macht und er steht unter ständiger Kontrolle(TE und Umgebung U9 s. u.).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 554 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF4.2 - Transport-, Netz- und SystemebeneIn der nachfolgenden Abbildung 40: Kryptographisch gesicherte Verbindungen auf NetzundTransportebene zwischen den verschiedenen Sicherheitszonen sind die kryptographischgesicherten Netz- und Transportverbindungen zwischen den unterschiedlichenSicherheitszonen eingezeichnet.ServiceConsumerTierTelematik TierdezentralTelematik TierzentralService ProviderTierHBA1.4 ZutrittbeschränkteGKKTZone 1:Dezentral externeGKKTeKiosk1.3 überwachtAVSPVSKISTrustedViewereGK HBAKT1.9 LAN1.1 DiensteVPN-Gateway1.1.1:AnwendungsDiensteConnectorServiceTVSSAKKTSIBrokerService1.1.4: SicherheitsDienste1.1.3 BasisdiensteKTeKioskeGKVPN-GatewayTicket-ServiceSMC-B1.1.9:WANAuthentisierungDNSexternZone 2.9 Zone 2.2:ZugangsnetzwerkÖffentlicheDiensteZone 6.1: Externe MehrwertdiensteZone 2.3: ÉingeschränkteDiensteNTPStratum 2DNSinternBrokerAppl. ProxyOCSP,CRLProxyMehrwertdiensteZone 3.7: AdministrationZone 3.5: InfrastrukturdiensteDNS NTP SDSroot Stratum 1Zone 2.4: BenutzerindividuelleDienste2.4.2 Interne Dienste2.4.1 Externe DiensteBrokerServiceTrustedSVSServiceSCSAuditSInfrastrukturPKI ServicesOCSP, CRL, TSLZone 3.6: Sicherheitsdienste IZone 6.2: Interne Mehrwertdienste3.1 AnwendungsdiensteMPLS BackboneZone 3.8:Monitoring4.7: Administration4.5: InfrastrukturdiensteNTPStratum 24.1: AnwendungsdiensteUFSUFS-Ser.CAMSCAMS-Ser.AMTSAMTS-Ser.NFDMNFDM-ServVODMVODM-ServVSDMVSDM-Ser.eGKPKI-DiensteOCSPldapAutor.Service-,Objekt-TicketDatenerhaltUmschlüsseln4.6: SicherheitsdiensteZone 4.8MonitoringZone 5. Legacy und existing application TierInformationsflussNachrichtenflussfür Request/Response KommunikationsmusterInformationsflussNachrichtenflussVerbindungsaufbaufür sekundäre Nutzung von DienstenAbbildung 40: Kryptographisch gesicherte Verbindungen auf Netz- und Transportebenezwischen den verschiedenen SicherheitszonenDiese kryptographischen Identitäten auf Netzwerkebene sind notwendig um• ein abgeschlossenes Netzwerk für die Telematikinfrastruktur zwischen berechtigtenund von der gematik zugelassenen Komponenten und Diensten zurealisieren.• die übertragenen Anwendungs- bzw. Protokolldaten auf Anwendungsebenezusätzlich auf dem Übertragungsweg zwischen den Endpunkten zu verschlüsselnund damit gegen unberechtigte Zugriffe bzw. mögliche Angriffe auf demÜbertragungsweg zu schützen. Der Schutz dieser Daten auf Anwendungsebeneist jedoch durch starke kryptographische Algorithmen (siehe Kap.F.4.1) schon unabhängig von diesen zusätzlichen Mechanismen gegeben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 555 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie Herausgeber-CAs der asymmetrischen Schlüssel dieser „unteren“ Schichten sind inder Trusted Component List TCL als Vertrauensraum zu finden.Abbildung 41: Struktur der PKI mit TCL und beteiligten AkteurenF4.2.1 – VPN, IPSECIPSec• Konnektor (SM-NK), Zone 1.1 vs.- VPN-Konzentrator, Zone 2.2• L2TP wird zwar genutzt, aber nicht für die Authentifizierung und ist daher hierirrelevant.• Konnektor (SM-NK), Zone1.1 vs.- VPN-Konzentrator, Zone 2.2 desMehrwertdienstenetzesF4.2.2 –TLS/SSL AuthentisierungTLS/SSLAllgemein: Nachrichtenkommunikation zwischen verschiedenen Anwendungsservices inder Telematik MUSS Authentifizierung, Autorisierung, Vertraulichkeit und Integritätsschutzüber SSL/TLS implementieren.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 556 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Kartenterminal, Zone 1.4 vs Konnektor KTS, Zone 1.1.3• Konnektor (SMC-B), Zone1.1^ vs Broker Appl.-Proxy, Zone 2.3• Konnektor (SAK), Zone1.1 vs Trusted Viewer, Zone 1.3 (Optional)• Broker Service, Zone 4.2.1 vs Fachdienste, Zone 4.1• Broker Service/SDS Proxy, Zone 4.2 vs SDS, Zone 3.2• Broker Service, Zone 4.2.1 vs Trusted Service, Zone 3.4• Broker Service, Zone 4.2.1 vs Audit-Service, Zone 3.4• Broker Service, Zone 4.2.1 vs Broker Appl.Proxy, Zone 2.3• Audit-Service, Zone 3.4 vs AdV, Zone 3.1• Audit-Service, Zone 3.4 vs VfA, Zone 3.1• SDS, Zone 3.2 vs SDS-Proxy, Zone 2.4• OSCP, Zone 3.4 vs OSCP Proxy. Zone 2.3• Das ‚Front-facing’-Netzwerk der DMZ verbindet eine Demilitarisierte Zone{DMZ} eines Rechenzentrums mit dem MPLS Backbone. Typischerweise istKommunikation auf diesem Netzwerk auf OSI Layer 4 verschlüsselt(TLS/SSL).F4.2.3 –Systemebene technische Absicherung von Zulassungen• SMC-B,: Zertifikat OSIG Zweck : Bestätigung zugelassene LE-Institution.• SM-NK, Zertifikat AUT KON Zweck : Bestätigung zugelassener Konnektor.• SM-KT, Zertifikat CA: Zweck: Verifikation Baugruppenzulassung, ZertifikatBGRP Zweck: Bestätigung baugruppen-zugelassenes Terminal• Zertifikate und Schlüssel für Software-UpdatesF4.3 - EinsatzumgebungenF4.3.1 – Sichere HardwareumgebungenHier werden die sicheren Hardwareumgebungen, auch allgemein Sicherheitsmodule genannt,zusammengefasst, die so konstruiert und gebaut sind, dass man nur mit großemAufwand Zugriff auf die enthaltenen Daten erlangen kann. Diese Umgebungen sind:• Chipkarte: Plastikkarten, die mit einem Mikrochip zu Rechen- und Speicherzweckenversehen sind. Die Informationen werden in einem Halbleiterchip abgelegt,der mit einem Chipkarten-Lesegerät ausgelesen wird. Sicherheit kanndurch einen PIN-Schutz und mit Kryptoverfahren erreicht werden.• TPM (Trusted Platform Module): Ein Trusted Platform Module ist ein Chip zurAusführung von kryptographischen Funktionen sowie zur Speicherung vongematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 557 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturSchlüsseln. Ein TPM kann mit einer fest eingebauten Smartcard verglichenwerden.• HSM (Hardware Security Module): Bauteil, welches sicherheitsrelevante Informationen,wie Daten und kryptographische Schlüssel sicher speichert undverarbeitet. Ist in der Regel als Hochleistungskryptomaschine ausgelegt, kannaber auch ein nur spezieller Chipkartencontroller sein.In jedem diese Sicherheitsmodule kann ein geschützter Bereich eingerichtet sein, in demdie sensiblen Daten bei bestimmten Vorfällen automatisch gelöscht werden.F4.3.2 – BetriebsumgebungenDie Betriebsumgebungen sind die Bereiche in einer Büroumgebung, in einer Arztpraxis, ineiner Apotheke oder auf einer Station im Krankenhaus.Diese Umgebungen sind sehr heterogen, daher sind viele Kriterien nötig um die Umgebungenzu beschreiben.Als erstes unterscheiden wir zwischen allgemein zugänglichem Bereich ohne wirksameAufsicht und dem zugänglichem Bereich mit Aufsicht oder (einfacher) Zugangskontrolle.Bei dem zugänglichen Bereich mit Aufsicht oder Zugangskontrolle ist die Intensität derKontrolle zu unterschieden. Unter „ständiger Kontrolle“ heißt aus Sicherheitssicht, dasslückenlos eine Kontrolle ausgeübt wird, alles andere ist „ohne Aufsicht“. Kann die Kontrollefür einen Zeitraum nicht ausgeübt werden, sind weiter Maßnahmen notwendig (z. B.Gerät wegschließen).Das kryptographische Material ist in der Regel in einem Gerät mit einem geschlossenenGehäuse untergebracht das zumindest eine physikalischen Mindestschutz bietet. Ergänzendkönnen die Geräte erweiterten Schutz entsprechend Common Criteria V2.1) bieten:TE Passive Erkennung materieller Angriffe (Tamper evident, CC V2.1: FPT_PHP.1)stellt Leistungsmerkmale bereit, die anzeigen, wenn ein Gerät oder Element mit SicherheitsfunktionenManipulationen ausgesetzt ist. Das Melden der Manipulationen geschiehtjedoch nicht automatisch; ein autorisierter Benutzer muss eine die Sicherheit betreffendeSystemverwaltungsfunktion aktivieren oder eine manuelle Überprüfung veranlassen, umfestzustellen, ob eine Manipulation stattgefunden hat.Anforderungen:Die Sicherheitsfunktionen müssen materielle Manipulationen, die die Sicherheitsfunktionenbloßstellen können, eindeutig erkennen.Die Sicherheitsfunktionen müssen die Fähigkeit zum Feststellen erfolgter materieller Manipulationender Geräte oder Elemente mit Sicherheitsfunktionen bereitstellen.TD Melden materieller Angriffe (Tamper detection, CC V2.1:FPT_PHP.2) stellt das automatischeMelden von Manipulationen für eine identifizierte Teilmenge von materiellenPenetrationen bereit.Anforderungen:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 558 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturManagement des Benutzers oder der Rolle, der/die über das Eindringen informiert wird.Management der Liste von Geräten, die den benannten Benutzer oder die Rolle über dasEindringen informieren sollen.Die Sicherheitsfunktionen müssen materielle Manipulationen, die die Sicherheitsfunktionenbloßstellen können, eindeutig erkennen.Die Sicherheitsfunktionen müssen die Fähigkeit zum Feststellen erfolgter materieller Manipulationender Geräte oder Elemente mit Sicherheitsfunktionen bereitstellen.Die Sicherheitsfunktionen müssen die Geräte und Elemente gemäß Liste der Geräte/ E-lemente für die aktives Erkennen erforderlich ist, überwachen und einem benannten Benutzeroder einer benannten Rolle melden, wenn materielle Manipulationen an Gerätenoder Elementen stattgefunden haben.TR Widerstand gegen materielle Angriffe (Tamper Resistance, CC V2.1:FPT_PHP.3)stellt Leistungsmerkmale bereit, die materielle Manipulationen von Geräten und Elementenmit Sicherheitsfunktionen verhindern oder diesen widerstehen.Anforderungen:Management der automatischen Reaktionen auf materielle Manipulationen.Die Sicherheitsfunktionen müssen Szenarien materieller Manipulationen von der Liste vonGeräten/Elementen widerstehen, indem diese automatisch so reagieren, dass die Sicherheitspolicynicht verletzt wird.Hinweis: Die Einteilung nach Common Criteria V2.3 ist granularer und kann auch benutztwerden.F4.3.3 – PrivatumgebungenEine ganz spezielle Umgebung ist die häusliche Umgebung des Versicherten. Hier hängtdie Sicherheit maßgeblich von der Sorgfalt ab, mit der der Versicherte seine persönlicheVerantwortung umsetzt. Der Versicherte wird zwar genau instruiert werden, man kann vonihm in der Regel aber kein Fachwissen erwarten..Die Annahmen sind: Das Heim des Versicherten ist ein öffentlich nicht zugänglicher Bereich,die Wohnung oder der Raum sind in der Regel unter Verschluss. Der Versichertewird nicht grob gegen seine Interessen verstoßen.F4.3.4 – RechenzentrenSiehe Siko Anhang G2.1.1 - Zugang zum DatenzentrumDer Zugang zu den vom Dienstbetreiber betriebenen Datenzentren darf ausschließlichMitarbeitern des Dienstbetreibers, deren primärer Arbeitsbereich innerhalb des Datenzentrumsliegt, sowie externen Mitarbeiten gewährt werden, die aus eindeutig unternehmensrelevantenGründen Zugang zu diesen Bereichen erhalten müssen. Über alle Anträ-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 559 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturge für eine dauerhafte Zugangsberechtigung zum Datenzentrum MUSS von dem für dasDatenzentrum verantwortlichen Manager des Dienstbetreibers oder seinem Stellvertreterentschieden werden.Neben dem allgemeinen Bereich gibt es im Rechenzentrum den so genannten kontrolliertenBereich (Genaueres siehe Anhang G2.1.2 - Kontrollierte Bereiche) Zur Erzielung eineshohen Sicherheitsniveaus MÜSSEN verschiedene Kontrollstufen implementiert werden.Hierdurch lässt sich die Effizienz der physischen Sicherheitsmaßnahmen für die vomDienstbetreiber verwalteten Systeme optimieren und der unbefugte Zugriff, die Beschädigungder Systeme bzw. die Unterbrechung von Services verhindern.Der Kontrollierte Bereich wird wiederum in den geschützten Bereich und den Sicherheitsbereichunterschieden. Zur genaueren Unterscheidung siehe Tabelle in G2.1.2Bei Sicherheitsbereichen handelt es sich um die Bereiche mit dem höchsten Sicherheitsniveau.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 560 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 53:Typen von EinsatzumgebungenNr. Kürzel Umgebungstyp Realisierung SchutzU1U_SC(SC = smardcard)Sicherheitsmodul Chipkarte allgemeiner BereichU2 U_SC_prot Sicherheitsmodul Chipkarte geschützter BereichU3 U_TPM Sicherheitsmodul TPM allgemeiner BereichU4 U_TPM_prot Sicherheitsmodul TPM geschützter BereichU5 U_HSMg Sicherheitsmodul HSM allgemeiner BereichU6 U_HSM_prot Sicherheitsmodul HSM geschützter BereichU7U_OP_pub(OP= operating Env.)Büro/Praxis/Apotheke/StationZugänglicherBereichGerät geschlossen/ohne AufsichtU8U_OP_SV(SV = Supervision)Büro/Praxis/Apotheke/StationBereich unterAufsichtunter Aufsichtoder einfacherZugangskontrolleU9U_OP_PC(PC = PermanentControl)Büro/Praxis/Apotheke/StationZugänglicherBereichunter ständigerKontrolleU10 U_OP_batchsig Büro/Praxis/Apotheke/StationBesondersgesicherteUmgebung fürStapelsignaturHBA unter VerschlussU11 U_Home Home nicht zugänglicherBereichRaum unter Verschluss,persönlicheVerantwortungU12U_DC(DC = data center)RechenzentrumallgemeinerBereichU13 U_DC_Prot Rechenzentrum kontrollierterBereichU14 U_DC_Sec Rechenzentrum kontrollierterBereichgeschützter BereichSicherheitsbereichgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 561 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 54: Sicherheitsstufen physikalische Sicherheit der GeräteNr. Kürzel SchutzG0 closed Gerät verschlossenG1 TE (Tamper-evident) Gerät verschlossen, Angriffe erkennbarG2G2TD (Tamper detection)TR(Tamper Resistance)Gerät verschlossen, Angriff wird erkannt und gemeldetGerät verschlossen, Autom. Schutz gegen AngriffeF4.4 - TransportartenGenauso wichtig wie die Einsatzumgebungen sind zum Beschreiben des Lebenszyklusvon Schlüsselmaterial die Arten des Transports.Tabelle 55: Arten des Transports von SchlüsselmaterialNr. Umgebungstyp Realisierung SchutzT1 Postweg allgemeiner PostversandT2 kontrollierter Postversand EinschreibenT3 kontrollierter Postversand Post-IdentverfahrenT4 Werttransport besondere Bestimmungenfür die betrauten PersonenSicherheitsumgebungenT5ElektronischerTransportÖffentliches NetzPayload verschlüsseltT6 Öffentliches Netz Alles verschlüsseltT7T8T9nicht öffentlich zugänglichesNetznicht öffentlich zugänglichesNetznicht öffentlich zugänglichesNetzUnverschlüsseltPayload verschlüsseltAlles verschlüsseltT10 gesichertes Netz UnverschlüsseltT11 gesichertes Netz Payload verschlüsseltT12 gesichertes Netz Alles verschlüsseltgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 562 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF4.5 – Zusammenfassung der AusgangsauforderungenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03134 S Krypto_Anwendung_01:SichereÜberprüfung der Gültigkeit derZertifikateA_03135 S Krypto_Anwendung_02: EvaluierteSAK und Chipkarte fürqualifizierte Signaturen.A_03136 S Krypto_Anwendung_03:Planmäßige UmschlüsselungA_03137 S Krypto_Anwendung_04: Übergangauf stärkere KryptoverfahrenA_03138 S Krypto_Anwendung_05:Umschlüsselung medizinischerDaten.A_03139 S Krypto_Betriebsumgebungen_01:Passive Erkennung materiellerAngriffe.A_03140 S Krypto_Betriebsumgebungen_02:Melden materieller AngriffeEs MUSS eine sichere Überprüfung der Gültigkeit der Zertifikategewährleistet werdenFür Qualifizierte Signaturen muss die SAK und die Chipkarte evaluiertsein, es werden Schlüssel und Zertifikate verwendet, dieausdrücklich für QES zugelassen sindDie planmäßige Umschlüsselung langfristig (> 1Jahr) gespeichertermedizinischer Daten und Dokumente MUSS vorgesehen werdenDie Infrastruktur muss für einen Übergang auf stärkere Kryptoverfahrenausgelegt sein. Insbesondere sind (z. B. auf Servern) gespeichertevertrauliche Daten bei einem solchen Übergang neu zuverschlüsseln und die alten Datensätze zu löschenUmschlüsselung medizinischer Daten eines Versicherten MUSSvorgesehen werdenTE Passive Erkennung materieller AngriffeDie Sicherheitsfunktionen müssen materielle Manipulationen, diedie Sicherheitsfunktionen bloßstellen können, eindeutig erkennen.Die Sicherheitsfunktionen müssen die Fähigkeit zum Feststellenerfolgter materieller Manipulationen der Geräte oder Elemente mitSicherheitsfunktionen bereitstellenTD Melden materieller AngriffeManagement des Benutzers oder der Rolle, der/die über das Eindringeninformiert wird.Management der Liste von Geräten, die den benannten Benutzeroder die Rolle über das Eindringen informieren sollen.AnhangF 4AnhangF 4AnhangF 4AnhangF 4AnhangF 4AnhangF 4AnhangF 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 563 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03141 S Krypto_Betriebsumgebungen_03:Widerstand gegen materielleAngriffeA_03142 S Krypto_RZ_Umgebung_01:kontrollierten BereichA_03143 S Krypto_Schlüssel_01: Zerstörungendgültig gesperrterSchlüssel.A_03144 S Krypto_Schlüssel_02: Prozesszur Schlüsselerzeugung.Die Sicherheitsfunktionen müssen materielle Manipulationen, diedie Sicherheitsfunktionen bloßstellen können, eindeutig erkennen.Die Sicherheitsfunktionen müssen die Fähigkeit zum Feststellenerfolgter materieller Manipulationen der Geräte oder Elemente mitSicherheitsfunktionen bereitstellen.Die Sicherheitsfunktionen müssen die Geräte und Elemente gemäßListe der Geräte/ Elemente für die aktives Erkennen erforderlichist, überwachen und einem benannten Benutzer oder einerbenannten Rolle melden, wenn materielle Manipulationen an Gerätenoder Elementen stattgefunden habenTR Widerstand gegen materielle AngriffeManagement der automatischen Reaktionen auf materielle Manipulationen.Die Sicherheitsfunktionen müssen Szenarien materieller Manipulationenvon der Liste von Geräten/Elementen widerstehen, indemdiese automatisch so reagieren, dass die Sicherheitspolicy nichtverletzt wirdNeben dem allgemeinen Bereich gibt es im Rechenzentrum den sogenannten kontrollierten Bereich (Genaueres siehe AnhangG2.1.2 - Kontrollierte Bereiche) Zur Erzielung eines hohen SicherheitsniveausMÜSSEN verschiedene Kontrollstufen implementiertwerden. Hierdurch lässt sich die Effizienz der physischen Sicherheitsmaßnahmenfür die vom Dienstbetreiber verwalteten Systemeoptimieren und der unbefugte Zugriff, die Beschädigung der Systemebzw. die Unterbrechung von Services verhindernZerstörte (Endgültig gesperrte) Schlüssel: Der Schlüssel ist endgültiggesperrt, er DARF NICHT mehr verwendet werden undSOLLTE sicher in allen Komponenten zerstört werdenErzeugungist der Prozess, einen Schlüssel zu erzeugen. Der SchlüsselMUSS dabei nach bestimmten Vorgaben erzeugt werden. SoweitAnhangF 4AnhangF 4AnhangF 4AnhangF 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 564 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03145 S Krypto_Schlüssel_03: Prozesszur Schlüsseldeaktivierung.A_03146 S Krypto_Schlüssel_04: DienstSchlüssel-AbleitungA_03147 S Krypto_Schlüssel_05: DienstSchlüsselsuspendierung:wie möglich SOLL der Prozess Tests enthalten, die die Einhaltungder Vorgaben überprüfenDeaktivierungdieser Prozess schränkt den Gebrauch eines Schlüssels ein. DerSchlüssel kann nicht mehr für kryptographische Operationen verwendetwerden. Dies MUSS geschehen, wenn die Gültigkeit desSchlüssel ausgelaufen ist oder weil der Schlüssel aufgrund einesEreignisses suspendiert und gesperrt wurdeKMS 7 Schlüssel-Ableitung:Der Dienst Schlüsselableitung erstellt eine potentiell große Anzahlvon Schlüsseln unter Benutzung eines geheimen Originalschlüssels,genannt Ableitungsschlüssel, nicht geheimen veränderlichenDaten und mit einem Transformationsprozess (der nicht immergeheim sein muss). Das Ergebnis dieses Prozesses ist der abgeleiteteSchlüssel. Der Ableitungsschlüssel erfordert besonderenSchutz. Der Ableitungsprozess MUSS unumkehrbar und nichtvorhersehbarsein um sicherzustellen, dass die Kompromittierungeines abgeleiteten Schlüssels nicht den Ableitungsschlüssel oderandere abgeleitete Schlüssel kompromittiert.KMS 9 Schlüsselsuspendierung:Wenn die Kompromittierung eines Schlüssels bekannt ist odervermutet wird, stellt der Dienst Schlüsselsuspendierung die sichereDeaktivierung des Schlüssels sicher. Der Dienst ist auch fürSchlüssel, deren Gültigkeit abgelaufen ist, notwendig. Schlüsselsuspendierungwird auch dann angewandt, wenn sich die Rahmenbedingungenbeim Schlüsselinhaber ändern. Nach der Suspendierungkann der Schlüssel nur eingeschränkt benutzt werden(In der Regel nicht mehr um zu verschlüsseln oder zu signieren,aber der Schlüssel darf gebraucht werden um zu entschlüsselnoder zu verifizieren). Der Grad der Suspendierung MUSS genaubeschrieben werden, wie auch die Umstände, unter denen derAnhangF 4AnhangF 4AnhangF 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 565 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03148STitel Beschreibung Rel. QuelleKrypto_Schlüssel_06: Verteilungund Verwendung derSchlüssel gemaß Minimalitätsprinzip.Schlüssel wieder aktiviert werden kann.Der Dienst Schlüsselsuspendierung wird kaum bei zertifikatbasiertenSchemata angewandt, wo der Lebenszyklus der Schlüsseldurch die Gültigkeit der Zertifikate geregelt wirdDie Verteilung und Verwendung der Schlüssel MUSS auf das absolutnotwendige Maß eingeschränkt werden, um die Möglichkeitenzur Kompromittierung von Schlüsseln zu minimieren und potentielleSchäden zu beschränken. Die Gültigkeitsdauer derSchlüssel ist zu begrenzen und geplante Schlüsselwechsel beiAblauf der Gültigkeit sowie ungeplante Schlüsselwechsel als Notfall-und Ersatzmaßnahme sind vorzusehenAnhangF 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 566 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF5 - Lebenszyklus des eingesetzten SchlüsselmaterialsDie Sicherheit aller § 291a Anwendungen und der in der Telematikinfrastruktur übertragenenoder gespeicherten medizinischen Dokumente und personenbezogener Daten beruhtauf der Verwendung der korrekten kryptographischen Methoden und der dabei eingesetztenSchlüssel. Aufgrund dieser zentralen Funktion erfordert die Verwaltung der Schlüsselmindestens den Schutzbedarf der sensitivsten Anwendung. Dies beinhaltet den Schutzvor Fehlbedienung, Innentätern und unberechtigtem Eindringen oder Ausspähen desKeymanagement-Systems. Daher MÜSSEN die kryptographischen Anforderungen unddie festgelegten Algorithmen der gematik vom Key-Management mindestens erfüllt bzw.umgesetzt werden oder sogar ein höheres Sicherheitsniveau erreichen. Der Betreibergewährleistet die Integrität, die Verbindlichkeit und die Vertraulichkeit der eingesetztenSchlüssel sowie die Verfügbarkeit seiner eigenen und der ihm anvertrauten Schlüssel undRessourcen. Dies gilt sowohl auf den eigenen Systemen als auch auf den Systemen, dieder Verantwortung des Unternehmens unterstehen.Diese Mindestanforderungen MÜSSEN im kompletten Lebenszyklus der Schlüssel eingehaltenwerden. Der Lebenszyklus eines Schlüssels umfasst nach ISO 11770 Erzeugung(Generation), Aktivierung (Activation) mit Installation, optional Zertifikatserzeugung,Schlüsselableitung, Schlüsselverteilung, Registrierung des Schlüssels/Zertifikats, Speicherungdes Schlüssels, sowie Deaktivierung (Deactivation), Reaktivierung (Reactivation)und Zerstörung des Schlüssels (Destruction).Die Aspekte ergänzt um die allgemeine Mindestanforderungenund Anforderungen zu Schlüsselanwendung, Schlüsselwechsel undbetriebliche Anforderungen werden in diesem Abschnitt behandelt. In Abbildung 42: Lebenszyklusder Schlüssel und die Übergänge zwischen den Zuständen eines Schlüsselssind die Zustände im Lebenszyklus eines Schlüssels dargestellt:• Noch nicht aktiv: Der Schlüssel ist erzeugt, aber noch nicht aktiviert.• Aktiv: In der Betriebsphase wird der Schlüssel gebraucht, um Informationkryptographisch zu bearbeiten• Post aktiv: Der Schlüssel darf nicht mehr für kryptographische Aktivitäten gebrauchtwerden. Der Grad der Suspendierung MUSS genau beschrieben werden,wie auch die Umstände, unter denen der Schlüssel ggf. wieder aktiviertwerden kann.• Zerstört (Endgültig gesperrt): Der Schlüssel ist endgültig gesperrt, er darfnicht mehr verwendet werden und SOLLTE sicher in allen Komponenten zerstörtwerden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 567 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZerstörungEndgültigsperrenReaktivierungNochnichtaktivAktivPostAktivErzeugung Aktivierung Deaktivierung ZerstörungZerstörtKompromittiertNotfallmaßnahmenInitialisierungsphaseBetriebsphaseNach-Betriebsphase ZerstörungsphaseAbbildung 42: Lebenszyklus der Schlüssel und die Übergänge zwischen den Zuständeneines SchlüsselsIn Abbildung 42 sind die Übergänge zwischen den Zuständen eines Schlüssels dargestellt• Erzeugung ist der Prozess, einen Schlüssel zu erzeugen. Der SchlüsselMUSS dabei nach bestimmten Vorgaben erzeugt werden. Soweit wie möglichSOLL der Prozess Tests enthalten, die die Einhaltung der Vorgaben überprüfen.• Aktivierung, dieser Prozess macht einen Schlüssel gültig. Der Schlüsselkann nun in kryptographischen Operationen operativ entsprechend seinemVerwendungszweck eingesetzt werden.• Deaktivierung, dieser Prozess schränkt den Gebrauch eines Schlüssels ein.Der Schlüssel kann nicht mehr für kryptographische Operationen verwendetwerden. Dies muss geschehen, wenn die Gültigkeit des Schlüssel ausgelaufenist oder weil der Schlüssel aufgrund eines Ereignisses suspendiert undgesperrt wurde.• Reaktivierung, dieser Prozess macht einen Schlüssel wieder voll gültig. DerSchlüssel kann nun wieder in den für diesen Schlüssel erlaubten kryptographischenOperationen eingesetzt werden.• Zerstörung beendet den Lebenszyklus des Schlüssels. Das beinhaltet die logischeendgültige Sperrung und die physikalische Zerstörung des Schlüssels.• Kompromittiert: In jeder Phase kann ein Schlüssel kompromittiert werden.Dann sind die für diesen Fall definierten Notfallmaßnahmen (siehe Kap. F7)einzuleiten - z. B. die betroffenen Karten sperren und die Karten tauschen.Nach der Durchführung der Notfallmaßnahmen ist der Schlüssel zu zerstören.Die betrachteten Übergänge beinhalten eine Anzahl von Schlüsselmanagement-Diensten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 568 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• KMS 1. Schlüssel-Erzeugung: Schlüsselerzeugung ist ein Dienst, der aufgerufenwird um auf sicherem Wege Schlüssel für einen bestimmten kryptographischenAlgorithmus zu erzeugen. Dies erfordert, dass die Schlüsselerzeugungnicht manipulierbar sein darf und dass die Schlüssel nicht vorhersagbarund in der vorgeschriebenen statistischen Verteilung erzeugt werdenmüssen.Diese statistischen Verteilungen sind vom verwendeten kryptographischenSchlüssel erzwungen und von geforderten Niveau des kryptographischenSchutzes.Die Erzeugung mancher Schlüssel, z. B. Master-Keys, erfordert besondereSorgfalt und besonderen Schutz, da die Kenntnis dieser Schlüssel Zugriff aufdie verbundenen oder abgeleiteten Schlüssel ermöglicht.• KMS 2. Schlüssel-Registrierung: Der Dienst Schlüsselregistrierung verbindeteinen Schlüssel mit einer Entität.Er wird von einer Registrierungsinstanz angeboten und wird üblicherweise angewandt,wenn symmetrische Kryptographie benutzt wird. Wenn eine Entitäteinen Schlüssel registrieren lassen will, kontaktiert sie die Registrierungsinstanz.Schlüsselregistrierung beinhaltet eine Registrierungsanforderung undeine Bestätigung dieser Registrierung. Eine Registrierungsinstanz pflegt einRegister von Schlüsseln und die dazugehörigen Informationen in hinreichendsicherer Art und Weise.• KMS 3. Erzeugung eines Schlüssel-Zertifikats: Der Dienst Registrierungeines Erzeugung eines Schlüssel-Zertifikats verbindet einen öffentlichenSchlüssel mit einer Entität und wird von einer Zertifizierungsinstanz betrieben.Wenn eine Anforderung zur Schlüssel-Zertifizierung akzeptiert, erzeugt dieZertifizierungsinstanz ein Schlüssel-Zertifikat.• KMS 4 Schlüssel-Verteilung: Die Schlüsselverteilung ist eine Menge vonProzessen, um Schlüssel-Management-Information-Objekte (in der RegelSchlüssel) sicher zu autorisierten Entitäten zu verteilen.• KMS 5 Schlüssel-Installation: Der Dienst Schlüsselinstallation ist immer vordem Gebrauch eines Schlüssels notwendig. Bei der Schlüsselinstallation wirdder Schlüssel in einer Art und Weise eingebracht, die den Schlüssel vor Kompromittierungschützt.• KMS 6 Schlüssel-Speicherung: Der Dienst Schlüsselspeicherung bietet sichereSpeicherung für Schlüssel im laufenden oder kurz bevorstehendenGebrauch oder auch für Backup-Schlüssel. Es ist üblicherweise von Vorteil,physikalisch getrennte Schlüsselspeicher vorzusehen. Zum Beispiel sichertein Schlüsselspeicher die Vertraulichkeit und Integrität von Schlüsselmaterialoder die Integrität von öffentlichen Schlüsseln. Speicherung kann in allenSchlüsselzuständen im Lebenszyklus eines Schlüssels vorkommen.• KMS 7 Schlüssel-Ableitung: Der Dienst Schlüsselableitung erstellt eine potentiellgroße Anzahl von Schlüsseln unter Benutzung eines geheimen Originalschlüssels,genannt Ableitungsschlüssel, nicht geheimen veränderlichenDaten und mit einem Transformationsprozess (der nicht immer geheim seinmuss). Das Ergebnis dieses Prozesses ist der abgeleitete Schlüssel. Der Ableitungsschlüsselerfordert besonderen Schutz. Der Ableitungsprozess MUSSunumkehrbar und nicht-vorhersehbar sein um sicherzustellen, dass die Kompromittierungeines abgeleiteten Schlüssels nicht den Ableitungsschlüssel o-der andere abgeleitete Schlüssel kompromittiert.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 569 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• KMS 8 Schlüssel-Archivierung Schlüsselarchivierung ist der Prozess,Schlüssel nach Ablauf der Nutzung sicher und langfristig zu speichern. Fürdiesen Dienst ist die Anwendung des Dienstes “Schlüsselspeicherung” denkbar,es bestehen aber verschiedene Anforderungen, so dass auch verschiedeneImplementierungen denkbar sind. So könnte z. B. die Schlüsselarchivierungoffline realisiert werden. Archivierte Schlüssel können noch lange nachdem normalen Gebrauch der Schlüssel benötigt werden, um bestimmte Ansprücheabzuklären• KMS 9 Schlüsselsuspendierung: Wenn die Kompromittierung eines Schlüsselsbekannt ist oder vermutet wird, stellt der Dienst Schlüsselsuspendierungdie sichere Deaktivierung des Schlüssels sicher. Der Dienst ist auch fürSchlüssel, deren Gültigkeit abgelaufen ist, notwendig. Schlüsselsuspendierungwird auch dann angewandt, wenn sich die Rahmenbedingungen beimSchlüsselinhaber ändern. Nach der Suspendierung kann der Schlüssel nureingeschränkt benutzt werden (In der Regel nicht mehr um zu verschlüsselnoder zu signieren, aber der Schlüssel darf gebraucht werden um zu entschlüsselnoder zu verifizieren). Der Grad der Suspendierung MUSS genaubeschrieben werden, wie auch die Umstände, unter denen der Schlüssel wiederaktiviert werden kann.Der Dienst Schlüsselsuspendierung wird kaum bei zertifikatbasierten Schemataangewandt, wo der Lebenszyklus der Schlüssel durch die Gültigkeit derZertifikate geregelt wird.• KMS 10 Aufheben der Registrierung eines Schlüssels: Der Dienst Aufhebender Registrierung eines Schlüssels wird von einer Registrierungsinstanzangeboten, die die Verbindung des Schlüssels mit einer Entität aufhebt.Er ist Teil des Schlüssel-Zerstörungsprozesses. Wenn eine Entität die Registrierungeines Schlüssels aufheben lassen will, kontaktiert sie die Registrierungsinstanz.• KMS11 Schlüssel-Zerstörung: Der Dienst Schlüsselzerstörung bietet einenProzess an für die sichere Zerstörung von Schlüsseln, die nicht mehr gebrauchtwerden. Zerstörung eines Schlüssels bedeutet, alle Einträge desSchlüsselmanagement-Informationsobjekts zu löschen, so dass nach der Zerstörungkeine Information übrig bleibt, um den zerstörten Schlüssel wiederherzustellen.Dies wird gemacht, um die Zerstörung alle archivierten Kopien sicherzustellen.Dennoch, bevor archivierte Schlüssel zerstört werden, sollte eine Prüfung gemachtwerden um sicherzustellen, dass kein Material, das durch dieseSchlüssel geschützt wird, jemals wieder gebraucht wird.NOTIZ: Es können Schlüssel außerhalb von elektronischen Geräten oder Systemengespeichert sein. Das erfordert zusätzliche administrative Maßnahmen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 570 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturInitialisierungsphaseBetriebsphase Nach-Betriebsphase ZerstörungsphaseNochnichtaktivAktivPostAktivZerstörtKarten-AusgabeSchlüssel-ErzeugungKarten-EinzugSchlüssel-DeaktivierungKarten-EntsorgungSchlüssel-ZerstörungKartenherausgeberTrustcenterKryptodevicesKarten, HSMs,sichere UmgebungKryptodevicesKarten, HSMs,sichere UmgebungKryptodevicesKarten, HSMsSchlüssel-AbleitungSchlüssel-RegistrierungZertifikats-RegistrierungSchlüssel-SpeicherungSchlüssel-VerteilungSchlüssel-InstallationSchlüssel-AbleitungSchlüssel-RegistrierungZertifikats-RegistrierungSchlüssel-SpeicherungSchlüssel-VerteilungSchlüssel-SpeicherungSchlüssel-ArchivierungSchlüssel-ArchivierungAbbildung 43: Betriebsphasen im Schlüssellebenszyklus und Keymanagement-Dienstenach ISO 11770lTabelle 56: Übergänge zwischen den Zuständen eines Schlüssels realisiert durch Schlüsselmanagementdienste(siehe [ISO11770])Übergang Schlüsselmanagementdienste BemerkungenErzeugung Schlüssel-Erzeugung obligatorischSchlüssel-RegistrierungErzeugung eines Schlüssel ZertifikatsSchlüssel-VerteilungOptional, entweder hier oderbei der AktivierungoptionaloptionalSchlüssel-SpeicherungoptionalAktivierung Erzeugung eines Schlüssel Zertifikats optionalSchlüssel-VerteilungSchlüssel-AbleitungSchlüssel-InstallationoptionaloptionalobligatorischSchlüssel-SpeicherungRegistrierung eines SchlüsselsoptionalDeaktivierung Schlüssel-Speicherung optionalOptional, entweder hier oderbei der ErzeugungSchlüssel-ArchivierungSchlüssel-SuspendierungOptional, entweder hier oderbei der Zerstörungobligatorischgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 571 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturÜbergang Schlüsselmanagementdienste BemerkungenReaktivierung Erzeugung eines Schlüssel Zertifikats optionalSchlüssel-VerteilungSchlüssel-AbleitungSchlüssel-InstallationSchlüssel-SpeicherungoptionaloptionalobligatorischoptionalZerstörung Schlüssel-Deregistrierung Obligatorisch; wenn registriert.Schlüssel-ZerstörungSchlüssel-ArchivierungobligatorischOptional, entweder hier oderbei der Deaktivierunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 572 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF5.1 - Key-Management-Infrastrukturen und Verantwortlichkeiten für die TelematikinfrastrukturIn der nachfolgenden Abbildung 44: Verantwortlichkeiten und Komponenten der Key-Management-Infrastruktur der Telematikinfrastruktur im Gesundheitswesen. sind dieKomponenten und Verantwortlichkeiten für das Key-Management der Schlüssel zumZugriff auf medizinische Dokumente sowie die Dienste und Komponenten in der Telematikinfrastrukturim Überblick dargestellt. Diese Verantwortlichkeiten und Komponentenbeinhalten alle Schlüssel 54 für fortgeschrittene Signaturen, Authentisierung, Verschlüsselung,C2C, C2S auf Anwendungs-, Transport- und Netzebene der Telematikinfrastruktur.gematikzentrale Aufsichtsstelle(COA)TrustcenterRootTrustcenterKartenherausgeberSchlüssel-Bearbeitungseinrichtungen(KPFs)TSL, TKLDir., OCSPKDCUFS, PIPRegistrierungsstellenSperr-HotlinePoliciesRegisterDienst-Agenten(SA)ldapClientOCSPClientKDCClientRAClientClient Knoten(CN)HPCTelematik-InfrastruktureHCFachdienst, HSM, Broker, Gateway, Konnektor, Karte Karteninhaber, med. Institution, Betreiber, HerstellerBenutzerinstanzen(UE)Abbildung 44: Verantwortlichkeiten und Komponenten der Key-Management-Infrastrukturder Telematikinfrastruktur im Gesundheitswesen.Die gematik ist die zentrale Aufsichtsstelle (Central Oversight Authority COA) für die Key-Management-Infrastruktur der Telematik im Gesundheitswesen. Die gematik legt dazu dieübergreifenden Mindestanforderungen an die Komponenten und Betreiber der KMI fest,um das notwendige Sicherheitsniveau der Telematikinfrastruktur zu gewährleisten (siehe§291b, Abs. 1 und AS_EP_01), und hat dazu die nachfolgenden Aufgaben und Verantwortlichkeiten:54 Die Regelungen für die qualifizierte Signatur aus SigG, SIGV und Vorgaben der BNetzA werdenfür die Verwendung qualifizierter Signaturen in der Telematikinfrastruktur im Gesundheitswesenübernommen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 573 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Koordiniert die spezifischen Krypto-Konzepte und Regelungen für die einzelnenKomponenten und Betreiber der KMI der Telematikinfrastruktur und legtdie einzuhaltenden Mindestanforderungen für den Schutz der Schlüssel normativfest, die für den Zugriff auf medizinische Dokumente, Dienste und Komponentender Telematikinfrastruktur verwendet werden.Dies ist beispielsweise:oGemeinsame Zertifizierungsrichtlinien für PKI (siehe gematik Website)• Stellt übergreifende Systeminformationen bereit, die von den Dienst-Agentenbenötigt wird. Dies ist beispielsweise:oDas Root-Trustcenter für die C2C Authentisierung• Stellt für die Telematikinfrastruktur Daten bereit. Beispiele sind:oooProdukt- und Registrierungsinformationen und die veröffentlichte Produktzulassung(siehe gematik Website, TCL) ,Directory Daten z. B. über die zugelassenen Dienste (z. B. TSL)übergreifende Informationen über kompromittierte Schlüssel und ZertifikateF5.1.1 - Allgemeine Anforderungen und einzuhaltende MindeststandardsDie Verteilung und Verwendung der Schlüssel MUSS auf das absolut notwendige Maßeingeschränkt werden, um die Möglichkeiten zur Kompromittierung von Schlüsseln zuminimieren und potentielle Schäden zu beschränken. Die Gültigkeitsdauer der Schlüsselist zu begrenzen und geplante Schlüsselwechsel bei Ablauf der Gültigkeit sowie ungeplanteSchlüsselwechsel als Notfall- und Ersatzmaßnahme sind vorzusehen.Der Sinn einer Schlüsselhierarchie liegt darin, für kryptographisches Material oder kryptographischeSchlüssel einer Stufe äquivalente sicherheitstechnische Mindestanforderungenzur Einhaltung des notwendigen Sicherheitsniveaus festzulegen. Es ist damit zu verhindern,dass durch erfolgreiche Angriffe auf Teile des Systems (z. B. einzelne Schlüssel,Karten oder Sicherheitsmodule) das Gesamtsystem oder größere Teile der TI betroffenwerden. Ein Schlüssel K H1 hat eine höhere Stufe als ein Schlüssel K H2 , wenn K H2 mit Hilfevon K H1 verschlüsselt, signiert oder abgeleitet wird. Die Mindestanforderungen ergebensich durch die Zuordnung zur Schlüsselhierarchie bzw. durch die durch diese Schlüsselgeschützten Daten der Versicherten:• Stufe 0: Kryptographisches Material oder kryptographische Schlüssel, diekeine unverschlüsselten medizinischen Dokumente einer Person sichern. Beispielsweisesind in diese Stufe einzuordnen:oDie Schlüssel zur Sicherung einer Session der Netzwerkverbindung zwischenzwei Sicherheitszonen.• Stufe 1: Kryptographisches Material oder kryptographische Schlüssel, die dazuverwendet werden, ein einzelnes Informationsobjekt oder eine Aktion einerPerson in der Telematikinfrastruktur zu sichern. Beispielsweise sind in dieseStufe einzuordnen:oDie Objekt-Verschlüsselungsschlüssel, die in den Objekttickets gespeichertsind.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 574 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Stufe 2: Kryptographisches Material oder kryptographische Schlüssel, die dazuverwendet werden, einen Teil der Informationsobjekte oder Aktionen einerPerson in der Telematikinfrastruktur zu sichern. Beispielsweise sind in dieseStufe einzuordnen:oDie Schlüssel zur versichertenindividuellen Verschlüsselung der Einträgeeines Versicherten in einem Fachdienst.• Stufe 3 55 : Kryptographisches Material oder kryptographische Schlüssel, diedazu verwendet werden, alle Informationsobjekte oder Aktionen einer Personin der Telematikinfrastruktur zu sichern oder Schlüssel der darunter liegendenStufen zu sichern. Beispielsweise sind in diese Stufe einzuordnen:oDie Authentisierungs- und Verschlüsselungsschlüssel eines Versichertenauf der Gesundheitskarte.o Die PIN eines Versicherten, die den Zugriff auf Schlüssel zur Nutzung z. B.der freiwilligen Anwendungen freigibt.ooDie Authentisierungs- und Verschlüsselungsschlüssel eines Leistungserbringerszum Zugriff auf die medizinischen Daten der Versicherten und derSignaturschlüssel zur Signatur der erzeugten medizinischen Dokumente.Die PIN eines Leistungserbringers für einen HBA oder SMC, die z. B. überdie C2C Authentisierung der Zugriff auf Pflichtanwendungen ermöglicht.• Stufe 4 56 : Kryptographisches Material bzw. kryptographische Schlüssel, diedazu verwendet werden die Sicherheitsobjekte der Stufe 3 (einer Gruppe vonPersonen) zu sichern. Beispielsweise sind in diese Stufe einzuordnen:oooDie PIN-Schlüssel eines Kartenherausgebers, die bei der Kartenproduktionverwendet werden (siehe Anhang E).Ableitungsschlüssel (KGK) für die Erzeugung kartenindividueller Schlüssel,z. B. für die Authentisierung C2S beim VSDD oder CAMSDie CA-Schlüssel für die Erstellung der personenbezogenen Zertifikate derStufe 3 (Authentisierungs-, Verschlüsselungs-, oder Signatur-Zertifikate)• Stufe 5 Kryptographisches Material bzw. kryptographische Schlüssel, diedazu verwendet werden, die Sicherheitsobjekte der darunter liegenden Stufezu sichern. Beispielsweise sind in diese Stufe einzuordnen:55 Da die Datenhoheit der medizinischen Daten der § 291a Anwendungen beim Versicherten liegt,ist die Verwendung dieser Schlüssel bzw. des kryptographischen Materials in der alleinigen Verfügungsgewaltdes Versicherten bzw. der von ihm persönlich Beauftragten. Durch die Prozessgestaltungenund die organisatorischen und technischen Schutzmassnahmen ist jegliche Verwendungdieser Schlüssel ohne Einverständnis und Autorisierung des Versicherten sicherzustellen und dieWirksamkeit dieser Maßnahmen ist in einem spezifischen Sicherheitskonzept des jeweiligenBetreibers eines Dienstes oder Komponente nachzuweisen.56 Ab dieser Stufe sind nur noch Schlüssel zum Schutz von Schlüsseln vorgesehen. KryptographischeSchlüssel bzw. kryptographischen Materials, die dazu verwendet werden alle Informationsobjektealler Versicherten in allen Fachdiensten in der Telematikinfrastruktur zu sichern darf es aufgrundder Datenhoheit der Versicherten nicht geben. Beispiele wären u. A. der Treuhänderschlüsseleines Treuhänders zum Key-Escrowing der Verschlüsselungsschlüssel zum Datenerhalt für alleVersicherten.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 575 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturooPrivate Schlüssel der Root-CAs für die Authentisierungs-, Autorisierungs-,oder Signaturschlüssel.Private Schlüssel zum Signieren der TSL, TCL für die Zuordnung von CAs,Komponentengruppen zur Telematikinfrastruktur.Auf der Basis der nachfolgenden Mindestanforderungen sind für die Realisierung bestpractices für die Schlüsselverwaltung (siehe [BSI-GK], [SP800-57]) zu verwendenNr.SP_KEY_ALL_1SP_KEY_ALL_2SP_KEY_ALL_3SP_KEY_ALL_4Allgemeine Anforderungen an das KeymanagementVertraulichkeitDie verwendeten kryptographischen Verfahren zum Schutz derSchlüssel MÜSSEN mindestens den Mindestanforderungen der gematikgenügen, um den Schutz der Vertraulichkeit der Schlüsselwährend des Transports, der Speicherung sowie des Gebrauchs vornicht autorisierter Aufdeckung, Weitergabe und Nutzung zu gewährleisten.Integrität und AuthentizitätDie Integrität der Schlüssel MUSS gewährleistet werden. Das betrifftden Schutz vor Änderung und Ersetzung der Schlüssel. Außerhalbgeschützter Hardware sind Schlüssel und die ihnen zugeordneteInformationen integritätsgeschützt zu speichern und zu übertragen.VerfügbarkeitEine hohe Serviceverfügbarkeit von Online-Anwendungen der Telematikinfrastrukturist sicherzustellen. Die Verfügbarkeit dieser Anwendungendarf durch den Zugriff auf die kryptographischen Methodenund die notwendigen Schlüssel nicht eingeschränkt werden.Backup der Schlüssel: Um die Handhabbarkeit des Schlüsselverwaltungssystemsund die Verfügbarkeit von Schlüsseln von Online-Anwendungen auch nach Fehlersituationen sicherzustellen, ist einProzess zu etablieren, um diese Schlüssel (falls zulässig) oder neueSchlüssel innerhalb eines definierten Zeitraums (wieder) zur Verfügungzu stellen.Archivierung von Schlüsseln zur Rekonstruktion historischerDaten. Bei Ablösung eines Schlüssels SOLL dieser nicht sofort gelöscht,sondern deaktiviert werden. Deaktivierte Schlüssel sollten füreinen Übergangszeitraum archiviert werden, so dass ggf. auf siezurückgegriffen werden kann. Nach Ablauf des Übergangszeitraumsmüssen die Schlüssel dann physikalisch zerstört (gelöscht) werden.Nachvollziehbarkeit:Die Nachvollziehbarkeit aller relevanten Aktivitäten im System isteine unabdingbare Forderung, sowohl aus entsprechenden gesetzlichenbzw. geschäftlichen Anforderungen, wie auch aus Eigeninteressedes jeweiligen Unternehmens. Der für eine Aktion Verantwortlichemuss eindeutig festgestellt werden können. Die Benutzer desSchlüsselverwaltungssystems und die Nutzer des Schlüsseldiensteskönnen für ihre Handlungen verantwortlich gemacht und damit auchvor ungerechtfertigten Beschuldigungen geschützt werden. Ebensogematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 576 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_ALL_5SP_KEY_ALL_6SP_KEY_ALL_7Allgemeine Anforderungen an das Keymanagementmuss Beweismaterial für Streitfälle erstellt und sicher verwahrt werden.Dies betrifft beim Keymanagement die Nachweisbarkeit der Schlüsselverwendungoder die Nachvollziehbarkeit der vorgenommenHandlungen, vonοοim Einsatz befindlichen Schlüsseln ab Stufe 1 mit Verteilungder Schlüssel, Empfänger, vorgesehener und tatsächlicherGültigkeitszeitraum, Festlegung Einsatzzweck des Schlüssels.mit einem Schlüssel bearbeiteten bzw. geschützten Objekten(z. B. verschlüsselten Daten, wie PINs, PUKs, …]).Die Verteilung und Verwendung der Schlüssel MUSS auf das absolutnotwendige Maß eingeschränkt werden, um die Möglichkeiten zurKompromittierung von Schlüsseln zu minimieren und potentielleSchäden zu beschränken.Minimale Verteilung: Eine Weitergabe DARF nur an berechtigteOrganisationen und Personen erfolgen und es MUSS sichergestelltwerden, dass nur die Nutzung der freigegebenen Anwendungenmöglich ist.Gemeinsame symmetrische Schlüssel dürfen nur bei direkt beteiligtenKommunikationspartnern operativ verwendet werden. SymmetrischeSession Keys zur Sicherung von Transaktionen SOLLEN nureinmalig verwendet werden.Schlüsseltrennung und minimale Funktionalität: Für jede Anwendungoder kryptographische Funktion sind eigene Schlüssel zudefinieren. Ein Schlüssel DARF nur entsprechend seinem Verwendungszweckeingesetzt werden.Beschränkte Gültigkeitsdauer: Die zeitliche Gültigkeit von SchlüsselnMUSS eingeschränkt sein. Es MUSS ein regelmäßiger Schlüsselwechselaller Schlüssel erfolgen. Für jeden Schlüssel MÜSSENZeiträume definiert sein, in denen ein Schlüssel gültig ist. Nach Ablaufdieser Zeitspanne MÜSSEN die Schlüssel gewechselt werdenund die Verwendung abgelaufener Schlüssel MUSS verhindert werden.Ein Schlüssel, der andere Schlüssel beglaubigt oder verschlüsselt,MUSS mindestens die kryptographische Stärke der von ihm geschütztenSchlüssel aufweisen. Falls es sich dabei um Schlüssel fürunterschiedliche Algorithmen handelt, muss dies sinngemäß für dieeffektiven Schlüssellängen gelten.Die Kompromittierung von Schlüsseln niedrigerer HierarchiestufenDARF NICHT oder nur unter einem Aufwand, der dem Brechen deszugrunde liegenden Verschlüsselungsalgorithmus entspricht, zueiner Kompromittierung von Schlüsseln höherer Hierarchiestufenführen.SP_KEY_ALL_8 Nur Schlüssel der untersten Hierarchiestufen (Stufe 1 – Stufe 3)dürfen zum Schutz von Daten, die selbst kein Schlüsselmaterialsind, verwendet werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 577 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDurch die Einordnung in die Schlüsselhierarchie sind gleichartige Sicherheitsmaßnahmenfür alle Schlüssel in einer Hierarchiestufe anzuwenden. Die nachfolgenden Anforderungensind nach dem Maximumprinzip abgeleitet. Spezifischere Mindestanforderungen für eineffizientes Schlüsselmanagement angepasst an die Risiken und den Schutzbedarf einzelnerSchlüsselarten sind in zukünftigen Versionen zu erwarten.Nr.SP_KEY_HI_1SP_KEY_HI_2SP_KEY_HI_3Allgemeine Anforderungen an Schlüssel einer HierarchiestufeEinheitliche SchutzmechanismenGeheimes kryptographisches Material oder geheime kryptographischeSchlüssel einer Hierarchiestufe SOLLEN einheitliche sicherheitstechnischeMindestanforderungen zur Einhaltung des notwendigenSicherheitsniveaus einhalten.Schlüssel des Versicherten:Da die Datenhoheit der medizinischen Daten der § 291a Anwendungenbeim Versicherten liegt, ist die Verwendung dieser Schlüsselbzw. des kryptographisches Material in der alleinigen Verfügungsgewaltdes Versicherten bzw. der von ihm persönlich Beauftragten.Durch die Prozessgestaltungen und die organisatorischen und technischenSchutzmassnahmen ist jegliche Verwendung dieser Schlüsselohne Einverständnis und Autorisierung des Versicherten zu verhindernund die Wirksamkeit dieser Maßnahmen ist in einem spezifischenKryptographiekonzept des jeweiligen Betreibers eines Dienstesoder Komponente nachzuweisen.Erzeugung der Schlüssel des Versicherten(siehe SP_KEY_HI_1)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent zu einem Trustcenter für qualifizierte Signaturen eingehaltenwerden.Die Betreiber MÜSSEN Abweichungen dokumentieren, die Risikenbewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwarten.SP_KEY_HI_4SP_KEY_HI_5Private Schlüssel einer CA(siehe SP_KEY_HI_1)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent für den privaten CA-Schlüssel in einem Trustcenter fürqualifizierte Signaturen eingehalten werden.Die Betreiber MÜSSEN Abweichungen dokumentieren, die Risikenbewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwarten.Private Schlüssel der Root-Trustcenter(siehe SP_KEY_HI_1)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent für den privaten Root-Schlüssel des Root-Trustcenter fürqualifizierte Signaturen eingehalten werden.Die Betreiber MÜSSEN Abweichungen dokumentieren, die Risikengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 578 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_HI_6Allgemeine Anforderungen an Schlüssel einer Hierarchiestufebewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwarten.Schlüssel der Bridge-CA(siehe SP_KEY_HI_1)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent für den privaten Root-Schlüssel des Root-Trustcenter fürqualifizierte Signaturen eingehalten werden.Die Betreiber MÜSSEN Abweichungen dokumentieren, die Risikenbewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwarten.F5.1.2 - Schlüssel-Erzeugung (Generation )ISO: Schlüsselerzeugung ist ein Dienst, der aufgerufen wird, um auf sicherem WegeSchlüssel für einen bestimmten kryptographischen Algorithmus zu erzeugen. Dies erfordert,dass die Schlüsselerzeugung nicht manipulierbar sein darf und dass die Schlüsselnicht vorhersagbar und in der vorgeschriebenen statistischen Verteilung erzeugt werdenmüssen.Diese statistischen Verteilungen sind vom verwendeten kryptographischen Schlüssel erzwungenund vom geforderten Niveau des kryptographischen Schutzes.Die Erzeugung mancher Schlüssel, z. B. Master-Keys, erfordert besondere Sorgfalt undbesonderen Schutz, da die Kenntnis dieser Schlüssel Zugriff auf die verbundenen oderabgeleiteten Schlüssel ermöglicht.Sämtliche kryptographischen Verfahren basieren auf der Gleichverteilung der Schlüsselund auf der Qualität des zugrunde liegenden Zufallszahlengenerators. Unabhängig vonder Schlüssellänge und der mathematischen bzw. algorithmischen Qualität eines Algorithmusbildet ein schlechter Zufallszahlengenerator die Grundlage für erfolgreiche kryptoanalytischeAngriffe. Die Mindestanforderungen der TR-03116 und der gematik sind einzuhalten.Nr.SP_KEY_CRE_1SP_KEY_CRE_2Anforderungen Schlüssel-ErzeugungGrundsätzlich können für die Erzeugung von Zufallszahlen physikalischeZufallszahlengeneratoren oder Pseudozufallszahlengeneratoreneingesetzt werden. Entsprechend des gewählten Generatorssind die Anforderungen gemäß [AIS 20] für Pseudozufallszahlengeneratorenund [AIS 31] für physikalische Zufallszahlengeneratoreneinzuhalten.Es wird dringend empfohlen, zur Schlüsselerzeugung einen physikalischenZufallszahlengenerator zu verwenden, Schlüssel der Hierachiestufen4 bis 5 und Schlüssel mit langer Lebensdauer (mehrals 3 Jahre) MÜSSEN von einem physikalischen Zufallszahlengeneratorerzeugt werden.Jeder Schlüssel MUSS mindestens eine Entropie von 100 Bit besitzen.Die Berechnung von Schlüsseln muss mit Hilfe eines kryptographischenAlgorithmus so erfolgen, dassgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 579 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_CRE_3SP_KEY_CRE_4Anforderungen Schlüssel-Erzeugungder berechnete Schlüssel ohne Kenntnis des für die Berechnungbenutzten Schlüssels nicht einfacher bestimmt werden kann als einzufällig erzeugter Schlüssel.aus der Kenntnis des berechneten Schlüssels und der übrigen Inputdatenkeine Informationen über den für die Berechnung benutztenSchlüssel abgeleitet werden können, ohne den zugrunde liegendenkryptographischen Algorithmus zu brechen.Alle Schlüssel müssen in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen erzeugt oder berechnetwerden, so dass sie nicht von Unbefugten ausgelesen odermanipuliert werden können.Die Systeme müssen jeden Versuch, einen Schlüssel unautorisiertzu erzeugen, verhindern.F5.1.3 - SchlüsselregistrierungISO: Der Dienst Schlüsselregistrierung verbindet einen Schlüssel mit einer Entität.Er wird von einer Registrierungsinstanz angeboten und wird üblicherweise angewandt,wenn symmetrische Kryptographie benutzt wird. Dazu wird beispielsweise jedem Schlüsselbei der Erzeugung ein systemweit eindeutiger Schlüsselname zugewiesen. Wenn eineEntität einen Schlüssel registrieren lassen will, kontaktiert sie die Registrierungsinstanz.Schlüsselregistrierung beinhaltet eine Registrierungsanforderung und eine Bestätigungdieser Registrierung. Eine Registrierungsinstanz pflegt ein Register von Schlüsseln unddie dazugehörigen Informationen in hinreichend sicherer Art und Weise.Die Registrierung symmetrischer Schlüssel ist in der Telematikinfrastruktur bisher nichtvorgesehen, da kein organisationsübergreifender Austausch symmetrischer Schlüsselstattfindet. Die Registrierung asymmetrischer Schlüssel findet im Rahmen der Erzeugungder Zertifikate statt und ist unter „Erzeugung eines Schlüssel-Zertifikats“ zu finden.F5.1.4 - Erzeugung eines Schlüssel-ZertifikatsISO: Der Dienst Erzeugung (und Registrierung) eines Schlüssel-Zertifikats verbindet einenöffentlichen Schlüssel mit einer Entität und wird von einer Zertifizierungsinstanz betrieben.Es sind zwei unterschiedliche Methoden zur Erzeugung eines Schlüssel-Zertifikats üblich:• Die Zertifizierungsinstanz erzeugt die Schlüssel auf sicherem Wege (Siehe„Schlüssel-Erzeugung“) und stellt in demselben Prozess auch gleich das Zertifikataus, indem sie öffentliche Schlüssel und Identitätsinformationen zusammenführtund signiert.• Der zukünftige Zertifikatsinhaber erzeugt die Schlüssel auf sicherem Wege(Siehe „Schlüssel-Erzeugung“) selbst. und sendet dann eine Request mit demöffentlichen Schlüssel und Identitätsinformationen an die Zertifizierungsinstanz.Die Zertifizierungsinstanz prüft den Request, bei Erfolg stellt sie dasZertifikat aus, indem sie öffentliche Schlüssel und Identitätsinformationen zusammenführtund signiert.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 580 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturBeide Methoden haben ihre Vor- und Nachteile, in der Telematikinfrastruktur werden beideMethoden angewandt.Bei beiden Methoden wird das Zertifikat mit der Ausstellung auch registriert.Nr.Erzeugung und Registrierung eines Schlüssel-ZertifikatsSP_KEY_GCR 57 _1 Die Zertifizierungsinstanz hat die Übereinstimmung der Identitätsinformationenim Zertifikat mit der Person zu gewährleisten (kann z.B. auch durch eine Prüfung bei der Auslieferung gewährleistet werden).SP_KEY_ GCR_2 Methode 2:Der Request des Zertifikat-Anforderers MUSS einen Nachweis enthalten,dass der Anforderer den privaten Schlüssel wirklich besitzt.Der Request des Zertifikat-Anforderers KANN einen Nachweis derIdentität enthalten, z. B. eine Qualifizierte Signatur.SP_KEY_GCR_3SP_KEY_GCR_4Alle Zertifikate müssen in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen erzeugt oder berechnetwerden.Die Systeme müssen jeden Versuch, ein Zertifikat unautorisiert zuerzeugen, verhindern.F5.1.5 - SchlüsselverteilungISO: Die Schlüsselverteilung ist eine Menge von Prozessen um Schlüssel-Management-Information-Objekte (in der Regel Schlüssel) sicher zu autorisierten Entitäten zu verteilen.Die Schlüssel müssen vertraulich und authentisch verteilt werden, d. h. es muss sichergestelltwerden, dass jeder Schlüssel an die richtige Systemkomponente und nur an dieseverteilt wird. Insbesondere dürfen Schlüssel während der Verteilung auch nicht durch alteVersionen ersetzt werden können (replay-attack).Nr.SP_KEY_TRA_1SP_KEY_TRA_2Anforderungen oder Maßnahme Schlüssel-VerteilungKryptographische Schlüssel dürfen nur in einer der folgenden Formenverteilt werden:οIn Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).ο Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Die Verbreitung und Gültigkeitsdauer dieser Schlüsselmuss so gering wie möglich gehalten werden.Für die Verteilung von Schlüsselteilen gelten dieselben Anforderungenwir für die Verteilung von Schlüsseln.Wenn in sicherer Umgebung Schlüssel in Klartext transportiert57 GRC =Generation and Registration of Certificatsgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 581 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_TRA_3SP_KEY_TRA_4SP_KEY_TRA_5SP_KEY_TRA_6SP_KEY_TRA_7Anforderungen oder Maßnahme Schlüssel-Verteilungwerden, ist zusätzlich zur Vertraulichkeit auch die Authentizität undIntegrität der Schlüssel durch ein geeignetes kryptographischesVerfahren sicherzustellen.Wenn Schlüssel in verschlüsselter Form verteilt werden, ist zusätzlichzur Vertraulichkeit auch die Authentizität und Integrität derSchlüssel durch ein geeignetes kryptographisches Verfahren sicherzustellen.Das Verfahren MUSS auch erlauben, das Wiederverteilenalter Schlüssel zu erkennen.In dem spezifischen Sicherheitskonzept ist genau zu bezeichnen,welcher Schlüssel in welcher Phase in welcher Systemkomponentetransportiert wird (siehe „F6.2 – Beschreibung mit Hilfe von exemplarischenSchlüssel-Lebenszyklen“). Die Schlüssel dürfen nuran diejenigen Systemkomponenten verteilt werden, in denen ihrAufenthalt vorgesehen ist und wo sie hinreichend geschützt sind.Der Schutz der Schlüssel bei der Verteilung muss durchgehendzwischen den Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere darf kein Schlüssel zwischen Verteilung undInstallation in einem den Kriterien für die Speicherung von Schlüsselnnicht genügenden Zustand zwischengespeichert werden.Ein Schlüssel darf nur dann in ein Gerät geladen werden, wennfeststeht, dass die Speicherung des Schlüssels in diesem Gerätden dafür geltenden Kriterien entspricht.Die Systeme müssen jeden Versuch, einen Schlüssel unautorisiertzu verteilen, verhindern.F5.1.6 - SchlüsselinstallationISO: Der Dienst Schlüsselinstallation ist immer vor dem Gebrauch eines Schlüssels notwendig.Bei der Schlüsselinstallation wird der Schlüssel in einer Art und Weise eingebracht,die den Schlüssel vor Kompromittierung schützt.Nr.SP_KEY_ACT_1SP_KEY_ACT_2SP_KEY_ACT_3Anforderungen oder Maßnahme SchlüsselinstallationKryptographische Schlüssel dürfen nur in einer der folgenden Formeninstalliert werden:οIn Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).ο Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Die Verbreitung und Gültigkeitsdauer dieser Schlüsselmuss so gering wie möglich gehalten werden.Für die Installation von Schlüsselteilen gelten dieselben Anforderungenwie für die Installation von Schlüsseln.Bei der Installation ist die Authentizität und Integrität der Schlüssel,die ja durch ein geeignetes kryptographisches Verfahren sichergestelltwurde, zu prüfen.Kopien von Schlüsselmaterial dürfen nur in denjenigen Systemkomponentenvorkommen, in denen ihr Aufenthalt vorgesehen undgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 582 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_ACT_4SP_KEY_ACT_5SP_KEY_ACT_6SP_KEY_ACT_7Anforderungen oder Maßnahme Schlüsselinstallationdokumentiert ist und wo sie hinreichend geschützt sind.Nach der Installation sind diese Kopien entsprechend den Regelnvollständig zu löschen.In dem spezifischen Sicherheitskonzept ist genau zu bezeichnen,welcher Schlüssel in welcher Phase in welcher Systemkomponentetransportiert wird (siehe „F6.3 – Beschreibung mit Hilfe von exemplarischenSchlüssel-Lebenszyklen“). Die Schlüssel dürfen nurin denjenigen Systemkomponenten installiert werden, in denen ihrAufenthalt vorgesehen ist und wo sie hinreichend geschützt sind.Der Schutz der Schlüssel bei der Verteilung muss durchgehendzwischen den Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere darf kein Schlüssel zwischen Verteilung undInstallation in einem den Kriterien für die Speicherung von Schlüsselnnicht genügenden Zustand zwischengespeichert werden.Ein Schlüssel darf nur dann in ein Gerät geladen und freigegebenwerden, wenn feststeht, dass die Speicherung des Schlüssels indiesem Gerät den dafür geltenden Kriterien entspricht.Die Systeme müssen jeden Versuch, einen Schlüssel unautorisiertzu installieren, verhindern.F5.1.7 - SchlüsselspeicherungISO: Der Dienst Schlüsselspeicherung bietet sichere Speicherung für Schlüssel im laufendenoder kurz bevorstehenden Gebrauch oder auch für Backup-Schlüssel. Es ist üblicherweisevon Vorteil, physikalisch getrennte Schlüsselspeicher vorzusehen.Zum Beispiel sichert es die Vertraulichkeit und Integrität von Schlüsselmaterial oder dieIntegrität von öffentlichen Schlüsseln. Speicherung kann in allen Schlüsselzuständen imLebenszyklus eines Schlüssels vorkommen. Abhängig von der Wichtigkeit der Schlüssel,können sie von den folgenden Mechanismen geschützt werden:• Physikalische Sicherheit• Verschlüsselung mit Schlüsseln, die ihrerseits durch Physikalische Sicherheitgeschützt sind.• Der Zugriff auf sie wird durch PIN oder Passwort geschützt.• Für Schlüsselmaterial sollten Versuche der Kompromittierung erkennbar sein.• Die Schlüssel dürfen während der Speicherung nicht unautorisiert ausgelesen,unautorisiert verändert, unautorisiert ersetzt oder in anderer Weise unautorisiertbenutzt werden.Nr.SP_KEY_STO_1Anforderungen oder Maßnahme Schlüssel-SpeicherungSymmetrische und private asymmetrische Schlüssel DÜRFEN nurin einer der folgenden Formen gespeichert werden:οIm Klartext in einer sicheren Umgebung oder in einem Si-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 583 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturcherheitsmodul.ο Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Für die Speicherung von Schlüsselteilen gelten dieselben Anforderungenwie für die Speicherung von Schlüsseln.SP_KEY_STO_2SP_KEY_STO_3SP_KEY_STO_4SP_KEY_STO_5Wenn in sicherer Umgebung Schlüssel im Klartext gespeichert werden,MUSS zusätzlich zur Vertraulichkeit auch die Authentizität undIntegrität der Schlüssel durch ein geeignetes kryptographischesVerfahren sichergestellt werden.Wenn Schlüssel in verschlüsselter Form gespeichert werden,MUSS zusätzlich zur Vertraulichkeit auch die Authentizität und Integritätder Schlüssel durch ein geeignetes kryptographisches Verfahrensichergestellt werden. Das Verfahren MUSS auch erlauben,das Überschreiben durch alte Schlüssel zu erkennen.Keiner einzelnen Person DARF es möglich sein, auf irgendeinengeheimen Schlüssel in Klartext zuzugreifen oder ihn zu verändernoder ihn zu ersetzen.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert auszulesen, zu verändern, zu ersetzen oder zu benutzen,.F5.1.8 - SchlüsselableitungISO: Der Dienst Schlüsselableitung erstellt eine potentiell große Anzahl z. B. kartenindividuellerSchlüsseln unter Benutzung eines geheimen Originalschlüssels, genannt Ableitungsschlüssel,nicht geheimen veränderlichen Daten und mit einem Transformationsprozess(der nicht geheim sein muss). Das Ergebnis dieses Prozesses ist der abgeleiteteSchlüssel. Der Ableitungsschlüssel erfordert besonderen Schutz. Der AbleitungsprozessMUSS unumkehrbar und nicht-vorhersehbar sein um sicherzustellen, dass die Kompromittierungeines abgeleiteten Schlüssels nicht den Ableitungsschlüssel oder andere abgeleiteteSchlüssel kompromittiert.Nr.SP_KEY_DEK_1SP_KEY_DEK _2SP_KEY_DEK_3Anforderungen Schlüssel-Erzeugung bzw. -AbleitungJeder Schlüssel MUSS mindestens eine Entropie von 100 Bit besitzen.Der geheime Ableitungsschlüssel MUSS mindestens die kryptographischeStärke der mit ihm abgeleiteten Schlüssel aufweisen.Damit MUSS der Ableitungsschlüssel eine Entropie deutlich über100 Bit aufweisen.Der geheime Ableitungsschlüssel MUSS mindestens den Schutzbedarfder mit ihm abgeleiteten Schlüssel erfüllen. Wird mit ihmeine Vielzahl von Schlüssel erzeugt, SOLLTE der geheime Ableitungsschlüsseleinen Schutzbedarf deutlich über dem der abgeleitetenSchlüssel, erfüllen.Die kryptographische Funktion mit Ein-Weg-Charakter, über die dieAbleitung realisiert wird (i. d. R. Hashfunktion oder Blockchiffre),sollte für diese Anwendung geeignet sein. Dies ist ggf. durch Refe-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 584 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_DEK_4SP_KEY_DEK_5SP_KEY_DEK_6Anforderungen Schlüssel-Erzeugung bzw. -Ableitungrenzen oder Sicherheitsgutachten zu belegen.Es ist ein Konzept für Maßnahmen für den Fall einer plötzlich aufgedecktenSchwäche der kryptographische Funktion mit Ein-Weg-Charakter zu beschreiben und vorzulegen.Nach Prüfung des Konzepts durch die Zulassungsstelle sind ggf.einleitende Maßnahmen zu treffen (z. B. Einbringung von Vertrauensankernzum Schlüsseltausch).Alle Schlüssel MÜSSEN in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen abgeleitet werden, sodass sie oder das Schlüsselmaterial zu Ableitung nicht von Unbefugtenausgelesen oder manipuliert werden können.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert abzuleiten.F5.1.9 - SchlüsselarchivierungISO: Schlüsselarchivierung ist der Prozess, Schlüssel nach Ablauf der Nutzung sicher undlangfristig zu speichern. Für diesen Dienst ist die Anwendung des Dienstes “Schlüsselspeicherung”denkbar, es bestehen aber verschiedene Anforderungen, so dass auch verschiedeneImplementierungen denkbar sind. So könnte z. B. die Schlüsselarchivierungoffline realisiert werden.Archivierte Schlüssel können noch lange nach dem normalen Gebrauch der Schlüsselbenötigt werden um bestimmte Ansprüchen abzuklären.Nr.SP_KEY_ARC_1SP_KEY_ARC_2SP_KEY_ARC_3SP_KEY_ARC_4Anforderungen oder Maßnahme Schlüssel-ArchivierungKryptographische Schlüssel DÜRFEN nur in einer der folgendenFormen verteilt werden:οIm Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).ο Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Die Verbreitung und Gültigkeitsdauer dieser Schlüssel muss sogering wie möglich gehalten werden.Wenn in sicherer Umgebung Schlüssel im Klartext transportiertwerden, MÜSSEN zusätzlich zur Vertraulichkeit auch die Authentizitätund Integrität der Schlüssel durch ein geeignetes kryptographischesVerfahren sichergestellt werden.Wenn Schlüssel in verschlüsselter Form verteilt werden, MUSSzusätzlich zur Vertraulichkeit auch die Authentizität und Integritätder Schlüssel durch ein geeignetes kryptographisches Verfahrensichergestellt werden. Das Verfahren MUSS auch erlauben, dasWiederverteilen alter Schlüssel zu erkennen.Keiner einzelnen Person DARF es möglich sein, auf irgendeinengeheimen Schlüssel in Klartext zuzugreifen oder ihn zu verändernoder ihn zu ersetzen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 585 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_ARC_5SP_KEY_ARC_6SP_KEY_ARC_7SP_KEY_ARC_8SP_KEY_ARC_9SP_KEY_ARC_10Anforderungen oder Maßnahme Schlüssel-ArchivierungZu jedem Schlüsselmaterial MUSS dokumentiert sein, ob und wielange es zu archivieren ist.Ist für Schlüsselmaterial die Archivierung vorgesehen, MUSS dieArchivierung durchgeführt werden.Für den Fall des wirtschaftlichen Ausfalls eines Betreibers ist eineNachfolgeregelung zu treffen, so dass die Qualität der Archivierungdurchgehend gewährleistet bleibt.In dem spezifischen Sicherheitskonzept ist genau zu bezeichnen,welcher Schlüssel in welcher Phase in welcher Systemkomponentearchiviert wird (siehe „F6.3 – Beschreibung mit Hilfe von exemplarischenSchlüssel-Lebenszyklen“). Die Schlüssel dürfen nur andiejenigen Systemkomponenten verteilt werden, in denen ihr Aufenthaltvorgesehen ist und wo sie hinreichend geschützt sind.Der Schutz der Schlüssel bei der Verteilung MUSS durchgehendzwischen den Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere darf kein Schlüssel zwischen Verteilung undInstallation in einem den Kriterien für die Speicherung/Archivierungvon Schlüsseln nicht genügenden Zustand zwischengespeichertwerden.Ein Schlüssel DARF nur dann in ein Gerät geladen werden, wennfeststeht, dass die Speicherung des Schlüssels in diesem Gerätden dafür geltenden Kriterien entspricht.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert zu archivieren.F5.1.10 - Schlüsselsuspendierung (Revoke-key)ISO: Wenn die Kompromittierung eines Schlüssels bekannt ist oder vermutet wird, stelltder Dienst Schlüsselsuspendierung die sichere Deaktivierung des Schlüssels sicher. DerDienst ist auch für Schlüssel notwendig, deren Gültigkeit abgelaufen ist. Schlüsselsuspendierungwird auch dann angewandt, wenn sich die Rahmenbedingungen beim Schlüsselinhaberändern. Nach der Suspendierung kann der Schlüssel nur eingeschränkt benutztwerden (In der Regel nicht mehr um zu verschlüsseln oder zu signieren, aber derSchlüssel darf gebraucht werden um zu entschlüsseln oder zu verifizieren). Der Grad derSuspendierung MUSS genau beschrieben werden, wie auch die Umstände unter denender Schlüssel wieder aktiviert werden kann.Der Dienst Schlüsselsuspendierung wird kaum bei zertifikatbasierten Schemata angewandt,wo der Lebenszyklus der Schlüssel durch die Gültigkeit der Zertifikate geregeltwird.Auch beim Einsatz von Verschlüsselungsalgorithmen, bei denen die Bestimmung derSchlüssel durch Brechen des Verfahrens sehr unwahrscheinlich ist, muss dennoch auchweiterhin mit anderen Angriffen auf die Schlüssel gerechnet werden. Beispiele für solcheGefährdungspotentiale sind etwa physische Zugriffe auf ein Sicherheitsmodul, Bestechung,Erpressung, etc. Aus diesem Grund müssen alle Schlüssel gesperrt werden können.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 586 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_DEA_1SP_KEY_DEA_2SP_KEY_DEA_3SP_KEY_DEA_4Anforderungen Schlüssel-DeaktivierungEs MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurregelmäßigen Schlüssel-Deaktivierung nach Zeitablauf allerSchlüssel getroffen werden.Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurnotfallmäßigen Schlüssel-Deaktivierung aller Schlüssel getroffenwerden.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert zu deaktivieren.Im Fall einer erkannten (oder angenommenen) KompromittierungMÜSSEN geeignete Maßnahmen ergriffen werden können,οοum alle Daten und Schlüssel zu bestimmen, die mit demkompromittierten Schlüssel oder davon abgeleitetenSchlüsseln geschützt wurden;um die weitere Verwendung des kompromittierten Schlüsselsund aller davon abgeleiteten bzw. geschützter Schlüsselbzw. PIN/PUK zu verhindern.F5.1.11 - Aufheben der Registrierung eines SchlüsselsISO: Der Dienst Aufheben der Registrierung eines Schlüssels wird von einer Registrierungsinstanzangeboten, die die Verbindung des Schlüssels mit einer Entität aufhebt.„Aufheben der Registrierung eines Schlüssels“ ist Teil des Schlüssel-Zerstörungsprozesses. Wenn eine Entität die Registrierung eines Schlüssels aufhebenlassen will, kontaktiert sie die Registrierungsinstanz.In der Telematikinfrastruktur ist zurzeit keine Registrierung von symmetrischen Schlüsselnvorgesehen. Die Registrierung von asymmetrischen Schlüsseln findet während der Erzeugungder Zertifikate durch die Registrierung der Zertifikate statt. Das Aufheben derRegistrierung stellt also die Sperrung von Zertifikaten dar.Nr.Anforderungen Aufheben der RegistrierungSP_KEY_DRC 58 _1 Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurregelmäßigen Aufheben der Registrierung von Zertifikaten nachZeitablauf getroffen werden.SP_KEY_DRC_2SP_KEY_DRC_3SP_KEY_DRC_4Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurnotfallmäßigen Aufhebung der Registrierung aller Zertifikate getroffenwerden.Die Systeme MÜSSEN jeden Versuch verhindern, die Registrierungeines Zertifikats unautorisiert aufzuheben.Im Fall einer erkannten (oder angenommenen) KompromittierungMÜSSEN geeignete Maßnahmen ergriffen werden können,58 DRC = Deregister Certificategematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 587 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturοοum alle Daten und Schlüssel zu bestimmen, die mit demkompromittierten Schlüssel oder davon abgeleitetenSchlüsseln geschützt wurden;um die weitere Verwendung des kompromittierten Schlüsselsund aller davon abgeleiteten bzw. geschützter Schlüsselbzw. PIN/PUK zu verhindern.F5.1.12 - SchlüsselzerstörungISO: Der Dienst Schlüsselzerstörung bietet einen Prozess an für die sichere Zerstörungvon Schlüsseln, die nicht mehr gebraucht werden. Zerstörung eines Schlüssels bedeutet,alle Einträge des Schlüsselmanagement-Informationsobjekts zu löschen, so dass nachder Zerstörung keine Information übrig bleibt, um den zerstörten Schlüssel wiederherzustellen.Dies wird gemacht, um die Zerstörung alle archivierten Kopien sicherzustellen. Bevor archivierteSchlüssel zerstört werden, sollte eine Prüfung gemacht werden um sicherzustellen,dass kein Material das, durch diese Schlüssel geschützt wird, jemals wieder gebrauchtwird.NOTIZ: Es können Schlüssel außerhalb von elektronischen Geräten oder Systemen gespeichertsein. Das erfordert zusätzliche administrative Maßnahmen.Ein Schlüssel DARF nur während der Gültigkeitsdauer und für den vom Schlüsselinhabervorgesehenen Zweck verwendet werden. Um missbräuchliche Verwendung und Kompromittierungsmöglichkeitenzu verringern, MUSS der Schlüssel daher in allen Komponentenunverzüglich sicher gelöscht werden, wenn die die Gültigkeitsdauer abläuft oderwenn er in einer Komponente nicht mehr benötigt wird.Nr.SP_KEY_DEL_1SP_KEY_DEL_2Anforderungen Schlüssel-ZerstörungNicht mehr benötigte Schlüssel MÜSSEN unverzüglich sicher gelöschtwerden.Die unverzügliche sichere Löschung ist im Sicherheitskonzept derjeweiligen Komponente und Dienste nachzuweisen.SchlüsselzerstörungEs MÜSSEN Vorkehrungen getroffen werden, um nicht mehr benötigteSchlüssel oder aktive Schlüssel im Fall der drohenden Kompromittierungso zerstören zu können, dass es nicht mehr möglichist, die Schlüssel ganz oder teilweise zu rekonstruieren.F5.1.13 - Prüfung der SchlüsselverwendungDie Sicherheit einer Anwendung kann potentiell dadurch beeinträchtigt werden, dassSchlüssel auf nicht vorgesehene Art benutzt werden. Dies kann dadurch verhindert werden,dass jedem Schlüssel sein Verwendungszweck eindeutig zugewiesen wird, und dieseZuweisung im Betrieb durchgesetzt und überwacht wird.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 588 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_USE_1SP_KEY_USE_2SP_KEY_USE_3Anforderungen oder Maßnahme Schlüssel-VerwendungJeder Schlüssel DARF jeweils nur für den in der Spezifikation desSystems eindeutig definierten kryptographischen Zweck verwendetwerden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel für einenanderen Zweck als den vorhergesehenen zu verwenden, erkennenund verhindern.Bei Beschreibung des Gebrauchs von asymmetrischen Schlüsselnin den Spezifikationen ist jeweils der in den Zertifikaten festgehalteneVerwendungszweck mit zu dokumentieren.F5.1.14 - Schlüssel-WechselIn der Regel als gekoppelten Dienst aus Schlüsselzerstörung und Erzeugung, Installationund Registrierung realisiert.Auch beim Einsatz von Verschlüsselungsalgorithmen, bei denen die Bestimmung derSchlüssel durch Brechen des Verfahrens sehr unwahrscheinlich ist, muss dennoch auchweiterhin mit anderen Angriffen auf die Schlüssel gerechnet werden. Beispiele für solcheGefährdungspotentiale sind etwa physische Zugriffe auf ein Sicherheitsmodul, Bestechung,Erpressung, etc. Aus diesem Grund müssen alle Schlüssel sowohl regelmäßig alsauch notfallmäßig ausgewechselt werden können. Ein regelmäßiger Schlüsselwechselbegrenzt den Schaden im Falle von unentdeckten Kompromittierungen. Ein notfallmäßigerSchlüsselwechsel begrenzt den Schaden im Falle von entdeckten Kompromittierungen.Nr.SP_KEY_CHA_1SP_KEY_CHA_2SP_KEY_CHA_3SP_KEY_CHA_4Anforderungen Schlüssel-WechselEs MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumregelmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumnotfallmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert auszuwechseln.Der ausgetauschte Schlüssel wird endgültig gesperrt, er kann nichtmehr reaktiviert werden.F5.1.15 - Reaktivierung (Reactivation)Bei Verdacht auf Angriffe auf die Schlüssel können alle Schlüssel gesperrt werden.Bei der Sperrung von Schlüsseln und Zertifikaten wird zwischen (temporärer) Deaktivierung,auch Suspendierung genannt, und der endgültigen Sperrung unterschieden.Ein deaktivierter Schlüssel kann unterbestimmten Umständen wieder reaktiviert werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 589 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturEs ist sinnvoll, die Policy so zu gestalten, dass ein deaktivierter Schlüssel nach einemfestgelegten Zeitraum, wenn er nicht reaktiviert wurde, endgültig gesperrt wird.Nr.SP_KEY_REA_1SP_KEY_REA_2SP_KEY_REA_3Anforderungen ReaktivierungDie Reaktivierung eines Schlüssels SOLL nicht unauthorisiert undnur wenn die Reaktivierung in der Policy vorgesehen ist, durchgeführtwerden. Es MUSS bei einer Reaktivierung sichergestellt werden,dass alle Gründe, die zu einer Deaktivierung geführt haben,nicht mehr erfüllt sind. Zusätzlich MÜSSEN die Anforderungen fürAktivierung eingehalten werden.Ein deaktivierter Schlüssel DARF nur innerhalb eines festgelegtenZeitraums wieder reaktiviert werden können. Ist dieser Zeitraumverstrichen, MUSS der Schlüssel endgültig gesperrt werden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertzu reaktivieren, verhindern.F5.1.16 - Prozessgestaltung und spezifisches Sicherheitskonzept des Betreibers für dieSchlüsselverwaltungDer Betreiber MUSS für das Keymanagement ein spezielles Sicherheitskonzept erstellenzu den allgemeinen betrieblichen Aspekten, siehe Anhang G des übergreifenden Sicherheitskonzepts.Aufgrund des in der Regel hohen, sehr hohen Schutzbedarfs des Schlüsselmanagementssind jedoch weitere Mindestanforderungen für die Verwaltung derSchlüssel einzuhalten. Das spezielle Sicherheitskonzept eines Betreibers für die Betriebsumgebungdes Keymanagements SOLLTE mindestens folgende Inhalte (vgl.z. B. § 2 SigV) enthalten. Diese Anforderungen sind auf elf Bereiche nach ISO27002:2005(vgl. BSI Standards 100-1,2,3). aufgeteilt:Nr.SP_KEY_PRO_1SP_KEY_PRO_2Übergreifende Anforderungen an die Prozessgestaltung und dasspezifisches Sicherheitskonzept des BetreibersInformation Security PolicyAlle sicherheitsrelevanten Aktivitäten werden in Standards undRegelwerken niedergelegt, die ständig an alle sich änderndenAnforderungen angepasst und ggf. erweitert werden MÜSSEN.Eine Beschreibung aller erforderlichen technischen, baulichen undorganisatorischen Sicherheitsmaßnahmen und deren EignungMUSS erfolgen.Die Einhaltung der Standards und Regelwerke MUSS von denUnternehmen gewährleistet werden. Das Keymanagement wirdbeeinflusst von den aktuell gültigen Mindeststandards der gematikOrganisationEine Übersicht über die Aufbau- und Ablauforganisation für denBetrieb des Sicherheitsmanagements MUSS erstellt werden, inder die Verantwortlichkeiten, Rechte und Pflichten des Bedienungspersonalseindeutig festgelegt sind.Durch personelle und organisatorische Maßnahmen MUSS si-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 590 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_3SP_KEY_PRO_4SP_KEY_PRO_5SP_KEY_PRO_6SP_KEY_PRO_7Übergreifende Anforderungen an die Prozessgestaltung und dasspezifisches Sicherheitskonzept des Betreiberschergestellt werden, dass nur ausdrücklich autorisierten Personenund Anwendungen der Umgang und die Verwendung der Schlüsselmöglich ist.Für die Anwendung besonders sensitiver Kryptoverfahren undSchlüssel (beispielsweise manuelle Verteilung initialer Transportschlüssel)MÜSSEN Personen gesondert ermächtigt werden.AssetmanagementEine Festlegung der Verantwortlichkeiten für alle Funktionen desSchlüsselmanagements mit den notwendigen organisatorischenTrennungen und Unvereinbarkeiten von Rollen sowie eine Abschätzungund Bewertung verbleibender Restrisiken MUSS erfolgenEine Person DARF dabei zu keinem Zeitpunkt die vollständigeKontrolle oder die Kenntnis über die in einem Bereich verwendetenSchlüssel besitzen. Daher ist eine Aufspaltung der Funktionenund Definition von Rollen notwendig, sodass das Vier-Augen-Prinzip gewährleistet ist. Dies bietet einerseits einen Schutz vorInnentätern, andererseits lassen sich somit unberechtigte Verdachtsmomenteund unbegründete Anschuldigungen von Mitarbeiternvermeiden.Die Aufbau- und Ablauforganisation MÜSSEN vollständig definiertund dokumentiert sein. Die Trennung und die Unvereinbarkeit vonfunktionalen, operativen und administrativen Tätigkeiten sind dabeiim Sicherheitskonzept des Betreibers zu berücksichtigen.Human resources securityDas eingesetzte Verfahren zur Beurteilung und Sicherstellung derZuverlässigkeit des eingesetzten Personals MUSS beschriebenwerden. Eine Auswahl besonders vertrauenswürdiger Personenals Schlüsselbeauftragte (für den Umgang mit Schlüsselmaterial)ist zu treffen.Schlüsselbeauftragte und ggf. der Benutzer von KryptoverfahrenMÜSSEN regelmäßig bezüglich der Einhaltung des Kryptoverfahrensund aller weiteren Festlegungen zur Schlüsselsicherheit geschultwerden.Physical and Environmental SecurityEine Beschreibung aller vorhandenen baulichen und organisatorischenSicherheitsmaßnahmen der Zutrittskontrolle und deren EignungMUSS vorhanden sein.Communications and Operations ManagementEine Übersicht über die eingesetzten Produkte und entsprechendeErklärungen zu den dadurch realisierten Sicherheitsfunktionenund deren Eignung MUSS erstellt werden.Die manuelle Ausgabe, Verteilung und Eingabe von SchlüsselnMUSS auf das unvermeidbar notwendige Maß zu beschränkenund ist nach dem Vier-Augen-Prinzip zu realisieren.Access ControlAlle vorhanden technischen und organisatorischen Sicherheits-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 591 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_8Übergreifende Anforderungen an die Prozessgestaltung und dasspezifisches Sicherheitskonzept des Betreibersmaßnahmen der Zugriffskontrolle und deren Eignung MÜSSENbeschrieben werden.Information systems acquisition, development and maintenanceDie Maßnahmen der Systementwicklung, des Tests, und der WartungSOLLEN beschrieben sein. Das Schlüsselverwaltungssystemund der Schlüsseldienst werden vor ihrer Einführung getestet undihre Vertrauenswürdigkeit wird nachgewiesen. Bei einem Übergangvom Testbetrieb zum Produktionsbetrieb bzw. vom Produktionsbetriebzur Instandhaltung und umgekehrt sollen spezielle Sicherheitsmaßnahmenergriffen, um diese Phasen zu trennen unddie Sicherheit des Produktionsbetriebs zu gewährleisten. Die folgendenMindestanforderungen SOLLEN eingehalten werden:οοοοοοοDie Hersteller von Geräten oder Programmen MÜSSENnachweisen, dass sie nach einer bewährten Entwicklungsmethodikarbeiten, die mindestens die folgenden drei(oder zu diesen äquivalente) Stufen umfasst:o Funktionale Spezifikationo Architekturentwurf (oder Grobentwurf)o FeinentwurfDie sicherheitsrelevanten Komponenten und Schnittstellen,sowie deren Abgrenzung zu nicht sicherheitsrelevantenKomponenten MÜSSEN klar bezeichnet werden. Diein der angewandten Entwicklungsmethodik definiertenStufen MÜSSEN zumindest für jede sicherheitsrelevanteKomponente und Schnittstelle ausführlich und nachvollziehbardokumentiert sein. Die Dokumentation MUSS denzuständigen Stellen zur Prüfung der Sicherheit zur Verfügunggestellt werden.Die Entwicklungsunterlagen MÜSSEN während ihrer Erstellung,Speicherung, Übermittlung, Lagerung und Prüfunggegen unbefugten Zugriff und insbesondere gegenunbemerkte Veränderung geschützt werden.Die Implementierung MUSS in einer Weise strukturiert erfolgenund dokumentiert werden, dass die im Feinentwurfidentifizierten sicherheitsrelevanten Komponenten undSchnittstellen im Gerät oder Programm eindeutig identifizierbarsind.Software-Implementierungen sind in einer gut dokumentiertenProgrammiersprache durchzuführen. Der dokumentierteQuellcode ist den zuständigen Stellen zur Prüfungzur Verfügung zu stellen.Die Hersteller von Geräten oder Programmen MÜSSENnachweisen, dass sie während der gesamten Implementierungs-und Wartungsphase mit einem bewährten Konfigurationskontrollsystemarbeiten.Die Hersteller MÜSSEN nachweisen, dass bei der Implementierungdie Verantwortlichkeiten und Zugriffsrechteklar definiert sind und die Arbeiten in einer Umgebung undgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 592 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_9Übergreifende Anforderungen an die Prozessgestaltung und dasspezifisches Sicherheitskonzept des Betreibersmit Werkzeugen ausgeführt werden, die eine Kontrollevon Zuständigkeiten und Zugriffsrechten jederzeit gewährleisten.οοοοDie Hersteller MÜSSEN umfassende Tests der Funktionalitätund Prüfungen der Sicherheit durchführen. InsbesondereMUSS nachgewiesen werden, dass die beabsichtigtenFunktionen nicht missbraucht oder umgangen werdenkönnen, und dass nur die beabsichtigten Funktionen ausgeführtwerden können. Die Testdaten und Testergebnissesind zu dokumentieren und den zuständigen Stellenzur Prüfung zur Verfügung zu stellen.Die Hersteller MÜSSEN nachweisen, dass sie die notwendigenWartungsarbeiten, den Ersatz und das Updatevon Komponenten in einer Weise organisieren und durchführenkönnen, die eine unautorisierte Veränderung derGeräte oder Programme zuverlässig verhindert.Nachträgliches Herunterladen von Programm-Updatesvon sicherheitsrelevanten Diensten darf nur nach gegenseitigerkryptographischer Authentifikation der kommunizierendenParteien stattfinden. Die Integrität der Programm-UpdatesMUSS geschützt sein.Die Hersteller MÜSSEN für alle Komponenten Installationsprozedurendefinieren und ggf. Werkzeuge mitliefern,die gewährleisten, dass die Geräte und Programme aufdem gesamten Weg von der Implementierungs- bis in dieBetriebsumgebung durchgehend gegen unbemerkte Manipulationengesichert sind.Information security incident managementEs ist nicht möglich, ein System vollständig gegen Angriffe abzusichern.Deshalb muss eine wichtige Sicherheitsfunktion zumindestdas Erkennen von Angriffen und Angriffsversuchen gegendas System unterstützen. Mit Hilfe dieser Funktion wird die Analyseder Angriffe erleichtert. Entsprechend notwendige Alarmbehandlungenund Schadensabwehrmaßnahmen können durchführenwerden.Beim Auftreten bestimmter, durch die Beweissicherung erfassterEreignisse wird unverzüglich Sicherheitsalarm ausgelöst und einbestimmter Benutzer / eine bestimmte Rolle benachrichtigt.Es muss im Sicherheitskonzept des Betreibers festgelegt sein,welche Situationen zu Alarmen führen.Für alle definierten Alarme MUSS folgendes gelten:ο Es MUSS festgelegt sein, wer für die Bearbeitung des A-larms zuständig ist.οοEs MÜSSEN Verfahren existieren um festzustellen, welcherSchaden angerichtet worden ist. Die dazu notwendigenInformationen MÜSSEN gesammelt und bereitgestelltwerden.Es MUSS festgelegt sein, welche Notfallprozeduren undgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 593 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturNr.SP_KEY_PRO_10SP_KEY_PRO_11Übergreifende Anforderungen an die Prozessgestaltung und dasspezifisches Sicherheitskonzept des BetreibersAbwehrstrategien ablaufen sollen. Insbesondere MÜS-SEN die maximalen Reaktionszeiten, die InformationsundEntscheidungsprozesse festgelegt sein.Es muss mindestens dann ein Alarm ausgelöst werden, wennSchlüssel oder PINs bei der Erzeugung, Verteilung, Speicherungoder im Betrieb kompromittiert wurden. Die gematik MUSS unverzüglichinformiert werden.Business Continuity ManagementEs MÜSSEN Maßnahmen für einen notfallmäßigen Schlüsselwechselvorgesehen werden.ComplianceDie Einhaltung der rechtlichen Vorgaben, der Sicherheitsrichtliniemuss durch unabhängige Audits geprüft werden. Es MÜSSENregelwidrige Handlungen von eigentlich autorisierten Personenzumindest nachträglich entdeckt und nachgewiesen werden können.Dazu ist das Führen von Audit 59 Trails und Log-Aufzeichnungen notwendig.Darin MÜSSEN z. B. Verletzungen von Sicherheitsregeln und Unregelmäßigkeitenim System (z. B. unkorrekte Übertragung, mehrfacheInitialisierung von individuellen Systemkomponenten, mehrfacheunkorrekte Eingabe von PINs, wiederholte Meldungen) aufgezeichnetwerden. Diese Aufzeichnungen MÜSSEN so geführtwerden, dass es möglich ist, relevante Operationen, die mit sensitivenDaten durchgeführt wurden, und die dabei betroffenen Datenzu rekonstruieren. Diese Aufzeichnungen MÜSSEN so ausgewertetwerden, dass sie innerhalb einer akzeptablen Frist zu geeignetenAlarmbehandlungen führen.Es MUSS ein Dienst geschaffen werden, der alle sicherheitsrelevantenAktionen von Benutzern und Anwendungen protokolliert.Hierzu gehören u. a.οοοAnmeldungen von Benutzern am System,Rollenwechsel,fehlgeschlagene Authentifikationen undο versuchte unberechtigte Zugriffe auf ObjekteZusätzlich SOLLEN die protokollierten Daten regelmäßig gesichtet,aufbereitet und ausgewertet werden, so dass Lücken im Sicherheitssystem(z. B. Ausnutzung verdeckter Kanäle, etc.) frühzeitigaufgedeckt werden können. Der Zugriff auf AuditdatenMUSS auf einen kleinen Personenkreis beschränkt bleiben.59 In diesem Audit werden die sicherheitsrelevanten Aktionen der Schlüsselverwaltung aufgezeichnet,ein Zusammenhang mit dem versichertenzentrierten Audit des Versicherten ist nicht vorhanden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 594 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF5.1.16 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03149A_03150A_03151F:SP_KEY_ALL_1F:SP_KEY_ALL_2F:SP_KEY_ALL_3SSSKrypto_KM_Vertaulichkeit:Vertraulichkeit; kryptographischeVerfahren zum Schutzder SchlüsselVertraulichkeitDie verwendeten kryptographischen Verfahren zum Schutz derSchlüssel MÜSSEN mindestens den Mindestanforderungen der gematikgenügen, um den Schutz der Vertraulichkeit der Schlüsselwährend des Transports, der Speicherung sowie des Gebrauchs vornicht autorisierter Aufdeckung, Weitergabe und Nutzung zu gewährleisten.Krypto_KM_Integrität_Authentizität: IntegritätsgeschützteSpeicherung und Übertragung.Krypto_KM_Verfügbarkeit:Verfügbarkeit von Schlüsseln;Backupund Archivierung.Integrität und AuthentizitätDie Integrität der Schlüssel MUSS gewährleistet werden. Das betrifftden Schutz vor Änderung und Ersetzung der Schlüssel. Außerhalbgeschützter Hardware sind Schlüssel und die ihnen zugeordneteInformationen integritätsgeschützt zu speichern und zu übertragen.VerfügbarkeitEine hohe Serviceverfügbarkeit von Online-Anwendungen der Telematikinfrastrukturist sicherzustellen. Die Verfügbarkeit dieser Anwendungendarf durch den Zugriff auf die kryptographischen Methodenund die notwendigen Schlüssel nicht eingeschränkt werden.o Backup der Schlüssel: Um die Handhabbarkeit des Schlüsselverwaltungssystemsund die Verfügbarkeit von Schlüsseln von Online-Anwendungen auch nach Fehlersituationen sicherzustellen, ist einProzess zu etablieren, um diese Schlüssel (falls zulässig) oder neueSchlüssel innerhalb eines definierten Zeitraums (wieder) zur Verfügungzu stellen.o Archivierung von Schlüsseln zur Rekonstruktion historischer Daten.Bei Ablösung eines Schlüssels SOLL dieser nicht sofort gelöscht,sondern deaktiviert werden. Deaktivierte Schlüssel sollten füreinen Übergangszeitraum archiviert werden, so dass ggf. auf siezurückgegriffen werden kann. Nach Ablauf des ÜbergangszeitraumsAnhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 595 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellemüssen die Schlüssel dann physikalisch zerstört (gelöscht) werden.A_03152A_03153F:SP_KEY_ALL_4F:SP_KEY_ALL_5SSKrypto_KM_Nachvollziehbarkeit:Nachvollziehbarkeit allerAktivitätem beim Schlüsselmanagement.Krypto_KM_Verteilung_Verwendung: Verteilung und Verwendungder Schlüssel; Umsetzungdes MinimalitätsprinzipsNachvollziehbarkeit:Die Nachvollziehbarkeit aller relevanten Aktivitäten im System isteine unabdingbare Forderung, sowohl aus entsprechenden gesetzlichenbzw. geschäftlichen Anforderungen, wie auch aus Eigeninteressedes jeweiligen Unternehmens. Der für eine Aktion Verantwortlichemuss eindeutig festgestellt werden können. Die Benutzer desSchlüsselverwaltungssystems und die Nutzer des Schlüsseldiensteskönnen für ihre Handlungen verantwortlich gemacht und damit auchvor ungerechtfertigten Beschuldigungen geschützt werden. Ebensomuss Beweismaterial für Streitfälle erstellt und sicher verwahrt werden.Dies betrifft beim Keymanagement die Nachweisbarkeit der Schlüsselverwendungoder die Nachvollziehbarkeit der vorgenommenHandlungen, vono im Einsatz befindlichen Schlüsseln ab Stufe 1 mit Verteilung derSchlüssel, Empfänger, vorgesehener und tatsächlicher Gültigkeitszeitraum,Festlegung Einsatzzweck des Schlüssels.o mit einem Schlüssel bearbeiteten bzw. geschützten Objekten(z. B. verschlüsselten Daten, wie PINs, PUKs, …]).Die Verteilung und Verwendung der Schlüssel MUSS auf das absolutnotwendige Maß eingeschränkt werden, um die Möglichkeiten zurKompromittierung von Schlüsseln zu minimieren und potentielleSchäden zu beschränken.o Minimale Verteilung: Eine Weitergabe DARF nur an berechtigteOrganisationen und Personen erfolgen und es MUSS sichergestelltwerden, dass nur die Nutzung der freigegebenen Anwendungenmöglich ist.Gemeinsame symmetrische Schlüssel dürfen nur bei direkt beteiligtenKommunikationspartnern operativ verwendet werden. SymmetrischeSession Keys zur Sicherung von Transaktionen SOLLEN nurAnhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 596 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03154A_03155A_03156A_03157A_03158F:SP_KEY_ALL_6F:SP_KEY_ALL_7F:SP_KEY_ALL_8SP_KEY_HI_1SP_KEY_HI_2SSSSSKrypto_KM_01: Schlüsselhierarchie.Krypto_KM_02 : Kompromittierungeinzelner Hierarchiestufen.Krypto_KM_03: Nutzung deruntersten Hierarchiestufe(1-3) für Datenschlüssel.Krypto_Schlüsselhierarchie_01:Einheitliche Schutzmechanismenpro Hierarchiestufe.Krypto_Schlüsselhierarchie_02:einmalig verwendet werden.o Schlüsseltrennung und minimale Funktionalität: Für jede Anwendungoder kryptographische Funktion sind eigene Schlüssel zu definieren.Ein Schlüssel DARF nur entsprechend seinem Verwendungszweckeingesetzt werden.o Beschränkte Gültigkeitsdauer: Die zeitliche Gültigkeit von SchlüsselnMUSS eingeschränkt sein. Es MUSS ein regelmäßiger Schlüsselwechselaller Schlüssel erfolgen. Für jeden Schlüssel MÜSSENZeiträume definiert sein, in denen ein Schlüssel gültig ist. Nach Ablaufdieser Zeitspanne MÜSSEN die Schlüssel gewechselt werdenund die Verwendung abgelaufener Schlüssel MUSS verhindert werden.Ein Schlüssel, der andere Schlüssel beglaubigt oder verschlüsselt,MUSS mindestens die kryptographische Stärke der von ihm geschütztenSchlüssel aufweisen. Falls es sich dabei um Schlüssel fürunterschiedliche Algorithmen handelt, muss dies sinngemäß für dieeffektiven Schlüssellängen gelten.Die Kompromittierung von Schlüsseln niedrigerer HierarchiestufenDARF NICHT oder nur unter einem Aufwand, der dem Brechen deszugrunde liegenden Verschlüsselungsalgorithmus entspricht, zueiner Kompromittierung von Schlüsseln höherer Hierarchiestufenführen.Nur Schlüssel der untersten Hierarchiestufen (Stufe 1 – Stufe 3)dürfen zum Schutz von Daten, die selbst kein Schlüsselmaterialsind, verwendet werden.Einheitliche SchutzmechanismenGeheimes kryptographisches Material oder geheime kryptographischeSchlüssel einer Hierarchiestufe SOLLEN einheitliche sicherheitstechnischeMindestanforderungen zur Einhaltung des notwendigenSicherheitsniveaus einhalten.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Schlüssel des Versicherten:Da die Datenhoheit der medizinischen Daten der § 291a Anwen- Anhang Fgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 597 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03159SP_KEY_HI_3SSchutz des Schlüssels desVersichertenKrypto_Schlüsselhierarchie_03:Erzeugung des Schlüsselsdes Versichertendungen beim Versicherten liegt, ist die Verwendung dieser Schlüsselbzw. des kryptographisches Material in der alleinigen Verfügungsgewaltdes Versicherten bzw. der von ihm persönlich Beauftragten.Durch die Prozessgestaltungen und die organisatorischen und technischenSchutzmassnahmen ist jegliche Verwendung dieser Schlüsselohne Einverständnis und Autorisierung des Versicherten zu verhindernund die Wirksamkeit dieser Maßnahmen ist in einem spezifischenKryptographiekonzept des jeweiligen Betreibers eines Dienstesoder Komponente nachzuweisen.Erzeugung der Schlüssel des Versicherten(siehe auch Krypto_Schlüsselhierarchie_01)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent zu einem Trustcenter für qualifizierte Signaturen eingehaltenwerden.5.5Anhang F5.5A_03160A_03161SP_KEY_HI_4SP_KEY_HI_5SSKrypto_Schlüsselhierarchie_04:Private Schlüssel einer CAKrypto_Schlüsselhierarchie_05:Private Schlüssel der Root-TrustcenterDie Betreiber MÜSSEN Abweichungen dokumentieren, die Risikenbewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwarten.Private Schlüssel einer CA(siehe auch Krypto_Schlüsselhierarchie_01)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent für den privaten CA-Schlüssel in einem Trustcenter fürqualifizierte Signaturen eingehalten werden.Die Betreiber MÜSSEN Abweichungen dokumentieren, die Risikenbewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwartenPrivate Schlüssel der Root-Trustcenter(siehe auch Krypto_Schlüsselhierarchie_01)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent für den privaten Root-Schlüssel des Root-Trustcenter fürqualifizierte Signaturen eingehalten werden.Die Betreiber MÜSSEN Abweichungen dokumentieren, die RisikenAnhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 598 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03162A_03163A_03164SP_KEY_HI_6SP_KEY_CRE_1SP_KEY_CRE_2SSSÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturKrypto_Schlüsselhierarchie_06:Schlüssel der Bridge-CAKrypto_Schlüsselerzeugung_01:Erzeugung von Zufallszahlenbewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwarten.Schlüssel der Bridge-CA(siehe auch Krypto_Schlüsselhierarchie_01)Es SOLLEN bauliche, personelle und organisatorische Maßnahmenäquivalent für den privaten Root-Schlüssel des Root-Trustcenter fürqualifizierte Signaturen eingehalten werden.Die Betreiber MÜSSEN Abweichungen dokumentieren, die Risikenbewerten und übernehmen. Spezifischere Mindestanforderungen füreinzelne Schlüsselarten sind in zukünftigen Versionen zu erwarten.Grundsätzlich können für die Erzeugung von Zufallszahlen physikalischeZufallszahlengeneratoren oder Pseudozufallszahlengeneratoreneingesetzt werden. Entsprechend des gewählten Generatorssind die Anforderungen gemäß [AIS 20] für Pseudozufallszahlengeneratorenund [AIS 31] für physikalische Zufallszahlengeneratoreneinzuhalten.Es wird dringend empfohlen, zur Schlüsselerzeugung einen physikalischenZufallszahlengenerator zu verwenden, Schlüssel der Hierachiestufen4 bis 5 und Schlüssel mit langer Lebensdauer (mehr als 3Jahre) MÜSSEN von einem physikalischen Zufallszahlengeneratorerzeugt werden.Jeder Schlüssel MUSS mindestens eine Entropie von 100 Bit besitzen.Krypto_Schlüsselerzeugung_02:Berechnung von Schlüsseln.Die Berechnung von Schlüsseln MUSS mit Hilfe eines kryptographischenAlgorithmus so erfolgen, dasso der berechnete Schlüssel ohne Kenntnis des für die Berechnungbenutzten Schlüssels nicht einfacher bestimmt werden kann als einzufällig erzeugter Schlüssel.o aus der Kenntnis des berechneten Schlüssels und der übrigenInputdaten keine Informationen über den für die Berechnung benutztenSchlüssel abgeleitet werden können, ohne den zugrunde liegendenkryptographischen Algorithmus zu brechen.Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 599 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03165A_03166A_03167A_03168A_03169A_03170A_03171SP_KEY_CRE_3SP_KEY_CRE_4SP_KEY_GCR_1SP_KEY_GCR_2SP_KEY_GCR_3SP_KEY_GCR_4SP_KEY_TRA_1SSSSSSSÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturKrypto_Schlüsselerzeugung_03:Erzeugung/Berechnung ingesicherter Umgebung.Krypto_Schlüsselerzeugung_04:Schutz vor unautorisierterSchlüsselgenerierung.Krypto_Schlüssel_Erzeugung_Registrierung_01: Identifikationdes Zertifikatseigners.Krypto_Schlüssel_Erzeugung_Registrierung_02: Nachweisdes Schlüsselbesitzes.Krypto_Schlüssel_Erzeugung_Registrierung_03: Erzeugung/Berechnungin gesicherterUmgebung.Krypto_Schlüssel_Erzeugung_Registrierung_04: Schutzvor unautorisierter Generierungeines Zertifikates.Krypto_Schlüssel_Verteilung_01:Gesicherte Verteilung vonSchlüsseln.Alle Schlüssel müssen in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen erzeugt oder berechnetwerden, so dass sie nicht von Unbefugten ausgelesen oder manipuliertwerden können.Die Systeme müssen jeden Versuch, einen Schlüssel unautorisiertzu erzeugen, verhindern.Die Zertifizierungsinstanz hat die Übereinstimmung der Identitätsinformationenim Zertifikat mit der Person zu gewährleisten (kann z. B.auch durch eine Prüfung bei der Auslieferung gewährleistet werden).Methode 2:Der Request des Zertifikat-Anforderers MUSS einen Nachweis enthalten,dass der Anforderer den privaten Schlüssel wirklich besitzt.Der Request des Zertifikat-Anforderers KANN einen Nachweis derIdentität enthalten, z. B. eine Qualifizierte Signatur.Alle Zertifikate MÜSSEN in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen erzeugt oder berechnetwerdenDie Systeme müssen jeden Versuch, ein Zertifikat unautorisiert zuerzeugen, verhindern.Kryptographische Schlüssel dürfen nur in einer der folgenden Formenverteilt werden:o In Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).o Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 600 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03172A_03173A_03174A_03175A_03176SP_KEY_TRA_2SP_KEY_TRA_3SP_KEY_TRA_4SP_KEY_TRA_5SP_KEY_TRA_6SSSSSKrypto_Schlüssel_Verteilung_02:Sicherstellen der Vertraulichkeit,Authentizität undIntegrität bei Schlüsseltransportim Klartext.Krypto_Schlüssel_Verteilung_03:Sicherstellen der Vertraulichkeit,Authentizität undIntegrität bei verschlüsseltemTransport.Krypto_Schlüssel_Verteilung_04:Dokumentation der Schlüsselverteilunggemäß Minimalitätsprinzip.Krypto_Schlüssel_Verteilung_05:Durchgängiger Schutz beider Schlüsselverteilung.Krypto_Schlüssel_Verteilung_06:Kein Einbringen von Schlüsselnin ungeeignete Geräte.Die Verbreitung und Gültigkeitsdauer dieser Schlüssel muss so geringwie möglich gehalten werden.Für die Verteilung von Schlüsselteilen gelten dieselben Anforderungenwir für die Verteilung von Schlüsseln.Wenn in sicherer Umgebung Schlüssel in Klartext transportiert werden,ist zusätzlich zur Vertraulichkeit auch die Authentizität und Integritätder Schlüssel durch ein geeignetes kryptographisches Verfahrensicherzustellen.Wenn Schlüssel in verschlüsselter Form verteilt werden, ist zusätzlichzur Vertraulichkeit auch die Authentizität und Integrität derSchlüssel durch ein geeignetes kryptographisches Verfahren sicherzustellen.Das Verfahren MUSS auch erlauben, das Wiederverteilenalter Schlüssel zu erkennen.In dem spezifischen Sicherheitskonzept ist genau zu bezeichnen,welcher Schlüssel in welcher Phase in welcher Systemkomponentetransportiert wird (siehe „F6.2 – Beschreibung mit Hilfe von exemplarischenSchlüssel-Lebenszyklen“). Die Schlüssel dürfen nur andiejenigen Systemkomponenten verteilt werden, in denen ihr Aufenthaltvorgesehen ist und wo sie hinreichend geschützt sind.Der Schutz der Schlüssel bei der Verteilung muss durchgehend zwischenden Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere darf kein Schlüssel zwischen Verteilung undInstallation in einem den Kriterien für die Speicherung von Schlüsselnnicht genügenden Zustand zwischengespeichert werden.Ein Schlüssel darf nur dann in ein Gerät geladen werden, wenn feststeht,dass die Speicherung des Schlüssels in diesem Gerät dendafür geltenden Kriterien entspricht.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 601 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03177A_03178A_03179A_03180A_03181A_03182SP_KEY_TRA_7SP_KEY_ACT_1SP_KEY_ACT_2SP_KEY_ACT_3SP_KEY_ACT_4SP_KEY_ACT_5SSSSSSÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturKrypto_Schlüssel_Verteilung_07:Verhindern der unautorisiertenSchlüsselverteilung.Krypto_Schlüssel_Installation_01:Gesicherte Installation vonSchlüsseln.Krypto_Schlüssel_Installation_02:Prüfung von Authentizitätund Integrität der Schlüssel.Krypto_Schlüssel_Installation_03:Kopien von SchlüsselmaterialKrypto_Schlüssel_Installation_04:Dokumentation der Schlüsselinstallationgemäß Minimalitätsprinzip.Krypto_Schlüssel_Installation_05:Durchgängiger Schutz beider SchlüsselinstallationDie Systeme müssen jeden Versuch, einen Schlüssel unautorisiertzu verteilen, verhindern.Kryptographische Schlüssel dürfen nur in einer der folgenden Formeninstalliert werden:o In Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).o Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Die Verbreitung und Gültigkeitsdauer dieser Schlüssel muss so geringwie möglich gehalten werden.Für die Installation von Schlüsselteilen gelten dieselben Anforderungenwie für die Installation von SchlüsselnBei der Installation ist die Authentizität und Integrität der Schlüssel,die ja durch ein geeignetes kryptographisches Verfahren sichergestelltwurde, zu prüfen.Kopien von Schlüsselmaterial dürfen nur in denjenigen Systemkomponentenvorkommen, in denen ihr Aufenthalt vorgesehen und dokumentiertist und wo sie hinreichend geschützt sind.Nach der Installation sind diese Kopien entsprechend den Regelnvollständig zu löschen.In dem spezifischen Sicherheitskonzept ist genau zu bezeichnen,welcher Schlüssel in welcher Phase in welcher Systemkomponentetransportiert wird (siehe „F6.3 – Beschreibung mit Hilfe von exemplarischenSchlüssel-Lebenszyklen“). Die Schlüssel dürfen nur indenjenigen Systemkomponenten installiert werden, in denen ihrAufenthalt vorgesehen ist und wo sie hinreichend geschützt sind.Der Schutz der Schlüssel bei der Verteilung muss durchgehend zwischenden Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere darf kein Schlüssel zwischen Verteilung undInstallation in einem den Kriterien für die Speicherung von Schlüs-Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 602 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleseln nicht genügenden Zustand zwischengespeichert werden.A_03183A_03184A_03185A_03186A_03187SP_KEY_ACT_6SP_KEY_ACT_7SP_KEY_STO_1SP_KEY_STO_2SP_KEY_STO_3SSSSSKrypto_Schlüssel_Installation_06:Keine Installation/Freigabevon Schlüsseln auf ungeeigneteGeräte.Krypto_Schlüssel_Installation_07:Verhindern der unautorisiertenSchlüsselinstallation.Krypto_Schlüssel_Speicherung_01: Sichere Spreicherungsymmetrischer und privateasymmetrischer Schlüssel.Krypto_Schlüssel_Speicherung_02: Sicherstellen der Vertraulichkeit,Authentizität undIntegrität bei Schlüsselspeicherungim Klartext.Krypto_Schlüssel_Speicherung_03:Sicherstellen der Vertraulichkeit,,AuthentizitätundIntegrität bei SchlüsselspeicherunguverschlüsselterForm.Ein Schlüssel darf nur dann in ein Gerät geladen und freigegebenwerden, wenn feststeht, dass die Speicherung des Schlüssels indiesem Gerät den dafür geltenden Kriterien entspricht.Die Systeme müssen jeden Versuch, einen Schlüssel unautorisiertzu installieren, verhindern.Symmetrische und private asymmetrische Schlüssel DÜRFEN nur ineiner der folgenden Formen gespeichert werden:o Im Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul.o Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Für die Speicherung von Schlüsselteilen gelten dieselben Anforderungenwie für die Speicherung von SchlüsselnWenn in sicherer Umgebung Schlüssel im Klartext gespeichert werden,MUSS zusätzlich zur Vertraulichkeit auch die Authentizität undIntegrität der Schlüssel durch ein geeignetes kryptographisches Verfahrensichergestellt werden.Wenn Schlüssel in verschlüsselter Form gespeichert werden, MUSSzusätzlich zur Vertraulichkeit auch die Authentizität und Integrität derSchlüssel durch ein geeignetes kryptographisches Verfahren sichergestelltwerden. Das Verfahren MUSS auch erlauben, das Überschreibendurch alte Schlüssel zu erkennen.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 603 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03188A_03189A_03190A_03191A_03192A_03193A_03194SP_KEY_STO_4SP_KEY_STO_5SP_KEY_DEK_1SP_KEY_DEK _2SP_KEY_DEK_3SP_KEY_DEK_4SP_KEY_DEK_5SSSSSSSÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturKrypto_Schlüssel_Speicherung_04: Zugriff auf Klartextschlüsselnur im Vireaugenprinzip.Krypto_Schlüssel_Speicherung_05: Schutz vor unautorisiertenSchlüsselnutzung.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert auszulesen, zu verändern, zu ersetzen oder zu benutzen,.Krypto_Schlüssel_Ableitung_01:Kryptographische Stärke undMindestentropie.Krypto_Schlüssel_Ableitung_02:Schutzbedarf des geheimeAbleitungsschlüssels.Krypto_Schlüssel_Ableitung_03:Eignung der Ableitungsfunktion.Krypto_Schlüssel_Ableitung_04:Vorgehen bei plötzlich aufgedecktenSchwächem inder Ableitungsfunktion.Krypto_Schlüssel_Ableitung_05:Schlüsselableitung in gesi-Keiner einzelnen Person DARF es möglich sein, auf irgendeinengeheimen Schlüssel in Klartext zuzugreifen oder ihn zu verändernoder ihn zu ersetzen.Jeder Schlüssel MUSS mindestens eine Entropie von 100 Bit besitzen.Der geheime Ableitungsschlüssel MUSS mindestens die kryptographischeStärke der mit ihm abgeleiteten Schlüssel aufweisen.Damit MUSS der Ableitungsschlüssel eine Entropie deutlich über100 Bit aufweisen.Der geheime Ableitungsschlüssel MUSS mindestens den Schutzbedarfder mit ihm abgeleiteten Schlüssel erfüllen. Wird mit ihm eineVielzahl von Schlüssel erzeugt, SOLLTE der geheime Ableitungsschlüsseleinen Schutzbedarf deutlich über dem der abgeleitetenSchlüssel, erfüllen.Die kryptographische Funktion mit Ein-Weg-Charakter, über die dieAbleitung realisiert wird (i. d. R. Hashfunktion oder Blockchiffre),sollte für diese Anwendung geeignet sein. Dies ist ggf. durch Referenzenoder Sicherheitsgutachten zu belegen.Es ist ein Konzept für Maßnahmen für den Fall einer plötzlich aufgedecktenSchwäche der kryptographische Funktion mit Ein-Weg-Charakter zu beschreiben und vorzulegen.Nach Prüfung des Konzepts durch die Zulassungsstelle sind ggf.einleitende Maßnahmen zu treffen (z. B. Einbringung von Vertrauensankernzum Schlüsseltausch).Alle Schlüssel MÜSSEN in einer sicheren Umgebung oder in einemSicherheitsmodul mit geprüften Werkzeugen abgeleitet werden, sodass sie oder das Schlüsselmaterial zu Ableitung nicht von Unbefug-Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 604 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellecherter Umgebung.ten ausgelesen oder manipuliert werden können.A_03195A_03196A_03197A_03198A_03199A_03200SP_KEY_DEK_6SP_KEY_ARC_1SP_KEY_ARC_2SP_KEY_ARC_3SP_KEY_ARC_4SP_KEY_ARC_5SSSSSSKrypto_Schlüssel_Ableitung_06:Verhindern unautorisierterSchlüsselableitung.Krypto_Schlüssel_Archivierung_01: Gesicherte Archivierungvon Schlüsseln.Krypto_Schlüssel_Archivierung_02: Sicherstellen der Vertraulichkeit,Authentizität undIntegrität bei Schlüsseltransportim Klartext.Krypto_Schlüssel_Archivierung_03: Sicherstellen der Vertraulichkeit,Authentizitätund Integritätbei verschlüsseltemTransport.Krypto_Schlüssel_Archivierung_04: Zugriff auf Klartextschlüsselnur im Vireaugenprinzip.Krypto_Schlüssel_Archivierung_05: Abgabe der Archivie-Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert abzuleiten.Kryptographische Schlüssel DÜRFEN nur in einer der folgendenFormen transportiert werden:o Im Klartext in einer sicheren Umgebung oder in einem Sicherheitsmodul(z. B. Chipkarte).o Verschlüsselt mit einem dafür vorgesehenen Schlüssel.Die Verbreitung und Gültigkeitsdauer dieser Schlüssel muss so geringwie möglich gehalten werden.Wenn in sicherer Umgebung Schlüssel im Klartext transportiert werden,MÜSSEN zusätzlich zur Vertraulichkeit auch die Authentizitätund Integrität der Schlüssel durch ein geeignetes kryptographischesVerfahren sichergestellt werden.Wenn Schlüssel in verschlüsselter Form verteilt werden, MUSS zusätzlichzur Vertraulichkeit auch die Authentizität und Integrität derSchlüssel durch ein geeignetes kryptographisches Verfahren sichergestelltwerden. Das Verfahren MUSS auch erlauben, das Wiederverteilenalter Schlüssel zu erkennen.Keiner einzelnen Person DARF es möglich sein, auf irgendeinengeheimen Schlüssel in Klartext zuzugreifen oder ihn zu verändernoder ihn zu ersetzen.Zu jedem Schlüsselmaterial MUSS dokumentiert sein, ob und wielange es zu archivieren ist.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 605 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellerungsdauer.A_03201A_03202A_03203A_03204A_03205A_03206SP_KEY_ARC_6SP_KEY_ARC_7SP_KEY_ARC_8SP_KEY_ARC_9SP_KEY_ARC_10SP_KEY_DEA_1SSSSSSKrypto_Schlüssel_Archivierung_06: Garantierte Archivierungauch bei Ausfall einesBetreibers.Krypto_Schlüssel_Archivierung_07: Dokumentation derSchlüsselarchivierung gemäßMinimalitätsprinzipKrypto_Schlüssel_Archivierung_08: Durchgängiger Schutz beider Schlüsselarchivierung.Krypto_Schlüssel_Archivierung_09: Keine Archivierung vonSchlüsseln auf ungeeigneteGeräte.Krypto_Schlüssel_Archivierung_10: Schutz vor unautorisierterArchivierung.Krypto_Schlüssel_Deaktivierung_01: Regelmäßige Schlüssel-Deaktivierung nach Zeitab-Ist für Schlüsselmaterial die Archivierung vorgesehen, MUSS dieArchivierung durchgeführt werden.Für den Fall des wirtschaftlichen Ausfalls eines Betreibers ist eineNachfolgeregelung zu treffen, so dass die Qualität der Archivierungdurchgehend gewährleistet bleibt.In dem spezifischen Sicherheitskonzept ist genau zu bezeichnen,welcher Schlüssel in welcher Phase in welcher Systemkomponentearchiviert wird (siehe „F6.3 – Beschreibung mit Hilfe von exemplarischenSchlüssel-Lebenszyklen“). Die Schlüssel dürfen nur an diejenigenSystemkomponenten verteilt werden, in denen ihr Aufenthaltvorgesehen ist und wo sie hinreichend geschützt sind.Der Schutz der Schlüssel bei der Verteilung MUSS durchgehendzwischen den Sicherheitsmodulen der Quelle und des Ziels gestaltetsein. Insbesondere darf kein Schlüssel zwischen Verteilung undInstallation in einem den Kriterien für die Speicherung/Archivierungvon Schlüsseln nicht genügenden Zustand zwischengespeichertwerden.Ein Schlüssel DARF nur dann in ein Gerät geladen werden, wennfeststeht, dass die Speicherung des Schlüssels in diesem Gerät dendafür geltenden Kriterien entspricht.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert zu archivieren.Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurregelmäßigen Schlüssel-Deaktivierung nach Zeitablauf aller Schlüsselgetroffen werden.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 606 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellelauf.A_03207A_03208A_03209A_03210A_03211A_03212SP_KEY_DEA_2SP_KEY_DEA_3SP_KEY_DEA_4SP_KEY_DRC_1SP_KEY_DRC_2SP_KEY_DRC_3SSSSSSKrypto_Schlüssel_Deaktivierung_02: Vorkehrungen zurSchlüssel-Deaktivierung inNotfallsituationen.Krypto_Schlüssel_Deaktivierung_03: Schutz vor unautorisiertesSchlüsseldeaktivierung.Krypto_Schlüssel_Deaktivierung_04: Maßnahmen zur Deaktivierungbei Kompromittierungvon Schlüsseln.Krypto_Schlüssel_Deregistrierung_01: Regelmäßige Deregistrierungvon abgelaufenenZertifikaten.Krypto_Schlüssel_Deregistrierung_02: Vorkehrungen zurDeregistrierung von Zertifikatenin Notfallsituationen.Krypto_Schlüssel_Deregistrierung_03: Schutz vor unautori-Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurnotfallmäßigen Schlüssel-Deaktivierung aller Schlüssel getroffenwerden.Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert zu deaktivieren.Im Fall einer erkannten (oder angenommenen) KompromittierungMÜSSEN geeignete Maßnahmen ergriffen werden können,o um alle Daten und Schlüssel zu bestimmen, die mit dem kompromittiertenSchlüssel oder davon abgeleiteten Schlüsseln geschütztwurden;o um die weitere Verwendung des kompromittierten Schlüssels undaller davon abgeleiteten bzw. geschützter Schlüssel bzw. PIN/PUKzu verhindernEs MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurregelmäßigen Aufheben der Registrierung von Zertifikaten nachZeitablauf getroffen werden.Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zurnotfallmäßigen Aufhebung der Registrierung aller Zertifikate getroffenwerden.Die Systeme MÜSSEN jeden Versuch verhindern, die Registrierungeines Zertifikats unautorisiert aufzuheben.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 607 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quellesierter Deregistrierung.A_03213A_03214A_03215A_03216A_03217A_03218SP_KEY_DRC_4SP_KEY_DEL_1SP_KEY_DEL_2SP_KEY_USE_1SP_KEY_USE_2SP_KEY_USE_3SSSSSSKrypto_Schlüssel_Deregistrierung_04: Maßnahmen zur Deregistrierungbei KompromittierungvonZertifikaten.Krypto_Schlüssel_Zerstörung_01:Zerstörung nicht mehr benötigterSchlüssel.Krypto_Schlüssel_Zerstörung_02:Zerstörung von nicht mehrbenötigten oder von KompromittierungbedrohtenSchlüsseln.Krypto_Schlüssel_Prüfung_Verwendung_01:Zweckbindungvon SchlüsselnKrypto_Schlüssel_Prüfung_Verwendung_02:SystemtechnischeSicherstellung der Zweckbindungvon SchlüsselnKrypto_Schlüssel_Prüfung_VerwIm Fall einer erkannten (oder angenommenen) KompromittierungMÜSSEN geeignete Maßnahmen ergriffen werden können,o um alle Daten und Schlüssel zu bestimmen, die mit dem kompromittiertenSchlüssel oder davon abgeleiteten Schlüsseln geschütztwurden;o um die weitere Verwendung des kompromittierten Schlüssels undaller davon abgeleiteten bzw. geschützter Schlüssel bzw. PIN/PUKzu verhindern.Nicht mehr benötigte Schlüssel MÜSSEN unverzüglich sicher gelöschtwerden.Die unverzügliche sichere Löschung ist im Sicherheitskonzept derjeweiligen Komponente und Dienste nachzuweisen.SchlüsselzerstörungEs MÜSSEN Vorkehrungen getroffen werden, um nicht mehr benötigteSchlüssel oder aktive Schlüssel im Fall der drohenden Kompromittierungso zerstören zu können, dass es nicht mehr möglichist, die Schlüssel ganz oder teilweise zu rekonstruieren.Jeder Schlüssel DARF jeweils nur für den in der Spezifikation desSystems eindeutig definierten kryptographischen Zweck verwendetwerden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel für einenanderen Zweck als den vorhergesehenen zu verwenden, erkennenund verhindern.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Bei Beschreibung des Gebrauchs von asymmetrischen Schlüsselnin den Spezifikationen ist jeweils der in den Zertifikaten festgehalte- Anhang Fgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 608 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03219A_03220A_03221A_03222A_03223A_03224A_03225A_03226SP_KEY_CHA_1SP_KEY_CHA_2SP_KEY_CHA_3SP_KEY_CHA_4SP_KEY_REA_1SP_KEY_REA_2SP_KEY_REA_3SP_KEY_PRO_1SSSSSSSSendung_03: Dokumentationdes Verwendungszwecks.ne Verwendungszweck mit zu dokumentieren. 5.5Krypto_Schlüssel_Wechsel_01:Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumregelmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.Regelmäßiger Schlüsselwechsel.Krypto_Schlüssel_Wechsel_02:Es MÜSSEN hinreichende Vorkehrungen oder Möglichkeiten zumnotfallmäßigen Schlüsselwechsel aller Schlüssel getroffen werden.Vorkehrungen zum Schlüsselwechselin Notfallsituationen.Krypto_Schlüssel_Wechsel_03:Die Systeme MÜSSEN jeden Versuch verhindern, einen Schlüsselunautorisiert auszuwechseln.Schutz vor unautorisiertemSchlüsselwechsel.Krypto_Schlüssel_Wechsel_04:Der ausgetauschte Schlüssel wird endgültig gesperrt, er kann nichtmehr reaktiviert werden.Endgültige Sperrung.Krypto_Schlüssel_Reaktivierung_Die Reaktivierung eines Schlüssels SOLL nicht unauthorisiert undnur wenn die Reaktivierung in der Policy vorgesehen ist, durchge-01 Reaktivierung von führt werden. Es MUSS bei einer Reaktivierung sichergestellt werden,Schlüsseln gemäß Policy.dass alle Gründe, die zu einer Deaktivierung geführt haben,nicht mehr erfüllt sind. Zusätzlich MÜSSEN die Anforderungen fürKrypto_Schlüssel_ Reaktivierung_02: Zeitraum zur Reaktivierungvon Schlüsseln.Krypto_Schlüssel_ Reaktivierung_03: Schutz vor unautorisierterReaktivierung.Krypto_Schlüssel_ Prozesse_01: Information SecurityAktivierung eingehalten werden.Ein deaktivierter Schlüssel DARF nur innerhalb eines festgelegtenZeitraums wieder reaktiviert werden können. Ist dieser Zeitraum verstrichen,MUSS der Schlüssel endgültig gesperrt werden.Die Systeme MÜSSEN jeden Versuch, einen Schlüssel unautorisiertzu reaktivieren, verhindern.Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Anhang F5.5Information Security PolicyAlle sicherheitsrelevanten Aktivitäten werden in Standards und Re- Anhang Fgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 609 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03227A_03228SP_KEY_PRO_2SP_KEY_PRO_3SSPolicy.Krypto_Schlüssel_ Prozesse_02: OrganisationKrypto_Schlüssel_ Prozesse_03: Assetmanagementgelwerken niedergelegt, die ständig an alle sich ändernden Anforderungenangepasst und ggf. erweitert werden MÜSSEN. Eine Beschreibungaller erforderlichen technischen, baulichen und organisatorischenSicherheitsmaßnahmen und deren Eignung MUSS erfolgen.Die Einhaltung der Standards und Regelwerke MUSS von den Unternehmengewährleistet werden. Das Keymanagement wird beeinflusstvon den aktuell gültigen Mindeststandards der gematikOrganisationEine Übersicht über die Aufbau- und Ablauforganisation für den Betriebdes Sicherheitsmanagements MUSS erstellt werden, in der dieVerantwortlichkeiten, Rechte und Pflichten des Bedienungspersonalseindeutig festgelegt sind.Durch personelle und organisatorische Maßnahmen MUSS sichergestelltwerden, dass nur ausdrücklich autorisierten Personen undAnwendungen der Umgang und die Verwendung der Schlüsselmöglich ist.Für die Anwendung besonders sensitiver Kryptoverfahren undSchlüssel (beispielsweise manuelle Verteilung initialer Transportschlüssel)MÜSSEN Personen gesondert ermächtigt werdenAssetmanagementEine Festlegung der Verantwortlichkeiten für alle Funktionen desSchlüsselmanagements mit den notwendigen organisatorischenTrennungen und Unvereinbarkeiten von Rollen sowie eine Abschätzungund Bewertung verbleibender Restrisiken MUSS erfolgenEine Person DARF dabei zu keinem Zeitpunkt die vollständige Kontrolleoder die Kenntnis über die in einem Bereich verwendetenSchlüssel besitzen. Daher ist eine Aufspaltung der Funktionen undDefinition von Rollen notwendig, sodass das Vier-Augen-Prinzipgewährleistet ist. Dies bietet einerseits einen Schutz vor Innentätern,andererseits lassen sich somit unberechtigte Verdachtsmomenteund unbegründete Anschuldigungen von Mitarbeitern vermeiden.5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 610 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03229A_03230A_03231SP_KEY_PRO_4SP_KEY_PRO_5SP_KEY_PRO_6SSSKrypto_Schlüssel_ Prozesse_04: Human resources securityKrypto_Schlüssel_ Prozesse_05: Physical and EnvironmentalSecurity.Krypto_Schlüssel_ Prozesse_06: Communications andOperations ManagementDie Aufbau- und Ablauforganisation MÜSSEN vollständig definiertund dokumentiert sein. Die Trennung und die Unvereinbarkeit vonfunktionalen, operativen und administrativen Tätigkeiten sind dabeiim Sicherheitskonzept des Betreibers zu berücksichtigen.Human resources securityDas eingesetzte Verfahren zur Beurteilung und Sicherstellung derZuverlässigkeit des eingesetzten Personals MUSS beschriebenwerden. Eine Auswahl besonders vertrauenswürdiger Personen alsSchlüsselbeauftragte (für den Umgang mit Schlüsselmaterial) ist zutreffen.Schlüsselbeauftragte und ggf. der Benutzer von KryptoverfahrenMÜSSEN regelmäßig bezüglich der Einhaltung des Kryptoverfahrensund aller weiteren Festlegungen zur Schlüsselsicherheit geschultwerdenPhysical and Environmental SecurityEine Beschreibung aller vorhandenen baulichen und organisatorischenSicherheitsmaßnahmen der Zutrittskontrolle und deren EignungMUSS vorhanden sein.Communications and Operations ManagementEine Übersicht über die eingesetzten Produkte und entsprechendeErklärungen zu den dadurch realisierten Sicherheitsfunktionen undderen Eignung MUSS erstellt werden.Die manuelle Ausgabe, Verteilung und Eingabe von SchlüsselnMUSS auf das unvermeidbar notwendige Maß zu beschränken undist nach dem Vier-Augen-Prinzip zu realisieren.Communications and Operations Management:Eine Übersicht über die eingesetzten Produkte und entsprechendeErklärungen zu den dadurch realisierten Sicherheitsfunktionen undderen Eignung MUSS erstellt werden.Die manuelle Ausgabe, Verteilung und Eingabe von SchlüsselnMUSS auf das unvermeidbar notwendige Maß zu beschränken undist nach dem Vier-Augen-Prinzip zu realisieren.Anhang F5.5Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 611 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03232A_03233SP_KEY_PRO_7SP_KEY_PRO_8SSKrypto_Schlüssel_ Prozesse_07: Access ControlKrypto_Schlüssel_ Prozesse_08: Information systemsacquisition, development andmaintenanceAccess ControlAlle vorhanden technischen und organisatorischen Sicherheitsmaßnahmender Zugriffskontrolle und deren Eignung MÜSSEN beschriebenwerden.Information systems acquisition, development and maintenanceDie Maßnahmen der Systementwicklung, des Tests, und der WartungSOLLEN beschrieben sein. Das Schlüsselverwaltungssystemund der Schlüsseldienst werden vor ihrer Einführung getestet undihre Vertrauenswürdigkeit wird nachgewiesen. Bei einem Übergangvom Testbetrieb zum Produktionsbetrieb bzw. vom Produktionsbetriebzur Instandhaltung und umgekehrt sollen spezielle Sicherheitsmaßnahmenergriffen, um diese Phasen zu trennen und dieSicherheit des Produktionsbetriebs zu gewährleisten. Die folgendenMindestanforderungen SOLLEN eingehalten werden:o Die Hersteller von Geräten oder Programmen MÜSSEN nachweisen,dass sie nach einer bewährten Entwicklungsmethodik arbeiten,die mindestens die folgenden drei (oder zu diesen äquivalente) Stufenumfasst:o Funktionale Spezifikationo Architekturentwurf (oder Grobentwurf)o Feinentwurfo Die sicherheitsrelevanten Komponenten und Schnittstellen, sowiederen Abgrenzung zu nicht sicherheitsrelevanten KomponentenMÜSSEN klar bezeichnet werden. Die in der angewandten Entwicklungsmethodikdefinierten Stufen MÜSSEN zumindest für jede sicherheitsrelevanteKomponente und Schnittstelle ausführlich undnachvollziehbar dokumentiert sein. Die Dokumentation MUSS denzuständigen Stellen zur Prüfung der Sicherheit zur Verfügung gestelltwerden.o Die Entwicklungsunterlagen MÜSSEN während ihrer Erstellung,Speicherung, Übermittlung, Lagerung und Prüfung gegen unbefugtenZugriff und insbesondere gegen unbemerkte Veränderung ge-Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 612 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. Quelleschützt werden.o Die Implementierung MUSS in einer Weise strukturiert erfolgenund dokumentiert werden, dass die im Feinentwurf identifiziertensicherheitsrelevanten Komponenten und Schnittstellen im Gerätoder Programm eindeutig identifizierbar sind.o Software-Implementierungen sind in einer gut dokumentiertenProgrammiersprache durchzuführen. Der dokumentierte Quellcodeist den zuständigen Stellen zur Prüfung zur Verfügung zu stellen.o Die Hersteller von Geräten oder Programmen MÜSSEN nachweisen,dass sie während der gesamten Implementierungs- und Wartungsphasemit einem bewährten Konfigurationskontrollsystem arbeiten.o Die Hersteller MÜSSEN nachweisen, dass bei der Implementierungdie Verantwortlichkeiten und Zugriffsrechte klar definiert sindund die Arbeiten in einer Umgebung und mit Werkzeugen ausgeführtwerden, die eine Kontrolle von Zuständigkeiten und Zugriffsrechtenjederzeit gewährleisten.o Die Hersteller MÜSSEN umfassende Tests der Funktionalität undPrüfungen der Sicherheit durchführen. Insbesondere MUSS nachgewiesenwerden, dass die beabsichtigten Funktionen nicht missbrauchtoder umgangen werden können, und dass nur die beabsichtigtenFunktionen ausgeführt werden können. Die Testdaten undTestergebnisse sind zu dokumentieren und den zuständigen Stellenzur Prüfung zur Verfügung zu stellen.o Die Hersteller MÜSSEN nachweisen, dass sie die notwendigenWartungsarbeiten, den Ersatz und das Update von Komponenten ineiner Weise organisieren und durchführen können, die eine unautorisierteVeränderung der Geräte oder Programme zuverlässig verhindert.o Nachträgliches Herunterladen von Programm-Updates von sicherheitsrelevantenDiensten darf nur nach gegenseitiger kryptographischerAuthentifikation der kommunizierenden Parteien stattfinden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 613 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03234SP_KEY_PRO_9SKrypto_Schlüssel_ Prozesse_09: Information securityincident managementDie Integrität der Programm-Updates MUSS geschützt sein.o Die Hersteller MÜSSEN für alle Komponenten Installationsprozedurendefinieren und ggf. Werkzeuge mitliefern, die gewährleisten,dass die Geräte und Programme auf dem gesamten Weg von derImplementierungs- bis in die Betriebsumgebung durchgehend gegenunbemerkte Manipulationen gesichert sind.Information security incident managementEs ist nicht möglich, ein System vollständig gegen Angriffe abzusichern.Deshalb muss eine wichtige Sicherheitsfunktion zumindestdas Erkennen von Angriffen und Angriffsversuchen gegen das Systemunterstützen. Mit Hilfe dieser Funktion wird die Analyse der Angriffeerleichtert. Entsprechend notwendige Alarmbehandlungen undSchadensabwehrmaßnahmen können durchführen werden.Beim Auftreten bestimmter, durch die Beweissicherung erfassterEreignisse wird unverzüglich Sicherheitsalarm ausgelöst und einbestimmter Benutzer / eine bestimmte Rolle benachrichtigt.Es muss im Sicherheitskonzept des Betreibers festgelegt sein, welcheSituationen zu Alarmen führen.Für alle definierten Alarme MUSS folgendes gelten:o Es MUSS festgelegt sein, wer für die Bearbeitung des Alarms zuständigist.o Es MÜSSEN Verfahren existieren um festzustellen, welcher Schadenangerichtet worden ist. Die dazu notwendigen InformationenMÜSSEN gesammelt und bereitgestellt werden.o Es MUSS festgelegt sein, welche Notfallprozeduren und Abwehrstrategienablaufen sollen. Insbesondere MÜSSEN die maximalenReaktionszeiten, die Informations- und Entscheidungsprozesse festgelegtsein.Es muss mindestens dann ein Alarm ausgelöst werden, wennSchlüssel oder PINs bei der Erzeugung, Verteilung, Speicherungoder im Betrieb kompromittiert wurden. Die gematik MUSS unverzüglichinformiert werden.Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 614 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03235A_03236SP_KEY_PRO_10SP_KEY_PRO_11SSKrypto_Schlüssel_ Prozesse_10: Business ContinuityManagementKrypto_Schlüssel_ Prozesse_11:ComplianceBusiness Continuity ManagementEs MÜSSEN Maßnahmen für einen notfallmäßigen Schlüsselwechselvorgesehen werdenComplianceDie Einhaltung der rechtlichen Vorgaben, der Sicherheitsrichtliniemuss durch unabhängige Audits geprüft werden. Es MÜSSEN regelwidrigeHandlungen von eigentlich autorisierten Personen zumindestnachträglich entdeckt und nachgewiesen werden können. Dazuist das Führen von Audit Trails und Log-Aufzeichnungen notwendig.Darin MÜSSEN z. B. Verletzungen von Sicherheitsregeln und Unregelmäßigkeitenim System (z. B. unkorrekte Übertragung, mehrfacheInitialisierung von individuellen Systemkomponenten, mehrfacheunkorrekte Eingabe von PINs, wiederholte Meldungen) aufgezeichnetwerden. Diese Aufzeichnungen MÜSSEN so geführt werden,dass es möglich ist, relevante Operationen, die mit sensitiven Datendurchgeführt wurden, und die dabei betroffenen Daten zu rekonstruieren.Diese Aufzeichnungen MÜSSEN so ausgewertet werden,dass sie innerhalb einer akzeptablen Frist zu geeigneten Alarmbehandlungenführen.Es MUSS ein Dienst geschaffen werden, der alle sicherheitsrelevantenAktionen von Benutzern und Anwendungen protokolliert. Hierzugehören u. a.o Anmeldungen von Benutzern am System,o Rollenwechsel,o fehlgeschlagene Authentifikationen undo versuchte unberechtigte Zugriffe auf ObjekteZusätzlich SOLLEN die protokollierten Daten regelmäßig gesichtet,aufbereitet und ausgewertet werden, so dass Lücken im Sicherheitssystem(z. B. Ausnutzung verdeckter Kanäle, etc.) frühzeitigaufgedeckt werden können. Der Zugriff auf Auditdaten MUSS aufeinen kleinen Personenkreis beschränkt bleiben.Anhang F5.5Anhang F5.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 615 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF5.2 – Beschreibung mit Hilfe von exemplarischen Schlüssel-LebenszyklenIn dem spezifischen Sicherheitskonzept ist genau zu bezeichnen, welcher Schlüssel inwelcher Phase in welcher Systemkomponente transportiert wird und die Einhaltung derMindestanforderungen der gematik in allen Phasen des Lebenszyklus MUSS nachgewiesenwerden. Zur Erstellung der vollständigen Schlüsselliste MUSS der jeweilige Schlüsselverantwortlichedie nachfolgenden Übersichtsinformationen bereitstellen:• Kurz-Bezeichnung des Schlüsselmaterials• Komponente• Beschreibung des Schlüsselmaterials• Typ des Schlüsselmaterials• Anwendung in welchem Sicherheitsverfahren• ggf. Zuordnung zu einer PKI• Maximale Gültigkeitsdauer /typische Gültigkeitsdauer• Schlüsselerzeugung• Ist ein Backup bei der Schlüsselerzeugung vorgesehen?• Schlüsselregistrierung• Erzeugung eines Schlüssel-Zertifikats• Schlüsselverteilung• Schlüsselinstallation• Schlüsselspeicherung• Ist ein Backup bei Schlüsselspeicherung vorgesehen?• Schlüsselableitung• Schlüsselarchivierung• Festgelegter Verwendungszweck des Schlüssels• Wer hat die Zugriffsrechte?• Wie wird der Zugriff geschützt?• Aufheben der Registrierung eines Schlüssels/Schlüsselzertifikats• Wie wird der Schlüssel (wenn zulässig) nur suspendiert?• Wie wird der Schlüssel (wenn zulässig) wieder aktiviert?• Wie wird der Schlüssel endgültig gelöscht/gesperrt?• Wie wird eine Kompromittierung des Schlüssels erfasst?gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 616 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Maßnahmen bei Kompromittierung des Schlüssels• verantwortlich während des BetriebsDie Telematikinfrastruktur enthält über 200 verschiedene Schlüsselarten, deren Lebenszyklenaber nicht alle verschieden sind, sondern auf relativ wenige Grundtypen rückführbarsind. In diesem Unterkapitel wird zuerst mittels einer Tabelle jedem Schlüssel ein LebenszyklusTyp zu geordnet. Dann wird zu jedem Lebenszyklustyp exemplarisch ein Lebenszyklusbeschrieben. Ergänzend wird in einer gesonderten Tabelle beschrieben wieder Schutzbedarf in den einzelnen Einsatzumgebungen zu realisieren ist, in denen derSchlüssel vorkommt.Tabelle 57: Wegweiser durch prototypische LebenszyklenEbene Typ Schlüsselbeschreibung Lebenzyklus-TypAnw.Asym.SchlüsselPrivater Schlüssel und zugehörendesZertifikat für QES des HBAF6.3.5 Privater Schlüsselder HBA zur Qualifiziertenelektronischen SignaturAnw.Asym.SchlüsselPrivater Schlüssel und zugehörendesZertifikat für X.509 Zertifikateungleich QES des HBA/SMCF6.3.3 Privater Schlüsselder eGK zur AuthentifikationAnw.Asym.SchlüsselPrivater Schlüssel und zugehörendesZertifikat für X.509 Zertifikateungleich QES der eGKF6.3.3 Privater Schlüsselder eGK zur AuthentifikationAnw.Asym.SchlüsselPrivater Schlüssel und zugehörendesZertifikat für CV-Authentifikation des HBA/SMCF6.3.4 Privater CVCSchlüssel der eGK zurAuthentifikationAnw.Asym.SchlüsselPrivater Schlüssel und zugehörendesZertifikat für CV-Authentifikation der EGKF6.3.4 Privater CVCSchlüssel der eGK zurAuthentifikationAnw.Asym.SchlüsselPrivater Schlüssel und zugehörendesAUT- Zertifikat für Nachrichtenauthentifikationvon Diensten/FachdienstenF6.3.3 Privater Schlüsselder eGK zur AuthentifikationAnw.Sym.SchlüsselObjektschlüssel zur Verschlüsselungmedizinischer DatenF6.3.1 Objektschlüssel zurVerschlüsselung medizinischerDatenAnw.Sym.SchlüsselSK.CAMS.ENC / SK.CAMS.MACKartenindividuelle Schlüssel fürdie gegenseitige Authentisierungim Rahmen der Interaktion zwischeneGK und zugehörigemCAMS(z. B. für das Nachladen von Anwendungen).F6.3.2 KartenindividuellerCAMS-SchlüsselAnw.Sym.SchlüsselSK.CAMS.ENC / SK.CAMS.MACKartenindividuelle Schlüssel fürdie gegenseitige AuthentisierungF6.3.2 KartenindividuellerCAMS-Schlüsselgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 617 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturEbene Typ Schlüsselbeschreibung Lebenzyklus-TypNetzNetzNetzNetzNetzNetzAsym.SchlüsselAsym.SchlüsselAsym.SchlüsselAsym.SchlüsselAsym.SchlüsselAsym.Schlüsselim Rahmen der Interaktion zwischeneGK und zugehörigemCAMS (z. B. für das Nachladenvon Anwendungen).Privater Schlüssel und zugehörendesZertifikat zur VPN Authentisierungim SM-NK/Netzkonnektor(IPSEC) zum VPN-Konzentrator(optionaler) Privater Schlüssel undzugehörendes Zertifikat zur TLS-Kommunikation mit dem Primärsystemim Konnektor.Privater Schlüssel und zugehörendesZertifikat zur VPN Authentisierungim SM-NK/Netzkonnektor(IPSEC) VPN-Konzentrator, Zone2.2 des MehrwertdienstenetzesPrivater Schlüssel und zugehörendesZertifikat X.509-Telematik-Netz-CA (IPSec)Privater Schlüssel und zugehörendesTLS/SSL Zertifikat Nachrichtenkommunikationzwischenverschiedenen Anwendungsservicesin der Telematik MUSS Authentifizierung,Autorisierung, Vertraulichkeitund Integritätsschutzüber SSL/TLS implementieren.•Privater Schlüssel und zugehörendesZertifikat X.509-TelematikService-CA (TLS/SSL))F6.3.8 Privater Schlüsselzur Authentisierung imTLS-Protokoll KonnektorF6.3.8 Privater Schlüsselzur Authentisierung imTLS-Protokoll KonnektorF6.3.8 Privater Schlüsselzur Authentisierung imTLS-Protokoll KonnektorF6.3.8 Privater Schlüsselzur Authentisierung imTLS-Protokoll KonnektorF6.3.8 Privater Schlüsselzur Authentisierung imTLS-Protokoll KonnektorF6.3.8 Privater Schlüsselzur Authentisierung imTLS-Protokoll KonnektorAnw.PIN undPasswörterPIN/Passwort KT F6.3.6 Passwörter für U-ser und Admin KartenterminalAnw.PIN undPasswörterPasswort KonnektorF6.3.7 Passwörter fürAdmin-Passwort KonnektorF5.2.1 - Objektschlüssel zur Verschlüsselung medizinischer DatenTabelle 58: Lebenszyklus Objektschlüssel zur Verschlüsselung medizinischer DatenErfassungsbogen von SchlüsselmaterialKurz-Bezeichnung desSchlüsselmaterialsObjektschlüsselVerantwortlicherEinsatzumgebunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 618 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialKomponenteKonnektorÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungBeschreibung desSchlüsselmaterialsTyp des SchlüsselmaterialsAnwendung in welchemSicherheitsverfahrenggf. Zuordnung zu einerPKIMaximale Gültigkeitsdauer/typische GültigkeitsdauerSchutzbedarfsymmetrischer Schlüssel zurVer-/Entschlüsselung vonDokumentensymmetrisch, AES 256 BITVer-/Entschlüsselung eines(medizinischen) DokumentsKeine direkte Zuordnung, dieSchlüssel die den Objektschlüsselhandhaben gehörenzur TSL PKI5 Jahre /3 JahreVertraulichkeit sehr hochIntegrität hochVerfügbarkeit hochAuthentizität hochNichtabstreitbarkeit hochSchlüsselerzeugung im Konnektor Gerät: Hersteller,Betriebund Umgebung:LEIst ein Backup bei der neinSchlüsselerzeugungvorgesehen ?Schlüsselregistrierung nicht vorgesehenU_OP_SV undTR oderU_OP_PC undTEErzeugung einesSchlüssel-ZertifikatsneinSchlüsselverteilungSchlüsselinstallationüber ObjektTickets an Berechtigtekeine explizite InstallationFachdienstU_DC_protoderU_DC_secSchlüsselspeicherungIst ein Backup beiSchlüsselspeicherungvorgesehen ?SchlüsselableitungNur verschlüsselt und signiertim ObjektTicket im Fachdienst/aufeGKNein, den Schlüssel habennur Berechtigte, die ein ObjektTicketbesitzenneinFachdienstU_DC_protoderU_DC_secgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 619 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialSchlüsselarchivierungneinÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungFestgelegter VerwendungszweckdesSchlüsselsWer hat die Zugriffsrechte?Wie werden die BerechtigtenausgewähltWie wird der Zugriffgeschützt?Aufheben der Registrierungeines Schlüssels/SchlüsselzertifikatsWie wird der Schlüssel(wenn zulässig) nursuspendiert?Wie wird der Schlüssel(wenn zulässig) wiederaktiviert?Wie wird der Schlüsselendgültig gelöscht/gesperrt?Wie wird eine Kompromittierungdes Schlüsselserfasst?Maßnahmen bei KompromittierungdesSchlüsselsverantwortlich währenddes BetriebsVer-/Entschlüsselung von(medizinischen) DokumentenBerechtigte, die ein ObjektTicketbesitzenDie Auswahl der Berechtigtenist sicherheitsrelevant.D. h. sie muss innerhalb derTI realisiert werden,i. d. R: durch Trusted Viewerund Konnektor.Prüfung der Berechtigung,Zugriff nur ObjektTickets anBerechtigtenicht vorgesehennicht vorgesehennicht vorgesehenLöschung des Objektdokuments/UmschlüsselnAnruf bei gematik, im Incident-Managementwird einIncident ausgelöst und dasFlag "Vertraulichkeit" gesetzt.Umschlüsseln (verlangt Anwesenheitdes Versicherten)Erzeugung bis Hinterlegungim Fachdienst: LE, danachFachdienstTrusted Viewer:Hersteller,Konnektor:Hersteller,PVS; Betriebund Umgebung:LEFachdienst /DatenerhaltgematikUmschlüsselnU_OP_SV undTR oderU_OP_PC undTEU_DC_protoderU_DC_sec/U_HSM_protU_HSM_protUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsTabelle 59: Umsetzung Schutzbedarf Objektschlüssel zur Verschl. medizinischer Datengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 620 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturObjektschlüssel: symmetrischerSchlüssel zur Ver-/Entschlüsselung von Dokumenten.Schutzbedarf Objektschlüssel(So071 – Statische Schlüssel)Vertraulichkeit sehr hochIntegrität hochVerfügbarkeit hochAuthentizität hochNichtabstreitbarkeit hochVorkommen des Schlüssels Einsatzumgebung Umsetzung des SchutzbedarfsSchlüsselerzeugung des Objektschlüsselsim Konnektor.Objektschlüssel verlässt Konnektornicht in Klartext, sondernausschließlich verschlüsselt undsigniert im ObjektTicket. Löschendes Objektschlüssels nach Verwendung.Konnektor:U_OP_SV und TRoderU_OP_PC und TEVertraulichkeit (der medizinischenDaten): Zufallserzeugungnach TR-03116.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Konnektorumzusetzen.Übertragung des Objektschlüssels,verschlüsselt und signiertim ObjektTicket, zum Fachdienst.Nachricht an den Fachdienstsigniert.Schlüsselspeicherung im Fachdienstnur verschlüsselt und signiertim ObjektTicket.Übertragung des Objektschlüssels,verschlüsselt und signiertim ObjektTicket, vom Fachdienstzum Konnektor. Nachricht vomFachdienst signiert. .Verschlüsselte LAN-Übertragungdes Objektschlüssels, verschlüsseltund signiert im ObjektTicketvom Konnektor zum Kartenleser.Entschlüsselung des Objektschlüsselsin Chipkarten.Kartenterminal: Übernahme desObjektschlüssels in Klartext vonder Chipkarte. Löschen des Objektschlüsselsnach Verwendung.Verschlüsselte LAN-Übertragungdes Objektschlüssels zum Konnektor.Konnektor -> VPN-Konz. IPsec verschlüsselt: T6,VPN-Konz. -> Broker:TLS/SSL verschlüsseltT9, Broker-> FachdienstT10.U_DC_prot oderU_DC_secKonnektor -> VPN-Konz. IPsec verschlüsselt: T6,VPN-Konz. -> Broker:TLS/SSL verschlüsseltT9, Broker-> FachdienstT10.T9: LAN: Keineweiteren Angaben.U_SC_ProtKartenterminal:U_OP_SV und TRoderU_OP_PC und TET9: LAN: Keineweiteren Angaben.Nur die verminderten Schutzbedarfefür das ObjektTicket sindbei der Übertragung zu realisieren.Kritisch: Vertraulichkeit"hoch" zwischen Broker undFachdienst ohne Verschlüsselungrealisieren.Nur die verminderten Schutzbedarfefür das ObjektTicket sindvon Fachdienst zu realisierenNur die verminderten Schutzbedarfefür das ObjektTicket sindbei der Übertragung zu realisieren.Kritisch: Vertraulichkeit"hoch" zwischen Broker undFachdienst ohne Verschlüsselungrealisieren.Nur die verminderten Schutzbedarfefür das ObjektTicket sindbei der Übertragung zu realisieren.Die Chipkarten sind dafür evaluiertden Schutzbedarf wie fürden Objektschlüssel verlangt,umzusetzenVertraulichkeit (sehr hoch) , Integrität,Verfügbarkeit, Authentizitätund Nichtabstreitbarkeitvom Kartenterminal umzusetzen.Kritisch: Die Verschlüsselungdes LAN MUSS Vertraulichkeit"sehr hoch" realisieren.Integrität, Verfügbarkeit, Authentizitätund Nichtabstreitbarkeitgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 621 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturObjektschlüssel: symmetrischerSchlüssel zur Ver-/Entschlüsselung von Dokumenten.Schutzbedarf Objektschlüssel(So071 – Statische Schlüssel)Vertraulichkeit sehr hochIntegrität hochVerfügbarkeit hochAuthentizität hochNichtabstreitbarkeit hochVorkommen des Schlüssels Einsatzumgebung Umsetzung des Schutzbedarfsvom Konnektor umzusetzen.Konnektor Verwendung des Objektschlüsselszur Ver-/Entschlüsselung von (medizinischen)Dokumenten.Konnektor Löschen des Objektschlüsselsnach Verwendung.Der Objektschlüssel wird imRahmen von „Umschlüsselungund Datenerhalt“ entschlüsseltund erneut verschlüsselt.Konnektor:U_OP_SV und TRoderU_OP_PC und TEKonnektor:U_OP_SV und TRoderU_OP_PC und TERechenzentrum für„Umschlüsselungund Datenerhalt“:U_DC_prot undU_HSM_Prot oderU_DC_sec undU_HSM_ProtVertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Konnektorumzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Konnektorumzusetzen.F5.2.2 - Kartenindividueller CAMS-SchlüsselTabelle 60 Lebenszyklus des Kartenindividuellen CAMS-SchlüsselsErfassungsbogen von SchlüsselmaterialKurz-Bezeichnung desSchlüsselmaterialsSK.CAMS.ENC /SK.CAMS.AUTVerantwortlicherEinsatzumgebungKomponenteBeschreibung des SchlüsselmaterialseGKKartenindividuelle Schlüsselfür die gegenseitige Authentisierungim Rahmen derInteraktion zwischen eGKund zugehörigem CAMS (z.B. für das Nachladen vonAnwendungen).Typ des Schlüsselmaterials Zurzeit sym. 2TDESSchlüssel mit 112 bitSchlüssellänge. BSI.2TDES: bis Ende 2009,3TDES: bis Ende 2013:AES-128, AES-192, AES-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 622 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von Schlüsselmaterial256: bis Ende 2013. FürKarten, die ab 2010 ausgegebenwerden, muss eineMigration von 2TDES aufAES oder 3TDES erfolgen.Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungAnwendung in welchemSicherheitsverfahrenggf. Zuordnung zu einerPKIMaximale Gültigkeitsdauer/typische GültigkeitsdauerSymmetrische Schlüssel zurAuthentifikation und Etablierungvon Sessionkeys fürMAC-Berechnung und Verschlüsselung-Lebensdauer einer eGK(eventuell Konflikt mit TR-03116)SchlüsselerzeugungIst ein Backup bei derSchlüsselerzeugung vorgesehen?In der so genannten Kartenproduktion(Initialisierung,Personalisierung, Auslieferung)der eGK-CA: VarianteA: Jede Karte ein eigenerzufälliger Schlüssel, VarianteB: Ableitung aus einemCAMS-MasterkeyunklareGK-CAU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)SchlüsselregistrierungErzeugung eines Schlüssel-Zertifikatsunklar, zumindest VersionierungneinSchlüsselverteilungVariante A: Schlüssel vonKartenproduktion an CAMS-Dienst versenden. VarianteB: Hilfsschlüssel von Kartenproduktionan CAMS-Dienst versenden.CAMSeGK:U2:Sicherheitsmodul,Chipkarte,geschützterBereich;CAMS: U14Rechenzentrum,kontrollierterBereich,Sicherheitsbereichgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 623 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialSchlüsselinstallationSchlüsselspeicherungIst ein Backup bei Schlüsselspeicherungvorgesehen?SchlüsselableitungSchlüsselarchivierungAuf der eGK während derPersonalisierung1.In der eGK2.Zumindest temporär ineGK-CA3.Im CAMS-Dienstja, zumindest 1. In eGK-CA2. In CAMSVariante A: Keine, VarianteB: aus Masterkeynicht vorgesehen1.Kartenhersteller2. eGK-CA3. CAMS-Dienst1. In eGK-CA2. Im CAMSKartenproduktionÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherCAMSEinsatzumgebungeGK:U2:Sicherheitsmodul,Chipkarte,geschützterBereich;CAMS: U14Rechenzentrum,kontrollierterBereich,SicherheitsbereicheGK:U2:Sicherheitsmodul,Chipkarte,geschützterBereich;eGK-CA,CAMS: U14Rechenzentrum,kontrollierterBereich,SicherheitsbereichU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)U14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)Festgelegter Verwendungszweckdes SchlüsselsZur Authentifikation undEtablierung von Sessionkeysfür MAC-Berechnungund Verschlüsselung ausschließlichmit dem CAMS.Kartenherausgebergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 624 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialWer hat die Zugriffsrechte ? der CAMS-DienstÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungWie wird der Zugriff geschützt?Aufheben der Registrierungeines Schlüssels/SchlüsselzertifikatsDurch die Kenntnis desCAMS-Schlüssel kann derSchlüssel In Rahmen desAuthentifikationsprotokollszwischen EGK und eGK-CAausgehandelt werden.-Wie wird der Schlüssel(wenn zulässig) nur suspendiert?Wie wird der Schlüssel(wenn zulässig) wieder aktiviert?Wie wird der Schlüsselendgültig gelöscht/gesperrt?Wie wird eine Kompromittierungdes Schlüssels erfasst?Maßnahmen bei Kompromittierungdes Schlüsselsverantwortlich während desBetriebsnicht vorgesehennicht vorgesehenunklar CAMS-Dienst CAMS: U14Rechenzentrum,kontrollierterBereich,Sicherheitsbereichunklar CAMS-Dienst CAMS: U14Rechenzentrum,kontrollierterBereich,Sicherheitsbe-unklar, zumindest muss derGebrauch des CAMS-Schlüssels organisatorischunterbunden werden.CAMSCAMS-DienstreicheGK:U2:Sicherheitsmodul,Chipkarte,geschützterBereich;CAMS: U14Rechenzentrum,kontrollierterBereich,Sicherheitsbereichgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 625 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsDie Schlüsselerzeugung desMaster-CAMS-Schlüssels dereGK findet im geschütztenBereich eines Sicherheitsmodulsstatt, dieses befindet sichdabei im Sicherheitsbereichdes Rechenzentrums desKartenherausgebers. DerMaster-CAMS-Schlüssel wirdsofort nach Erzeugung imgeschützten Teil eines Sicherheitmodulsuntergebracht.Ein Master-CAMS-Schlüsseldarf ein Sicherheitsmodul inKlartext, sondern nur imRahmen festgelegter Verfahrenund verschlüsselt mit einemvon der gematik zugelassenenKrypto-Verfahrenverlassen.Alle kryptographischen Berechnungenmit dem Master-CAMS-Schlüssel müsseninnerhalb eines Sicherheitsmodulserfolgen. Der Zugriffauf den Master-CAMS-Schlüssel in einem Sicherheitsmodulmuss durch eineAuthentifikation geschütztsein. Die Zugriffe müssenprotokolliert werden, dasZugriffssystem muss durchdie gematik zugelassen sein.U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)Tabelle 61: Umsetzung Schutzbedarf Kartenindividueller CAMS-SchlüsselKartenindividueller CAMS-SchlüsselSchutzbedarf CAMS-Schlüssel (So071 – StatischeSchlüssel)Vertraulichkeit sehr hochIntegrität hochVerfügbarkeit hochAuthentizität hochNichtabstreitbarkeit hochVorkommen des Schlüssels EinsatzumgebungUmsetzung des SchutzbedarfsZufallserzeugung nach TR-03116.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 626 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKartenindividueller CAMS-SchlüsselVorkommen des SchlüsselsSchlüsselverteilung: VarianteB: Der Master-CAMS-Schlüssel muss nach Erzeugungdem Kartenmanagementsicher übermittelt werden.Zur Produktion der eGKmuss er der Kartenproduktionsicher übermittelt werden.Ein Master-CAMS-Schlüsselmuss in einem Sicherheitsmodulder Kartenproduktionoder des Kartenmanagementsaktiv gelöscht werden, sobalder durch dieses Sicherheitsmodulnicht mehr benötigtwird.Die Schlüsselerzeugung deskartenindividueller CAMS-Schlüssels der eGK findet imgeschützten Bereich einesSicherheitsmoduls statt, diesesbefindet sich dabei imSicherheitsbereich des Rechenzentrumsdes Kartenherausgebers.Der kartenindividuellerCAMS-Schlüssel wirdsofort nach Erzeugung imgeschützten Teil eines Sicherheitmodulsuntergebracht.Ein kartenindividuellerCAMS-Schlüssel darf ein Sicherheitsmodulin Klartext,sondern nur im Rahmen festgelegterVerfahren und verschlüsseltmit einem von dergematik zugelassenen Krypto-Verfahren verlassen.EinsatzumgebungChipkarte, geschützterBereich U2 = U_SC_protU2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)Schutzbedarf CAMS-Schlüssel (So071 – StatischeSchlüssel)Vertraulichkeit sehr hochIntegrität hochVerfügbarkeit hochAuthentizität hochNichtabstreitbarkeit hochUmsetzung des SchutzbedarfsErstverteilung T1 Postzustellung,Zweitverteilung T3:Postzustellung mit Ident-Prüfung oder gleichwertigeErsatzverfahrenVertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Variante A: Zufallserzeugungnach TR-03116.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Rechenzentrumumzusetzen.Variante B: Zusätzlich Schutzdes CAMS-Masterkeys mitnoch höheren Anforderungen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Rechenzentrumumzusetzen.Kritisch:Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 627 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKartenindividueller CAMS-SchlüsselVorkommen des SchlüsselsAlle kryptographischen Berechnungenmit dem kartenindividuellenCAMS-Schlüsselmüssen im CAMS_Dienstinnerhalb eines Sicherheitsmodulserfolgen. Der Zugriffauf den kartenindividuellerCAMS-Schlüssel in einemSicherheitsmodul muss durcheine Authentifikation geschütztsein. Die Zugriffemüssen protokolliert werden,das Zugriffssystem mussdurch die gematik zugelassensein.Ein kartenindividueller CAMS-Schlüssel muss in einem Sicherheitsmodulder Kartenproduktionoder des Kartenmanagementsaktiv gelöschtwerden, sobald er durch diesesSicherheitsmodul nichtmehr benötigt wird.Schlüsselverteilung: VarianteA: Der kartenindividuelleCAMS-Schlüssel der eGKmuss von der Kartenproduktionzum Kartenmanagementsicher übermittelt werden.Schlüsselspeicherung: Derkartenindividuelle CAMS-Schlüssel der eGK wird imgeschützten Teil der eGKuntergebracht. Zum Authentifizierenund Aushandeln vonSession-Keys verlässt derSchlüssel die Karte nicht.Schlüsselverteilung: Der kartenindividuelleCAMS-Schlüssel in der eGK wird imZuge der Verteilung der eGKmit verteilt.EinsatzumgebungU2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)Chipkarte, geschützterBereich U2 = U_SC_protChipkarte, geschützterBereich U2 = U_SC_protSchutzbedarf CAMS-Schlüssel (So071 – StatischeSchlüssel)Vertraulichkeit sehr hochIntegrität hochVerfügbarkeit hochAuthentizität hochNichtabstreitbarkeit hochUmsetzung des SchutzbedarfsVertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Rechenzentrumumzusetzen.Die Chipkarten sind dafürevaluiert den SchutzbedarfumzusetzenErstverteilung T1 Postzustellung,Zweitverteilung T3:Postzustellung mit Ident-Prüfung oder gleichwertigeErsatzverfahrengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 628 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

F5.2.3 - Privater Schlüssel der eGK zur AuthentifikationKurz-Bezeichnung desSchlüsselmaterialsPrK.CH.AutKomponenteeGKBeschreibung des SchlüsselmaterialthentifikationPrivater Schlüssel zur Au-PrK.CH.AUTTyp des Schlüsselmaterials asym. Privater SchlüsselÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 62: Lebenszyklus des Privaten Schlüssel der eGK zur AuthentifikationVerantwortlicherErfassungsbogen von SchlüsselmaterialEinsatzumgebungAnwendung in welchemSicherheitsverfahrenRSA nach X.509V3, Authentifizierungggf. Zuordnung zu einerPKIMaximale Gültigkeitsdauer/typische GültigkeitsdauerX.509V3-PKI unter Bridge-CABei Verwendung 1024 BitRSA oder SHA-1 bis Ende2007, bei 2048 Bit RSAund SHA-256 5 Jahre.Schlüsselerzeugung Im Trustcenter der eGK-CA eGK-CA U14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)Ist ein Backup bei derSchlüsselerzeugung vorgesehen?SchlüsselregistrierungneinJa, im Trustcenter der eGK-CAeGK-CAU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 629 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialErzeugung eines Schlüssel-ZertifikatsSchlüsselverteilungSchlüsselinstallationSchlüsselspeicherungIst ein Backup bei Schlüsselspeicherungvorgesehen?SchlüsselableitungSchlüsselarchivierungJa, im Trustcenter der eGK-CA und Verwendung desprivaten X509V3-Schlüsselder eGK-CAIm Zuge der Verteilung dereGKIm Trustcenter der eGK-CAauf die eGKNur auf der eGK/DF.ESIGN/EF.Prk/PrK.CH.AUT KeyRef '82'neinnicht zulässignicht vorgesehenKartenherausgebereGK-CAeGK-CAÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlichereGK-CAEinsatzumgebungU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)PrivaterSchlüssel inSicherheitsmodul,geschützterBereichU2, U4,U6Erstvertei-lungT1 Postzustellung,Zweitvertei-lungT3:Postzustellungmit Ident-PrüfungU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)eGK U2: Sicherheitsmodul,Chipkarte,geschützterBereichFestgelegter Verwendungszweckdes SchlüsselsAuthentifizierungWer hat die Zugriffsrechte ? Inhaber der eGKWie wird der Zugriff geschützt?Durch PIN.ch geschütztgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 630 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialAufheben der Registrierungeines Schlüssels/SchlüsselzertifikatsWie wird der Schlüssel(wenn zulässig) nur suspendiert?Sperrung des zugehörigenAUT-Zertifikats. über denOCSP-Servernicht zulässigÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherKartenherausgeberEinsatzumgebungU13 Rechenzentrum,kontrollierterBereich,geschützterBereich(OCSP-Server)Wie wird der Schlüssel(wenn zulässig) wieder aktiviert?Wie wird der Schlüsselendgültig gelöscht/gesperrt?Wie wird eine Kompromittierungdes Schlüssels erfasst?nicht zulässigDie faktische Außerbetriebnahmedes Privaten Signaturschlüsselder eGK nachVerwendung, erfolgt durch:a) vorzeitige Außerbetriebnahmeder eGK oder,b) wiederholte falsche PIN-Eingabe oder,c) durch Sperrung des Zertifikatsoder,d) durch Ablauf des Gültigkeitszeitraumsdes Zertifikats.a) Kartenherausgeberb) Inhaberder Kartec) Kartenherausgeberd) ausführen-deKompo-nenteNachricht an die gematik gematik N.N.c) U13 Rechen-zentrum,kontrollierterBereich, geschützterBereich(OCSP-Server)Maßnahmen bei Kompromittierungdes SchlüsselsBenachrichtigung der gematik,Sperrung des zugehörigenAUT-Zertifikatsgematik,KartenherausgeberU13 Rechenzentrum,kontrollierterBereich,geschützterBereich(OCSP-Server)verantwortlich während desBetriebsder Versicherte = KarteninhaberUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsTabelle 63: Umsetzung Schutzbedarf Privater Schlüssel der eGK zur Authentikationgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 631 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPrivate-Key (Signatur) dereGKVorkommen des SchlüsselsDie Schlüsselerzeugung desPrivaten Signaturschlüsselsder eGK findet im geschütztenBereich eines Sicherheitsmodulsstatt, dieses befindet sichdabei im Sicherheitsbereichdes Rechenzentrums desKartenherausgebers. Der PrivatenSignaturschlüssel wirdsofort nach Erzeugung imgeschützten Teil eines Sicherheitmodulsuntergebracht.Ein Privater Signaturschlüsseldarf ein Sicherheitsmodulin Klartext, sondern nur imRahmen festgelegter Verfahrenund verschlüsselt mit einemvon der gematik zugelassenenKrypto-Verfahrenverlassen.Alle kryptographischen Berechnungenmit dem PrivatenSignaturschlüssel müsseninnerhalb eines Sicherheitsmodulserfolgen. Der Zugriffauf den Privaten Signaturschlüsselin einem Sicherheitsmodulmuss durch eineAuthentifikation geschütztsein. Die Zugriffe müssenprotokolliert werden, dasZugriffssystem muss durchdie gematik zugelassen sein.Ein Privater Signaturschlüsselmuss in einem Sicherheitsmodulder Kartenproduktionaktiv gelöscht werden, sobalder durch dieses Sicherheitsmodulnicht mehr benötigtwird.EinsatzumgebungU2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)Schutzbedarf So079 - PrivaterSignaturschlüssel dereGKVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit sehr hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochUmsetzung des SchutzbedarfsZufallserzeugung nach TR-03116.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 632 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPrivate-Key (Signatur) dereGKVorkommen des SchlüsselsErzeugung eine Zertifikats fürden Öffentlichen Signaturschlüsselder eGK passendzum Privaten Signaturschlüsselder eGK, im Sicherheitsbereichdes Rechenzentrumsder CA. Hierbei wird der PrivateSignaturschlüssel dereGK nicht benutzt.Schlüsselverteilung: Der PrivateSignaturschlüssel in dereGK wird im Zuge der Verteilungder eGK mit verteilt.Schlüsselspeicherung: DerPrivate Signaturschlüssel wirdim nicht auslesbaren Teil dereGK untergebracht. Zum Signierenverlässt der Schlüsseldie Karte nicht.Benutzung des Schlüssels:Die Nutzung des PrivatenSignaturschlüssels der eGKist mit PIN geschützt.Die faktische Außerbetriebnahmedes Privaten Signaturschlüsselder eGK nach Verwendung,erfolgt durch:a) vorzeitige Außerbetriebnahmeder eGK oder,b) wiederholte falsche PIN-Eingabe oder,c) durch Sperrung des Zertifikatsoder,d) durch Ablauf des Gültigkeitszeitraumsdes Zertifikats.EinsatzumgebungU14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)Chipkarte, geschützterBereich U2 = U_SC_protChipkarte, geschützterBereich U2 = U_SC_protChipkarte, geschützterBereich U2 = U_SC_protSchutzbedarf So079 - PrivaterSignaturschlüssel dereGKVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit sehr hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochUmsetzung des SchutzbedarfsIntegrität, Authentizität undNichtabstreitbarkeit des ÖffentlichenSignaturschlüsselder eGK (und damit indirektauch Integrität, Authentizitätund Nichtabstreitbarkeit desPrivaten Signaturschlüsselder eGK) wird durch die Signaturdes Zertifikats durch dieCA gesichert.Erstverteilung T1 Postzustellung,Zweitverteilung T3:Postzustellung mit Ident-Prüfung oder gleichwertigeErsatzverfahrenDie Chipkarten sind dafürevaluiert den Schutzbedarfwie für den Privaten Signaturschlüsselverlangt, umzusetzenDas PIN-Verfahren ist aufhohem Niveaus durchzuführen.Besitz der eGK und Wissender PIN gemeinsam gewährleistendie hochwertigeAuthentifikation.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 633 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

F5.2.4 - Privater CVC Schlüssel der eGK zur AuthentifikationKurz-Bezeichnung desSchlüsselmaterialsPrK.eGK.AUTÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 64: Lebenszyklus des Privaten CVC Schlüssel der eGK zur AuthentifikationVerantwortlicherErfassungsbogen von SchlüsselmaterialEinsatzumgebungKomponenteBeschreibung des SchlüsselmaterialsTyp des SchlüsselmaterialseGKFür C2C-Authentisierungsverfahrenauf Basis vonCV-Zertifikaten wird derprivate SchlüsselPrK.eGK.AUT für diegegenseitige Authentisierungvon eGK/HPC undeGK/SMC verwendet.Für die C2C-Authentisierng bei lokalenInteraktionen zwischeneGK und HPCbzw. eGK und SMC wirdein Authentisierungsprotokollohne Vereinbarungvon Sitzungsschlüsselnverwendetasym. Privater SchlüsselAnwendung in welchem SicherheitsverfahrenRSA, CVC-Authentifizierungggf. Zuordnung zu einer PKIMaximale Gültigkeitsdauer/typische GültigkeitsdauerSchlüsselerzeugungCV-PKI unter der CV-Root der gematikBei Verwendung 1024Bit RSA oder SHA-1 bisEnde 2007, bei 2048 BitRSA und SHA-256 5Jahre.Im Trustcenter der eGK-CAeGK-CAU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)Ist ein Backup bei der Schlüsselerzeugungvorgesehen ?neingematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 634 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialSchlüsselregistrierungErzeugung eines Schlüssel-ZertifikatsSchlüsselverteilungSchlüsselinstallationSchlüsselspeicherungJa, im Trustcenter dereGK-CAJa, im Trustcenter dereGK-CA und Verwendungdes privaten CV-Schlüssel der eGK-CAIm Zuge der Verteilungder eGKIm Trustcenter der eGK-CA auf die eGKNur auf der eGK inEF.PrK , Key ID 10,SE#1 und SE#2eGK-CAKartenherausgebereGK-CAeGK-CAÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlichereGK-CAEinsatzumgebungU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)U14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter),PrivaterSchlüssel inSicherheitsmodul,geschützterBereichU2, U4,U6ErstverteilungT1 Postzustellung,ZweitverteilungT3:Postzustellungmit Ident-Prüfung odergleichwertigeErsatzverfahrenU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)eGK U2: Sicherheitsmodul,Chipkarte,geschützterBereichIst ein Backup bei Schlüsselspeicherungvorgesehen ?SchlüsselableitungSchlüsselarchivierungFestgelegter Verwendungszweckdes Schlüsselsneinnicht zulässignicht vorgesehenCVC-Authentifizierungohne Schlüsselvereinbarunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 635 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialWer hat die Zugriffsrechte ?Inhaber der eGKÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungWie wird der Zugriff geschützt?Wie wird der Schlüssel (wennzulässig) nur suspendiert?Nur durch sichere Handhabungder eGK, keinePIN vorgesehennicht vorgesehennicht zulässigAufheben der Registrierungeines Schlüssels/SchlüsselzertifikatsKartenherausgeberU13 Rechenzentrum,kontrollierterBereich,geschützterBereich(OCSP-Server)Wie wird der Schlüssel (wennzulässig) wieder aktiviert?nicht zulässigWie wird der Schlüssel endgültiggelöscht/gesperrt?1. Austausch des CV-Root-Zertifikats. 2. Ü-berschreitung des Gültigkeitszeitraumsdeszugehörigen CV-Zertifikats.KartenherausgeberU13 Rechenzentrum,kontrollierterBereich,geschützterBereich(OCSP-Server)Wie wird eine Kompromittierungdes Schlüssels erfasst?Nachricht an die gematik gematikN.N.Maßnahmen bei Kompromittierungdes SchlüsselsBenachrichtigung dergematikgematik, KartenherausgeberU13 Rechenzentrum,kontrollierterBereich,geschützterBereich(OCSP-Server)verantwortlich während desBetriebsder Versicherte = KarteninhaberUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsTabelle 65: Umsetzung Schutzbedarf Privater CVC Schlüssel der eGKgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 636 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPrivater CVC-Key der eGKVorkommen des SchlüsselsDie Schlüsselerzeugung desPrivaten CVC-Schlüssels dereGK findet im geschütztenBereich eines Sicherheitsmodulsstatt, dieses befindet sichdabei im Sicherheitsbereichdes Rechenzentrums desKartenherausgebers. DerCVC-Schlüssel wird sofortnach Erzeugung im geschütztenTeil eines Sicherheitmodulsuntergebracht.Ein Privater CVC-Schlüssel ldarf ein Sicherheitsmodul inKlartext, sondern nur imRahmen festgelegter Verfahrenund verschlüsselt mit einemvon der gematik zugelassenenKrypto-Verfahrenverlassen.Alle kryptographischen Berechnungenmit dem PrivatenCVC-Schlüssel müssen innerhalbeines Sicherheitsmodulserfolgen. Der Zugriff aufden Privaten Signaturschlüsselin einem Sicherheitsmodulmuss durch eine Authentifikationgeschützt sein. Die Zugriffemüssen protokolliert werden,das Zugriffssystem mussdurch die gematik zugelassensein.Ein Privater CVC-Schlüsselmuss in einem Sicherheitsmodulder Kartenproduktionaktiv gelöscht werden, sobalder durch dieses Sicherheitsmodulnicht mehr benötigtwird.Erzeugung eines Zertifikatsfür den Öffentlichen CVC-Schlüssel der eGK passendEinsatzumgebungU2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U14 Rechenzentrum,kontrollierter Bereich,SicherheitsbereichSchutzbedarf So083 - PrivaterCVC-Key der eGKVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochUmsetzung des SchutzbedarfsZufallserzeugung nach TR-03116.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Integrität, Authentizität undNichtabstreitbarkeit des ÖffentlichenCVC-Schlüsselsgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 637 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPrivater CVC-Key der eGKVorkommen des Schlüsselszum Privaten CVC-Schlüsselder eGK, im Sicherheitsbereichdes Rechenzentrumsder CA. Dabei wird das Zertifikatmit dem Privaten CVC-CA-Schlüssel signiert. Hierbeiwird der Private CVC-Schlüssel der eGK nicht benutzt.Schlüsselverteilung: Der PrivateCVC-Schlüssel l in dereGK wird im Zuge der Verteilungder eGK mit verteilt.Schlüsselspeicherung: DerPrivate CVC-Schlüssel wirdim nicht auslesbaren Teil dereGK untergebracht. Zum Signierenverlässt der Schlüsseldie Karte nicht.Benutzung des Schlüssels:Die Nutzung des PrivatenCVC-Schlüssel der eGK istmit PIN geschützt.Die faktische Außerbetriebnahmedes Privaten CVC-Schlüssel der eGK nach Verwendung,erfolgt durch:a) vorzeitige Außerbetriebnahmeder eGK oder,d) durch Ablauf des Gültigkeitszeitraumsdes Zertifikats.Einsatzumgebung(Trustcenter)Chipkarte, geschützterBereich U2 = U_SC_protChipkarte, geschützterBereich U2 = U_SC_protChipkarte, geschützterBereich U2 = U_SC_protSchutzbedarf So083 - PrivaterCVC-Key der eGKVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochUmsetzung des Schutzbedarfsder eGK (und damit indirektauch Integrität, Authentizitätund Nichtabstreitbarkeit desPrivaten CVS_Schlüssel dereGK) wird durch die Signaturdes Zertifikats durch die CAgesichert.Erstverteilung T1 Postzustellung,Zweitverteilung T3:Postzustellung mit Ident-Prüfung oder gleichwertigeErsatzverfahrenDie Chipkarten sind so hochevaluiert, dass sie demSchutzbedarf des PrivatenSignaturschlüssels gerechtwerden.Das PIN-Verfahren ist aufhohem Niveau durchzuführen.Besitz der eGK und Wissender PIN gemeinsam gewährleistendie hochwertigeAuthentifikation.F5.2.5 - Privater Schlüssel der HBA zur Qualifizierten Elektronischen SignaturTabelle 66: Lebenszyklus des Privaten Schlüssel der HBA zur QESVerantwortlicherErfassungsbogen von SchlüsselmaterialEinsatzumgebunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 638 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialKurz-Bezeichnung desSchlüsselmaterialsPrK.HP.QESKomponenteHBABeschreibung des SchlüsselmateriallifiziertenSignaturPrivater Schlüssel zur Qua-PrK.HP.QESTyp des Schlüsselmaterials asym. Privater SchlüsselÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungAnwendung in welchemSicherheitsverfahrenRSA nach X.509V3, QualifizierteSignaturggf. Zuordnung zu einer PKI X.509V3-PKI unter Bridge-CAMaximale Gültigkeitsdauer/typische GültigkeitsdauerBei Verwendung 1024 BitRSA oder SHA-1 bis Ende2007, bei 2048 Bit RSAund SHA-256 5 Jahre.Schlüsselerzeugung Im Trustcenter der HBA-CA HBA-CA U14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)Ist ein Backup bei derSchlüsselerzeugung vorgesehen?neinSchlüsselregistrierungJa, im Trustcenter der HBA-CAHBA-CAU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)Erzeugung eines Schlüssel-ZertifikatsJa, im Trustcenter der HBA-CA und Verwendung desprivaten X509V3-Schlüsselder HBA-CAHBA-CAU14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter),PrivaterSchlüssel inSicherheitsmodul,geschützterBereichU2, U4,U6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 639 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturErfassungsbogen von SchlüsselmaterialVerantwortlichegebungEinsatzum-Schlüsselverteilung Im Zuge der Verteilung derHBAKartenherausgeberErstverteilungT1 Postzustellung,ZweitverteilungT3:Postzustellungmit Ident-Prüfung odergleichwertigeErsatzverfahrenSchlüsselinstallation Im Trustcenter der HBA-CAauf die HBAHBA-CA U14 Rechenzentrum,kontrollierterBereich,Sicherheitsbereich(Trustcenter)Schlüsselspeicherung Nur auf der HBA HBA-CA HBA U2: Sicherheitsmodul,Chipkarte,geschützterBereichIst ein Backup bei Schlüsselspeicherungvorgesehen?SchlüsselableitungSchlüsselarchivierungFestgelegter Verwendungszweckdes Schlüsselsneinnicht zulässigGemäß SigGQualifizierten SignaturWer hat die Zugriffsrechte ? Inhaber der HBAWie wird der Zugriff geschützt?Aufheben der Registrierungeines Schlüssels/SchlüsselzertifikatsWie wird der Schlüssel(wenn zulässig) nur suspendiert?Durch PIN.QES geschütztSperrung des zugehörigenQES-Zertifikats. über denOCSP-Servernicht zulässigKartenherausgeberU13 Rechenzentrum,kontrollierterBereich,geschützterBereich(OCSP-Server)Wie wird der Schlüssel(wenn zulässig) wieder aktiviert?nicht zulässiggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 640 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialWie wird der Schlüsselendgültig gelöscht/gesperrt?Die faktische Außerbetriebnahmedes Privaten Signaturschlüsselder HBA nachVerwendung, erfolgt durch:a) vorzeitige Außerbetriebnahmeder HBA oder, b)wiederholte falsche PIN-Eingabe oder, c) durchSperrung des Zertifikatsoder,d) durch Ablauf desGültigkeitszeitraums desZertifikats.Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlichera) Kartenherausgeberb) Inhaberder Karte c)Kartenherausgeberd)ausführendeKomponenteEinsatzumgebungc) U13 Rechenzentrum,kontrollierterBereich, geschützterBereich(OCSP-Server)Wie wird eine Kompromittierungdes Schlüssels erfasst?Nachricht an die gematik gematik N.N.Maßnahmen bei Kompromittierungdes Schlüsselsverantwortlich während desBetriebsBenachrichtigung der gematik,Sperrung des zugehörigenAUT-Zertifikatsder Versicherte = Karteninhabergematik, KartenherausgeberU13 Rechenzentrum,kontrollierterBereich,geschützterBereich(OCSP-Server)Umsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsTabelle 67: Umsetzung des Schutzbedarfs Privater Schlüssel der HBA zur QESPrivate-Key (Signatur) derHBASchutzbedarf So079 - PrivaterSignaturschlüssel derHBAVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit sehr hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochVorkommen des Schlüssels EinsatzumgebungUmsetzung des Schutzbedarfsgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 641 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPrivate-Key (Signatur) derHBAVorkommen des SchlüsselsDie Schlüsselerzeugung desPrivaten Signaturschlüsselsder HBA findet im geschütztenBereich eines Sicherheitsmodulsstatt, dieses befindet sichdabei im Sicherheitsbereichdes Rechenzentrums desKartenherausgebers. Der PrivatenSignaturschlüssel wirdsofort nach Erzeugung imgeschützten Teil eines Sicherheitmodulsuntergebracht.Ein Privater Signaturschlüsseldarf ein Sicherheitsmodulin Klartext, sondern nur imRahmen festgelegter Verfahrenund verschlüsselt mit einemvon der gematik zugelassenenKrypto-Verfahrenverlassen.Alle kryptographischen Berechnungenmit dem PrivatenSignaturschlüssel müsseninnerhalb eines Sicherheitsmodulserfolgen. Der Zugriffauf den Privaten Signaturschlüsselin einem Sicherheitsmodulmuss durch eineQualifizierten Signatur geschütztsein. Die Zugriffemüssen protokolliert werden,das Zugriffssystem mussdurch die gematik zugelassensein.Ein Privater Signaturschlüsselmuss in einem Sicherheitsmodulder Kartenproduktionaktiv gelöscht werden, sobalder durch dieses Sicherheitsmodulnicht mehr benötigtwird.EinsatzumgebungU2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)U2,U4,U6 Sicherheitsmodul,U14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)Schutzbedarf So079 - PrivaterSignaturschlüssel derHBAVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit sehr hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochUmsetzung des SchutzbedarfsZufallserzeugung nach TR-03116.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.Vertraulichkeit, Integrität, Verfügbarkeit,Authentizität undNichtabstreitbarkeit vom Sicherheitsmodulund der Umgebung(Rechenzentrum)umzusetzen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 642 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPrivate-Key (Signatur) derHBAVorkommen des SchlüsselsErzeugung eine Zertifikats fürden Öffentlichen Signaturschlüsselder HBA passendzum Privaten Signaturschlüsselder HBA, im Sicherheitsbereichdes Rechenzentrumsder CA. Hierbei wird der PrivateSignaturschlüssel derHBA nicht benutzt.Schlüsselverteilung: Der PrivateSignaturschlüssel in derHBA wird im Zuge der Verteilungder HBA mit verteilt.Schlüsselspeicherung: DerPrivate Signaturschlüsselwird im nicht auslesbaren Teilder HBA untergebracht. ZumSignieren verlässt der Schlüsseldie Karte nicht.Benutzung des Schlüssels:Die Nutzung des PrivatenSignaturschlüssels der HBAist mit PIN geschützt.Die faktische Außerbetriebnahmedes Privaten Signaturschlüsselder HBA nach Verwendung,erfolgt durch :a) vorzeitige Außerbetriebnahmeder HBA oder,b) wiederholte falsche PIN-Eingabe oder,c) durch Sperrung des Zertifikatsoder,d) durch Ablauf des Gültigkeitszeitraumsdes Zertifikats.EinsatzumgebungU14 Rechenzentrum,kontrollierter Bereich,Sicherheitsbereich(Trustcenter)Chipkarte, geschützterBereich U2 = U_SC_protChipkarte, geschützterBereich U2 = U_SC_protChipkarte, geschützterBereich U2 = U_SC_protSchutzbedarf So079 - PrivaterSignaturschlüssel derHBAVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit sehr hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochUmsetzung des SchutzbedarfsIntegrität, Authentizität undNichtabstreitbarkeit des ÖffentlichenSignaturschlüsselder HBA (und damit indirektauch Integrität, Authentizitätund Nichtabstreitbarkeit desPrivaten Signaturschlüsselder HBA) wird durch die Signaturdes Zertifikats durch dieCA gesichert.Erstverteilung T1 Postzustellung,Zweitverteilung T3:Postzustellung mit Ident-Prüfung oder gleichwertigeErsatzverfahrenDie Chipkarten sind dafürevaluiert den Schutzbedarfwie für den Privaten Signaturschlüsselverlangt, umzusetzenDas PIN-Verfahren ist aufhohem Niveaus durchzuführen.Besitz der HBA und Wissender PIN gemeinsam gewährleistendie hochwertigeQualifizierten Signatur.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 643 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

F5.2.6 - Passwörter für User und Admin KartenterminalErfassungsbogen von SchlüsselmaterialKurz-Bezeichnung des SchlüsselmaterialsAdminPasswörter für User undKomponenteKartenterminalBeschreibung des SchlüsselmaterialsPasswörter für User undAdmin zur Authentifizierungim SICCT-Modusals auch im Webinterfacedes KTTyp des Schlüsselmaterials PasswortAnwendung in welchem Sicherheitsverfahrenggf. Zuordnung zu einer PKI -Maximale Gültigkeitsdauer unbegrenzt/typische GültigkeitsdauerSchlüsselerzeugungPasswort-Authentifizierunginitial: herstellerspezifisch(z. B. Default-Passwort)Ist ein Backup bei der Schlüsselerzeugungvorgesehen ? neinSchlüsselregistrierung neinErzeugung eines Schlüssel-ZertifikatsneinSchlüsselverteilungneinSchlüsselinstallationneinSchlüsselspeicherungKartenterminal, "sichereSpeicherung", z. B. alsnur Hashwert, verschl.durch FirmwareIst ein Backup bei Schlüsselspeicherungvorgesehen ? herstellerspezifischSchlüsselableitungneinSchlüsselarchivierungneinFestgelegter Verwendungszweckdes SchlüsselsUser und AdministratorAuthentifizierung vonWer hat die Zugriffsrechte ? KartenterminalWie wird der Zugriff geschützt? herstellerspezifischAufheben der Registrierungeines Schlüssels/Schlüsselzertifikats-Wie wird der Schlüssel (wennzulässig) nur suspendiert? -Wie wird der Schlüssel (wennzulässig) wieder aktiviert? -Wie wird der Schlüssel endgültiggelöscht/gesperrt? -HerstellerHerstellerHerstellerHerstellerHerstellerÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 68: Lebenszyklus der Passwörter für User und Admin KartenterminalVerantwortlicherEinsatzumgebunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 644 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialWie wird eine Kompromittierungdes Schlüssels erfasst? ?Maßnahmen bei Kompromittierungdes Schlüsselsverantwortlich während desBetriebsRelevante Spezifikationggf. ähnliches SchlüsselmaterialZusätzliche QuellenLeistungserbringer bzw.seine ServiceleuteeHealth-KT-SpecPassworte Konnektor-Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsTabelle 69: Hinweis auf Umsetzung des Schutzbedarfs Passwörter für User und Admin KartenterminalPasswörter für User und AdminKartenterminaltrauliche persönlicheSchutzbedarf DK11d Ver-AuthentikationsmittelVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit hochAuthentizität sehr hochNichtabstreitbarkeit sehrhochSiehe Kapitel PIN/PUK PolicyF5.2.7 - Passwörter für Admin-Passwort KonnektorTabelle 70: Lebenszyklus der Passwörter für Admin-Passwort KonnektorVerantwortlicherErfassungsbogen von SchlüsselmaterialKurz-Bezeichnung des Admin-Passwort KonnektorSchlüsselmaterialsKomponenteKonnektorBeschreibung des SchlüsselmaterialnistrationszugangPasswort, das den Admi-zumKonnektor schütztTyp des Schlüsselmaterials PasswortAnwendung in welchem SicherheitsverfahrenPasswort-Authentifizierungggf. Zuordnung zu einer PKI -Maximale Gültigkeitsdauer Manueller Wechsel/typische GültigkeitsdauerSchlüsselerzeugunginitial: herstellerspezifisch(z. B. Default-Passwort)KonnektorHerstellerEinsatzumgebunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 645 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialIst ein Backup bei der Schlüsselerzeugungvorgesehen ? unklarSchlüsselregistrierung neinErzeugung eines Schlüssel-ZertifikatsneinSchlüsselverteilungneinSchlüsselinstallationneinSchlüsselspeicherung Konnektor, "sichere Speicherung",z. B. als nurHashwertIst ein Backup bei Schlüsselspeicherungvorgesehen ? herstellerspezifischSchlüsselableitungneinSchlüsselarchivierung neinFestgelegter Verwendungszweckdes Schlüssels AuthentifizierungAdministrator-Wer hat die Zugriffsrechte ? KonnektorWie wird der Zugriff geschützt?herstellerspezifischAufheben der Registrierungeines Schlüssels/SchlüsselzertifikatsWie wird der Schlüssel (wennzulässig) nur suspendiert?Wie wird der Schlüssel (wennzulässig) wieder aktiviert?Wie wird der Schlüssel endgültiggelöscht/gesperrt?Wie wird eine Kompromittierungdes Schlüssels erfasst?Maßnahmen bei Kompromittierungdes Schlüsselsverantwortlich während desBetriebsLeistungserbringerRelevante Spezifikationggf. ähnliches SchlüsselmaterialZusätzliche QuellenKonSpecKonnektorHerstellerKonnektorHerstellerKonnektorHerstellerÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherKonnektorHerstellerEinsatzumgebungUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsTabelle 71: Hinweis Umsetzung Schutzbedarf Admin-Passwort Konnektorgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 646 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAdmin-Passwort KonnektorSiehe Kapitel PIN/PUK PolicySchutzbedarf DK11d VertraulichepersönlicheAuthentikationsmittelVertraulichkeit sehr hochIntegrität sehr hochVerfügbarkeit hochAuthentizität sehr hochNichtabstreitbarkeit sehr hochF5.2.8 - Privater Schlüssel zur Authentisierung im TLS-Protokoll KonnektorTabelle 72: Lebenszyklus des Privaten Schlüssel zur Authentisierung im TLS-ProtokollKonnektorErfassungsbogen von SchlüsselmaterialKurz-Bezeichnung desSchlüsselmaterialsPrK.HCI.AUTKomponenteAnwendungskonnektorBeschreibung des Schlüsselmaterialthentisierungim TLS-Privater Schlüssel zur Au-Protokoll, optionale Absicherungdes Verkehrs zwischenPS und KonnektorTyp des Schlüsselmaterials asym private keyAnwendung in welchem SicherheitsverfahrenRSAggf. Zuordnung zu einer PKI herstellerspezifisch, leis-Maximale Gültigkeitsdauer/typische GültigkeitsdauerSchlüsselerzeugungSchlüsselspeicherungtungserbringerspezifisch1024 Bit RSA oder SHA-1:bis Ende 20072048 Bit RSA und SHA-256: 5 Jahre.KonnektorneinKonnektorKonnektorKonnektorIst ein Backup bei Schlüsselspeicherungvorgesehen ? neinSchlüsselableitung nein -Schlüsselarchivierung nein -LeistungserbringerIst ein Backup bei der Schlüsselerzeugungvorgesehen?SchlüsselregistrierungErzeugung eines Schlüssel-ZertifikatsSchlüsselverteilungSchlüsselinstallationLeistungserbringerLeistungserbringerLeistungserbringerVerantwortlicherEinsatzumgebunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 647 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Wie wird der Schlüssel (wennzulässig) nur suspendiert?Wie wird der Schlüssel (wennzulässig) wieder aktiviert?Wie wird der Schlüssel endgültiggelöscht/gesperrt?Wie wird eine Kompromittierungdes Schlüssels erfasst?Maßnahmen bei Kompromittierungdes Schlüsselsverantwortlich während desBetriebsRelevante Spezifikationggf. ähnliches SchlüsselmaterialZusätzliche QuellenLeistungserbringergemX.509_KonPKI-Dokumente, BetriebsdokumenteAufheben der Registrierungeines Schlüssels/SchlüsselzertifikatsLeistungserbringerLeistungserbringerLeistungserbringerLeistungserbringerLeistungserbringerLeistungserbringerÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherErfassungsbogen von SchlüsselmaterialFestgelegter Verwendungszweckdes Schlüssels TLSWer hat die Zugriffsrechte ? AnwendungskonnektorWie wird der Zugriff geschützt?herstellerspezifisch HerstellerEinsatzumgebungUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des SchlüsselsTabelle 73: Umsetzung Schutzbedarf Privater Schlüssel zur TLS Authentisierung KonnektorPasswörter für User und AdminKartenterminaleines Telematikservices (SSL)Schutzbedarf: Private-KeysVertraulichkeit hochIntegrität hochVerfügbarkeit hochAuthentizität hochNichtabstreitbarkeit hoch1. Methode: Einbringen über eine Chipkarte/Sicherheitsmodul siehe das LebenszykluseGK-Schlüssel.Andere Methode werden noch abgestimmt.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 648 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF6 - Sicherheitsvorfälle und NotfallmaßnahmenDieses Kapitel beschreibt eine abgestufte Hierarchie der Sicherheitsvorfälle, die Anforderungan Notfallmaßnahmen wie Schlüssellöschung, Sperrung von Zertifikaten, eventgetriebenerTausch von Schlüsseln, Umstieg auf vorgesehene Ausweichverfahren,F6.1 - Maßnahmen, die in jedem Kryptosystem vorzusehen sind: Ersetzenvon SchlüsselnIn jedem Kryptosystem ist ein sicheres Verfahren vorzusehen, um Schlüssel zu ersetzen.Die Schlüssel können ja nicht nur durch das Brechen des prinzipiellen Kryptoverfahrens,sondern auch durch physikalische oder organisatorische Lücken kompromittiert werden.In Systemen, die im Dauerbetrieb sind, sollten Schlüssel immer nur einen bestimmtenZeitraum gelten bzw. MÜSSEN regelmäßig ausgetauscht werden.Bei Chipkarten erfolgt dies Schlüsselaustausch durch Austausch der Karte.Bei Sicherheitsvorfällen MUSS dieser Austausch vorgezogen werden können.Es gibt folgende Möglichkeiten Schlüssel, die in Karten gespeichert sind, auszutauschen:• Austausch von Schlüsseln in Karten, Variante 1. Einen sicheren Nachlademechanismusfür Schlüssel einführen. Ist bisher nicht vorgesehen.• Austausch von Schlüsseln in Karten, Variante 2. Ausgabe neuer Karten mitneuen Schlüsseln. Sehr aufwändig. In der Regel ist damit aber auch eine Zeitlang Parallelbetrieb beider Schlüsselsysteme nötig. Ist Parallelbetrieb nichtmöglich, dadurch zu realisieren, dass nach Erkennen der Bedrohung Kartenmit beiden Schlüsseln ausgegeben werden und wenn genügend Karten mitden neuen Schlüssel im Feld sind, das System (i. d. R. die Konnektoren)komplett umschaltet.• Austausch von Schlüsseln in Karten, Variante 2b. Gleich Karten mit zweiSchlüsselsystemen ausgeben. Der zweite Schlüsselsatz wird gleich mit eingebracht.Da alle Karten den neuen Schlüssel schon haben, kann, das System(i. d. R. die Konnektoren) komplett umschalten. Danach würde dann Kartenmit dem Zweiten und einem neuen, dritten Schlüssel ausgegeben werdenusw. Nachteil: Alle Karten müssen mit zwei Schlüsselsätzen ausgestattet werden.Bei Angriffen gegen das Kryptoverfahren an sich, wäre der zweiteSchlüssel auch bald gebrochen.F6.2 - Anpassungen der Kryptoverfahren, die vorgesehen werden MÜSSENF6.2.1 - Wechsel der HashfunktionDa in der Vergangenheit fast alle standardisierten Hashfunktionen irgendwann Schwächenaufwiesen, ist auch bei den Hashfunktionen, die die TI verwendet damit zu rechnen.• Außerhalb von Chipkarten: Austausch der Hashfunktion in der Kryptobibliothek.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 649 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Anpassbarkeit der Signaturschemata an andere Hashfunktionen (Hashfunktionenwerden in der Regel Außerhalb der Chipkarte berechnet.)• Wahl einer hochwertigen Hashfunktionen zur Signatur der CV-Zertifikate(werden in der Chipkarte ausgewertet)F6.3 - Anpassungen der Kryptoverfahren, die vorgesehen werden KÖNNENF6.3.1 - Vergrößerung der RSA-SchlüssellängeSoll die RSA-Schlüssellänge erhöht werden, dann sind:• Alle RSA-Schlüssel auszutauschen (siehe F7.1)• Anpassung der Signaturschemata an größere RSA-Schlüssellänge• Anpassung der Speicherressourcen und Übertragungslängen an größere Signaturen, größere Objekttickets, längere Authentikationen. RSA-Schlüssellänge• Neuverschlüsseln aller Objekttickets (wie bei DATENERHALT)• Nachsignieren aller persistenten SignaturenF6.4 - Vorgaben zur Alarmierung bei kryptographischen Problemenanhalten4 Sofort mitzuteilen, Betriebanhalten, Eingriff nur nachRückspracheSecurity Alarm Bezeichnung Reaktion0 Gering e Bedeutung Keine Meldung, lokal lösen1 Mitzuteilen Meldung im Rahmen des Berichtswesens, lokal lösen.2 Sofort mitzuteilen Sofortige Meldung, lokal lösen.3 Sofort mitzuteilen, Betrieb Sofortige Meldung, lokal lösen, Wiederaufnahme erst nach Rücksprache(und ggf. weiteren Maßnahmen).Sofortige Meldung, lokal lösen Wiederaufnahme erst nach Rücksprache,Wiederaufnahme erst nach Wiederfreigabe, ggf Sperrungvon Zertifikaten.5 Betrieb einstellen Sofortige Meldung, Betreib einstellen, alle Zulassungen und Zertifikatesperrengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 650 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF6.5 – Zusammenfassung der AusgangsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_03237A_03238SSKrypto_Notfall_01:Notfallmaßnahmenzum Ersetzen vonSchlüsseln.Krypto_Notfall_02:Notfallmaßnahmenzum Wechsel derHashfunktionMaßnahmen, die in jedem Kryptosystem vorzusehen sind:Ersetzen von Schlüsseln:In Systemen, die im Dauerbetrieb sind, sollten Schlüssel immernur einen bestimmten Zeitraum gelten bzw. MÜSSENregelmäßig ausgetauscht werden.Bei Chipkarten erfolgt dies Schlüsselaustausch durch Austauschder Karte.Bei Sicherheitsvorfällen MUSS dieser Austausch vorgezogenwerden könnenAnpassungen der Kryptoverfahren, die vorgesehen werdenMÜSSEN:Wechsel der HashfunktionAnhang6Anhang6FFgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 651 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturF7 - Kryptographische EntitätenNotwendiges Ziel des Übergreifendem Sicherheitskonzepts ist eine möglichst vollständigeBeschreibung des in der Telematikinfrastruktur benutzten kryptographischen Schlüsselmaterialsund seines Lebenszyklus.Dazu wurde mit einem Fragebogen („Erfassungsbogen von Schlüsselmaterial“ s. u.) der Ist-Stand erfasst und eine abgestimmte Liste des Schlüsselmaterials erstellt, die in einem gesondertenDokument vorliegt.Es ist klar, dass eine solche Liste ständig gepflegt werden muss. Dazu kann wieder der Fragebogenbenutzt werden. Hilfreich sind auch die exemplarisch ausgefüllten Fragebögen zumLebenszyklen mit Ortsangaben in F6.3.3.1ff., denn die Bedingungen sind oft ähnlich.Erfassungsbogen von SchlüsselmaterialKurz-Bezeichnung des SchlüsselmaterialsKomponenteBeschreibung des SchlüsselmaterialsTyp des SchlüsselmaterialsAnwendung in welchem Sicherheitsverfahrenggf. Zuordnung zu einer PKIMaximale Gültigkeitsdauer/typische GültigkeitsdauerSchlüsselerzeugungIst ein Backup bei der Schlüsselerzeugungvorgesehen ?SchlüsselregistrierungErzeugung eines Schlüssel-ZertifikatsSchlüsselverteilungSchlüsselinstallationSchlüsselspeicherungIst ein Backup bei Schlüsselspeicherungvorgesehen ?SchlüsselableitungSchlüsselarchivierungFestgelegter Verwendungszweckdes SchlüsselsWer hat die Zugriffsrechte ?Wie wird der Zugriff geschützt?Aufheben der Registrierung einesSchlüssels/SchlüsselzertifikatsWie wird der Schlüssel (wennzulässig) nur suspendiert?VerantwortlicherEinsatzumgebunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 652 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Erfassungsbogen von SchlüsselmaterialWie wird der Schlüssel (wennzulässig) wieder aktiviert?Wie wird der Schlüssel endgültiggelöscht/gesperrt?Wie wird eine Kompromittierungdes Schlüssels erfasst?Maßnahmen bei Kompromittierungdes Schlüsselsverantwortlich während des BetriebsRelevante SpezifikationÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortlicherEinsatzumgebungggf ähnliches SchlüsselmaterialZusätzliche Quellen-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 653 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturUmsetzung des Schutzbedarfs in den verschiedenen Einsatzumgebungen des Schlüsselswird erfasst im dem Bogen:Name des SchlüsselmaterialsVorkommen des SchlüsselsDabei bitte alle Stationen imLebenszyklus erfassenEinsatzumgebungSchutzbedarfVertraulichkeitIntegritätVerfügbarkeitAuthentizitätNichtabstreitbarkeitUmsetzung des SchutzbedarfsDie abgestimmte Liste des Schlüsselmaterials die in einem gesonderten Dokument vorliegt,hat folgende Gliederung:.Themenkreis (zust. AG)KomponenteNameBeschreibungTypPKI-L/ EbeneKrypto-VerfahrenLebenszyklusBegründungAuswahlmöglichkeiten: Architektur, Datenschutz undSicherheit´, Karten, PKI, dezentrale Komponenten, Infrastruktur,BetriebNach der Liste der KomponentenName des SchlüsselmaterialsVerbale Beschreibung nicht mehr als 10 ZeilenZ.B Schüssel, Zertifikat, PIN, Zufallwert usw.Wenn in eine PKI eingeordnet, dann dies. SchlüsselebeneZugrunde liegenden Krypto-VerfahrenReferenz auf Lebenszyklusbeschreibung in Fragebogenbzw. Referenz auf exemplarischen LebenszyklusBeschreibung bzw. Herleitung weiterer EigenschaftenDie exemplarisch ausgefüllten Fragebögen zu den Lebenszyklen stehen in F6.3.3.1ff.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 654 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang G –Sicherheitsanforderungen BetriebDie Infrastrukturdienste werden potenziell nicht von der gematik, sondern von vertraglichbeauftragten Dienstleistern betrieben. In sofern ist es notwendig, auch die zu treffenden Sicherheitsmaßnahmenvertraglich fest zu legen. Bei der Verarbeitung von personenbezogenenDaten sind ggf. die Regelungen des § 11 BDSG zu beachten.Dieses Kapitel beschreibt Sicherheitsmaßnahmen, und es ist jeweils gekennzeichnet, ob derDienstbetreiber sie umsetzen SOLL oder MUSS. Dazu werden im Einzelfall weitere, aus demSchutzbedarf und den Bedrohungen des spezifischen Dienstes abgeleitete Maßnahmenfestgelegt. In sofern beschreibt dieses Dokument Mindestanforderungen zum Betrieb derInfrastruktur, die durch die anderen, in der Leistungsbeschreibung referenzierten Dokumente,um weitere Anforderungen erweitert werden.Die Sicherheitsmaßnahmen sind den entsprechenden Kapiteln aus ISO/IEC 27002:2005zugeordnet. Dieses Dokument beschreibt die Anforderungen der gematik an die Umsetzungeinzelner Punkte dieses Standards durch den Betreiber genauer und detaillierter. Davonunabhängig bleibt die Forderung weiter bestehen, dass der Dienstanbieter seine Betriebsführunggenerell an den Anforderungen des ISO/IEC 27002:2005 [ISO27002] ausrichtet. Diesbedeutet, dass er dokumentiert hat, wie die Anforderungen des ISO/IEC 27002:2005 durchseine Betriebsführung erfüllt werden. Die weitergehenden Anforderungen an die Umsetzungvon ISO 27001 [ISO27001] bleiben unberührt.In diesem Kapitel wurde bereits berücksichtigt, dass der Dienstbetreiber möglicherweiseVerantwortungen an einen anderen Auftragnehmer delegiert. Deswegen sind die konkretenVerantwortlichkeiten so weit aufgeschlüsselt, dass eine Zuweisung bestimmter Verantwortungenan einen Dritten durch Zuteilen der Art der Verantwortung (P = Performt, A =Assistiert) leicht möglich ist. Die Tatsache, dass der Vertragspartner der gematik auch für dieUmsetzung der Maßnahmen durch Unterauftragnehmer verantwortlich ist, bleibt davon unberührt.Konzepte zur Implementierung und zum Betrieb des Dienstes werden vom Betreiber erstellt.Diese Dokumente werden hier „Architekturkonzept“ und „Betriebskonzept“ genannt. DieseDokumente werden unter dem Begriff „Implementierungskonzept“ subsumiert.G1 - Personelle AnforderungenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 8.1.1 - 8.1.3 Human resources security.Die geeignete Auswahl, Einweisung und Schulung des Personals und die Schaffung geeigneterorganisatorischer Rahmenbedingungen hat einen sehr großen Einfluss auf die Sicherheitdes Betriebes. Es muss sichergestellt werden und überprüfbar sein, dass die Mitarbeiterüber die vorzugebenden Kenntnisse verfügen.Um eine ausreichende Regelung besonders sicherheitsrelevanter Aspekte zu belegenMUSS der Dienstbetreiber die Dokumentation folgender Punkte nachweisen. Die Dokumentationmuss inhaltlich nicht vorgelegt werden, wenn sie vertraulich ist:• Nachweis über die Ausbildung und Schulungen der Mitarbeitergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 655 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Vorgesehene Disziplinarmaßnahmen bei Sicherheitsverstößen• Anforderungen der Sicherheitsüberprüfungen von Mitarbeitern (Screening)• Funktionsbeschreibungen mit Aufgaben und Verantwortlichkeiten der einzelnenRollen• Verpflichtungserklärung der Mitarbeiter zur Nichtweitergabe von vertraulichen Informationen(Verpflichtung auf das Datenschutzgeheimnis nach § 5 BDSG beiVerarbeitung von personenbezogenen Daten immer erforderlich).• Festlegungen für das Personal über den Umgang mit Sicherheitsvorfällen undfestgestellten Abweichungen von definierten Sicherheitsmaßnahmen in einemSicherheitshandbuchgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 656 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG1.1 Zusammenfassung der AusgangsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_03239 SPersonelle_Anforderungen:Anforderungen andas PersonalmanagementeinesDienstbetreibers.Um eine ausreichende Regelung besonders sicherheitsrelevanterAspekte zu belegen MUSS der Dienstbetreiber die Dokumentationfolgender Punkte nachweisen. Die Dokumentation muss inhaltlichnicht vorgelegt werden, wenn sie vertraulich ist:• Nachweis über die Ausbildung und Schulungen der Mitarbeiter• Vorgesehene Disziplinarmaßnahmen bei Sicherheitsverstößen• Anforderungen der Sicherheitsüberprüfungen von Mitarbeitern(Screening)• Funktionsbeschreibungen mit Aufgaben und Verantwortlichkeitender einzelnen Rollen• Verpflichtungserklärung der Mitarbeiter zur Nichtweitergabe vonvertraulichen Informationen (Verpflichtung auf das Datenschutzgeheimnisnach § 5 BDSG bei Verarbeitung von personenbezogenenDaten immer erforderlich).• Festlegungen für das Personal über den Umgang mit Sicherheitsvorfällenund festgestellten Abweichungen von definierten Sicherheitsmaßnahmenin einem SicherheitshandbuchAnhang G 1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 657 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG2 - Physische SicherheitsmaßnahmenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 9.1.2 Physical entry controls (Physische Zutrittskontrollen).G2.1 - Physische Sicherheitsmaßnahmen in Bereichen, die der Kontrolle vonDienstbetreibern unterstehenDiebstahl oder Beschädigung der Systeme für die Informationsverarbeitung, nicht autorisierteWeitergabe oder Löschung von Informationen sowie die Unterbrechung der Unterstützungfür Geschäftsprozesse gehören zu den Risiken, die die Leiter oder Verantwortlichenfür die Informationsverarbeitung in einem Unternehmen berücksichtigen müssen. Dadurch den physischen Zugang zu diesen Assets für die Informationsverarbeitung alle dieseRisiken bestehen, MUSS das zuständige Management physische Zugangskontrolleneinrichten, um diese Risiken und potenzielle Datenverluste zu vermeiden.In diesem Abschnitt werden die Maßnahmen zum Schutz der Datenzentren aufgeführt,die vom Dienstbetreiber überwacht werden. Weiterhin werden der Zugang zu den vomDienstbetreiber überwachten Datenzentren, die Sicherheit von Druckern sowie die Kontrolleder internen Netzwerk-Infrastruktur des Dienstbetreibers beschrieben.(Entsprechende gesetzliche Regelung in Ziffer 1 Anlage zu § 9 BDSG, als datenschutzrechtlicheVerpflichtung, wenn personenbezogene Daten verarbeitet werden).G2.1.1 - Zugang zum DatenzentrumEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 9.1.2 Physical entry controls (Physische Zutrittskontrollen).Der Zugang zu den vom Dienstbetreiber betriebenen Datenzentren darf ausschließlichMitarbeitern des Dienstbetreibers, deren primärer Arbeitsbereich innerhalb des Datenzentrumsliegt, sowie externen Mitarbeiten gewährt werden, die aus eindeutig unternehmensrelevantenGründen Zugang zu diesen Bereichen erhalten müssen. Über alle Anträgefür eine dauerhafte Zugangsberechtigung zum Datenzentrum MUSS von dem für dasDatenzentrum verantwortlichen Manager des Dienstbetreibers oder seinem Stellvertreterentschieden werden.Bei Datenverarbeitung im Auftrag ist die Vergabe an Unterauftragnehmer mit dem Auftraggeberabzustimmen, der Zugang explizit zu regeln.Zugang zum DatenzentrumMindestanforderungVerantwortungen (P = Performt, A = Assistiert)Beschränken des Zugangs zu allen Datenverarbeitungsbereichen,für die der Dienstbetreiber die Sicher-DienstbetreiberPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 659 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturheitsverantwortung übernimmt, auf autorisierte MitarbeiterG2.1.2 - Kontrollierte BereicheEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 9.1.1 Physical security perimeter (Physischer Sicherheitsgrenze)und Ziffer 9.1.5 Working in secure areas (Arbeiten in Sicherheitszonen).Zur Erzielung eines hohen Sicherheitsniveaus 60 MÜSSEN verschiedene Kontrollstufenimplementiert werden. Hierdurch lässt sich die Effizienz der physischen Sicherheitsmaßnahmenfür die vom Dienstbetreiber verwalteten Systeme optimieren und der unbefugteZugriff, die Beschädigung der Systeme bzw. die Unterbrechung von Services verhindern.Kontrollierte Bereiche werden zur Unterbringung von großen, mittleren oder verteiltenComputersystemen 61 sowie zur Lagerung von Wechselmedien verwendet. Die benötigteStufe der physischen Sicherheit und der Zugangskontrolle hängt von der Bedeutung desbereitgestellten Systemservices sowie vom Wert der für die Informationsverarbeitung eingesetztenHardware ab. Bei Sicherheitsbereichen handelt es sich um die Bereiche mitdem höchsten Sicherheitsniveau, während der nächst niedrigere Bereich als „geschützt“bezeichnet wird. In den folgenden Abschnitten werden die physischen sowie organisatorischenKontrollen für die kontrollierten Bereiche in Einrichtungen des Dienstbetreibers beschrieben.Physische Voraussetzungen für kontrollierte BereicheIn diesem Abschnitt werden die physischen Voraussetzungen für kontrollierte Bereicheinnerhalb von Datenzentren des Dienstbetreibers definiert.Physische VoraussetzungenKontrollierte BereicheGeschützterBereichSicherheitsbereichDer Zugang DARF NICHT über allgemein zugängliche Gebäudebereicheerfolgen.Der Bereichsverantwortliche MUSS klar definiert sein. Ja JaDer Bereich MUSS auch dann verschlossen sein, wenn erüberwacht wird.JaJaJaJa60 Die Forderung nach einem hohen Sicherheitsniveau leitet sich aus dem hohen bis sehr hohenSchutzbedarf der verarbeiteten Datenobjekte ab. Dabei ist zu beachten, dass auch der Schutzbedarfnicht unmittelbar mit dem Dienst des Dienstanbieters verarbeiteter Datenobjekte die Sicherheitsanforderungenbeeinflussen kann, z. B. wenn die Verfügbarkeit eines Datenobjektes mit hohemSchutzbedarf bzgl. der Verfügbarkeit von der Verfügbarkeit des Dienstes (z. B.) DNS abhängt.Die Dokumentation des Sicherheitsniveaus des Dienstes ist im Sicherheitskonzept des Dienstanbieterszu finden.61 d. h. Computersysteme, die beispielsweise nicht in Schränken gekapselt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 660 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPhysische VoraussetzungenKontrollierte BereicheNotausgänge MÜSSEN mit funktionsbereiten, überprüfbarenund überwachten Alarmeinrichtungen ausgestattet sein.Zur Gewährleistung der Sicherheit MÜSSEN diese Alarmeinrichtungenüber eine Notstromversorgung verfügen. ImAlarmfall MÜSSEN geeignete Maßnahmen zur Untersuchungdes Vorfalls immer eingeleitet werden. Die Alarmeinrichtungender Notausgänge MÜSSEN in periodischenZeitabständen auf ihre Funktionsfähigkeit überprüft und dieentsprechenden Ergebnisse MÜSSEN dokumentiert werden.Für Außenfenster für Erdgeschossinstallationen MUSS einesplittersichere Verglasung verwendet werden.Der Bereich DARF von außen NICHT einsehbar sein (blindeFenster)Der Bereich MUSS mit mechanischen Barrieren (Fenstergitteretc.) UND Einbruchmeldern ausgestattet sein.Die Zugangstüren MÜSSEN elektronisch gesichert sein,wenn durch den Vorgesetzten des Bereichsverantwortlichenoder ein gleichgestelltes Mitglied der Unternehmensleitungkeine anders lautenden, expliziten Anweisungendefiniert wurden.NeinNeinNeinJaNeinJaJaJaJaJaVerwaltung kontrollierter BereicheDie Bereichsverantwortlichen sind für die Aufrechterhaltung effektiver unternehmensinternerKontrollmaßnahmen für den entsprechenden Bereich verantwortlich. Die Kontrollekann auf eine Vielzahl verschiedener Arten gewährleistet werden. Als Beispiele für dieMaßnahmen und Einrichtungen zur physischen Zugangskontrolle können Schlüssel, Codeschlösserund elektronische Einrichtungen zur Zugangskontrolle sowie die Bewachungder Zugänge durch entsprechendes Personal aufgeführt werden. In diesem Abschnittwerden die geforderten verwaltungstechnischen Sicherheitsmaßnahmen in den Datenzentrendes Dienstbetreibers beschrieben.ZugangsanforderungenKontrollierte BereicheGeschützterBereichSicherheitsbereichDer Zugang MUSS kontrolliert werden, um den Zutrittnicht autorisierter Personen zum Bereich zu verhindern.Die in der genehmigten Zugangsberechtigungsliste aufgeführtenPersonen MÜSSEN autorisiert sein.Personen, denen von einem autorisierten Mitarbeiter einetemporäre Zugangsberechtigung erteilt wurde, verfügenüber eine einmalige Autorisierung für den Zutritt zumbetreffenden Bereich.JaJaJaJagematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 661 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZugangsanforderungenKontrollierte BereichePersonen, die für den Zugang zu einem zutrittskontrolliertenBereich berechtigt sind, MÜSSEN einen gültigengeschäftlichen Grund für ihren Zutritt vorweisen könnenund vom Bereichsverantwortlichen autorisiert wordensein. Der Bereichsverantwortliche ist dafür zuständig,festzustellen, welche Gründe als geschäftlich einzustufensind, und diese Feststellung auch zu belegen.Die Zugangsberechtigungsliste MUSS vom Bereichsverantwortlichenauf nicht autorisierte Änderungen hinüberprüft werden.Die weitere Gültigkeit des geschäftlichen Grunds der inder Zugangsberechtigungsliste aufgeführten PersonenMUSS vom Bereichsverantwortlichen geprüft werden.Prozess zum zeitgerechten Widerrufen der Zugangsberechtigungauf Anforderung oder implizit durch Ausscheidender betreffenden Person aus dem UnternehmenMUSS implementiert sein.Datum und Uhrzeit von Zutritt und Verlassen eines Bereichesdurch eine Person MÜSSEN aufgezeichnet werden.Die Nachvollziehbarkeit aller Zutrittsvorgänge MUSS gepflegtwerden.JaNeinNeinJaNeinJahalbjährlichJährlichJaJaG2.1.3 - Standort von Systemen und KomponentenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 9.2.1 Equipment siting and protection (Positionierung undSchutz der Geräte).Die Anforderungen für die physische Zugangskontrolle gelten für die CPU, die über Kanäleangeschlossenen Einheiten sowie Konsolen des physischen Systems/Servers unddie Hauptkonsolen (d. h., interaktive Einheiten, die eine Befehlsschnittstelle zum Betriebssystembereitstellen, ohne dass der Bediener identifiziert und authentifiziert wird). Die Artdes verwendeten kontrollierten Bereiches hängt von der Bedeutung des bereitgestelltenSystemservices für die Sicherstellung der festgelegten Qualität der Dienste (siehe SLAs)und insbesondere vom Schutzbedarf der jeweiligen Komponente ab. Insofern beschreibtdie nachfolgende Tabelle nur Mindestanforderungen.Die verwendeten LANs MÜSSEN so konzipiert sein, dass sie nicht zum Ziel nicht autorisierterZugriffs- und Manipulationsversuche (z. B. durch Angriffe von Sniffern) werdenkönnen. Als Beispiel zur Realisierung dieses Ziels KANN ein hierarchisches Entwurfskonzeptherangezogen werden.Standort von Datenverarbeitungseinrichtungen /Komponenten der LAN-InfrastrukturMindestanforderung fürden Bereichgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 662 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturStandort von Datenverarbeitungseinrichtungen /Komponenten der LAN-InfrastrukturSysteme mit zentraler Bedeutung für die Ausführung wichtigerGeschäftsprozesse 62 oder Systeme mit sehr hohemSchutzbedarfSysteme die Komponenten mit hohem oder sehr hohemSchutzbedarf enthalten 63 oder Systeme mit hohemSchutzbedarfKleinere Unternehmenssysteme oder Systeme mit mittleremSchutzbedarfSonstige Systeme mit niedrigem SchutzbedarfTemporäre Konfigurationen/Komponenten, die zu einemDemo- oder Testsystem gehören und keine produktiven /klassifizierten Assets umfassenAlle Einheiten für die Kontrolle der Netzwerkkommunikation(unabhängig vom unterstützten Systemservice)LAN-ManagementsystemeBridges, Gateways, Repeater, Router, Wiring Hubs, WiringClosetsDrahtlose Netzwerkzugänge(WLAN-Technologie DARF in den Sicherheitszonen 2 bis7 des Zonenkonzeptes NICHT eingesetzt werden, siehe[gemNWSich])ModemsAktive Ports in hierarchischen LANs auf LAN-Segmenten,die nicht von Benutzern verwendet werden (z. B. Backbones)Aktive Ports (unabhängig davon, ob ein System oder eineEinheit angeschlossen ist) in LAN-Benutzersegmenten.Hinweis: Aktive Ports sind in allgemein zugänglichen Gebäudebereichennur dann zulässig, wenn diese überwachtMindestanforderung fürden BereichSicherheitsbereichSicherheitsbereichGeschützter BereichRaum verschlossen, wennunbeaufsichtigtRaum verschlossen, wennunbeaufsichtigtGeschützter BereichRaum verschlossen, wennunbeaufsichtigtGeschützter BereichMontiert im DeckenbereichoderMontiert in einer Mindesthöhevon 2,5 m über demBoden oderGeschützter Bereich oderIn einem abgesperrten BürooderPhysisch gesichert, um Diebstahloder Manipulationsversuchezu verhindernGleicher Status wie die Systeme/Komponenten,an diediese Einheiten angeschlossensindGeschützter BereichNicht allgemein zugänglicheGebäudebereiche62 Diese Systeme sind im Architekturkonzept auszuweisen.63Soweit im Sicherheitskonzept des Dienstanbieters keine anderen Anforderungen definiert sind.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 663 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturStandort von Datenverarbeitungseinrichtungen /Komponenten der LAN-Infrastrukturwerden.Sniffer-EinheitenMindestanforderung fürden BereichNur autorisierten Personenmit einem gültigen geschäftlichenGrund gestattetLAN-Server/InfrastruktureinheitenGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Begrenzen des Zugangs zu LAN-Servern und Infrastruktureinheiten inden Einrichtungen des DienstbetreibersDienstbetreiberPOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Begrenzen des Zugangs zu LAN-Servern und Infrastruktureinheiten inden Einrichtungen des spezifischen DienstesPG2.2 - DruckerEntsprechende Anforderungen gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.7.3 Information handling procedures (Verfahren zum Umgangmit Informationen).Ausdrucke MÜSSEN zu jeder Zeit geschützt werden, solange sie sich unter der Kontrolledes Dienstbetreibers befinden. In folgenden Situationen MÜSSEN Ausdrucke gegen unbefugtenZugriff geschützt werden:• Ausdrucken von Daten auf einem Drucker• Zusammenstellen, Vorbereiten und Aufbewahren von Ausdrucken für Auslieferungund Versand• Auslieferung und Versand, solange sich die Ausdrucke unter der Kontrolle vonDienstbetreibern befinden• Kontrollierte Vernichtung von nicht benötigten bzw. beschädigten AusdruckenDruckerGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Festlegung und Implementieren von Maßnahmen zum Schutz der vomDienstbetreiber kontrollierten Druckausgaben gegen unbefugten ZugriffDienstbetreiberPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 664 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDruckerentsprechend dem Schutzbedarf der auszudruckenden Datengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 665 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG2.3 – Zusammenfassung der SicherheitsanforderungenAfo-ID Anfo ArtA_03240A_03241A_03242A_03243A_03244A_03245SSSSSSTitel Beschreibung Rel. QuelleZugang_zum_Datenzentrum:Zugangsbeschränkungen zuDatenverarbeitungsbereichen.Kontrollierte_Bereiche_01:Implementierung verschiedenerKontrollstufen.Kontrollierte_Bereiche_02:Kein Zugang über allgemeinzugängliche Gebäudebereiche.Kontrollierte_Bereiche_03:Benennung eines Bereichsverantwortlichen.Kontrollierte_Bereiche_04:Verschluß überwachter Bereiche.Kontrollierte_Bereiche_05:Alarmeinrichtungen an Notausgängen.Beschränken des Zugangs zu allen Datenverarbeitungsbereichen,für die der Dienstbetreiber die Sicherheitsverantwortung übernimmt,auf autorisierte MitarbeiterZur Erzielung eines hohen Sicherheitsniveaus MÜSSEN verschiedeneKontrollstufen implementiert werdenDer Zugang DARF NICHT über allgemein zugängliche Gebäudebereicheerfolgen.Geschützter Bereich:JSicherheitsbereich:JDer Bereichsverantwortliche MUSS klar definiert sein.Geschützter Bereich:JSicherheitsbereich:JDer Bereich MUSS auch dann verschlossen sein, wenn er überwachtwird.Geschützter Bereich:JSicherheitsbereich:JNotausgänge MÜSSEN mit funktionsbereiten, überprüfbaren undüberwachten Alarmeinrichtungen ausgestattet sein. Zur Gewährleistungder Sicherheit MÜSSEN diese Alarmeinrichtungen übereine Notstromversorgung verfügen. Im Alarmfall MÜSSEN geeigneteMaßnahmen zur Untersuchung des Vorfalls immer eingeleitetAnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 666 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03246A_03247A_03248A_03249A_03250SSSSSTitel Beschreibung Rel. QuelleKontrollierte_Bereiche_06:Sicherung von Erdgeschossinstallationen.Kontrollierte_Bereiche_07:Einsehbarkeit des Bereichesvon außen.Kontrollierte_Bereiche_08:Mechanischer Zutrittsschutzund Einbruchmelder.Kontrollierte_Bereiche_09:Elektronsiche Sicherung derZugangstüren.Kontrollierte_Bereiche_10:Zugangskontrollewerden. Die Alarmeinrichtungen der Notausgänge MÜSSEN inperiodischen Zeitabständen auf ihre Funktionsfähigkeit überprüftund die entsprechenden Ergebnisse MÜSSEN dokumentiert werden.Geschützter Bereich:NSicherheitsbereich:JFür Außenfenster für Erdgeschossinstallationen MUSS eine splittersichereVerglasung verwendet werden.Geschützter Bereich:NSicherheitsbereich:JDer Bereich DARF von außen NICHT einsehbar sein (blinde Fenster)Geschützter Bereich:NSicherheitsbereich:JDer Bereich MUSS mit mechanischen Barrieren (Fenstergitter etc.)UND Einbruchmeldern ausgestattet sein.Geschützter Bereich:JSicherheitsbereich:JDie Zugangstüren MÜSSEN elektronisch gesichert sein, wenndurch den Vorgesetzten des Bereichsverantwortlichen oder eingleichgestelltes Mitglied der Unternehmensleitung keine anderslautenden, expliziten Anweisungen definiert wurden.Geschützter Bereich:NSicherheitsbereich:JDer Zugang MUSS kontrolliert werden, um den Zutritt nicht autorisierterPersonen zum Bereich zu verhindern. Die in der genehmigtenZugangsberechtigungsliste aufgeführten Personen MÜSSENautorisiert sein.Geschützter Bereich:JAnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 667 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleSicherheitsbereich:JA_03251A_03252A_03253A_03254A_03255SSSSSKontrollierte_Bereiche_11:Temporäre Zugangsberechtigung.Kontrollierte_Bereiche_12:Zutrittsgenehmigung und -begründung.Kontrollierte_Bereiche_13:Prüfung der Zugangsberechtigungsliste.Kontrollierte_Bereiche_14:Prüfung der Zutrittsbegründung.Kontrollierte_Bereiche_15:Prozess zum zeitgerechtenWiderrufen der Zugangsberechtigung.Personen, denen von einem autorisierten Mitarbeiter eine temporäreZugangsberechtigung erteilt wurde, DÜFEN NUR über eineeinmalige Autorisierung für den Zutritt zum betreffenden Bereichverfügen.Geschützter Bereich:JSicherheitsbereich:JPersonen, die für den Zugang zu einem zutrittskontrollierten Bereichberechtigt sind, MÜSSEN einen gültigen geschäftlichenGrund für ihren Zutritt vorweisen können und vom Bereichsverantwortlichenautorisiert worden sein. Der Bereichsverantwortliche istdafür zuständig, festzustellen, welche Gründe als geschäftlich einzustufensind, und diese Feststellung auch zu belegen.Geschützter Bereich:JSicherheitsbereich:JDie Zugangsberechtigungsliste MUSS vom Bereichsverantwortlichenauf nicht autorisierte Änderungen hin überprüft werden.Geschützter Bereich:NSicherheitsbereich:J, halbjährlichDie weitere Gültigkeit des geschäftlichen Grunds der in der Zugangsberechtigungslisteaufgeführten Personen MUSS vom Bereichsverantwortlichengeprüft werden.Geschützter Bereich:NSicherheitsbereich:J, jährlichProzess zum zeitgerechten Widerrufen der Zugangsberechtigungauf Anforderung oder implizit durch Ausscheiden der betreffendenPerson aus dem Unternehmen MUSS implementiert sein.Geschützter Bereich:JAnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 668 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleSicherheitsbereich:JA_03256SKontrollierte_Bereiche_16:Protokollierung der Zutritte.A_03257 S Standort_von_Systemen_und_Komponenten_01: Zugriffs- undmanipulationsgeschützter Aufstellungsort.A_03258 S Standort_von_Systemen_und_Komponenten_02: Systeme mitzentraler Bedeutung für dieAusführung wichtiger GeschäftsprozesseA_03259 SStandort_von_Systemen_und_Komponenten_03: Komponentenmit hohem oder sehr hohemSchutzbedarfA_03260 S Standort_von_Systemen_und_Komponenten_04: Kleinere Unternehmenssystemeoder Systememit mittlerem SchutzbedarfDatum und Uhrzeit von Zutritt und Verlassen eines Bereichesdurch eine Person MÜSSEN aufgezeichnet werden. Die Nachvollziehbarkeitaller Zutrittsvorgänge MUSS gepflegt werden.Geschützter Bereich:NSicherheitsbereich:JDie verwendeten LANs MÜSSEN so konzipiert sein, dass sie nichtzum Ziel nicht autorisierter Zugriffs- und Manipulationsversuche (z.B. durch Angriffe von Sniffern) werden können. Als Beispiel zurRealisierung dieses Ziels KANN ein hierarchisches Entwurfskonzeptherangezogen werdenSysteme mit zentraler Bedeutung für die Ausführung wichtiger Geschäftsprozesse[Diese Systeme sind im Architekturkonzept auszuweisen]oder Systeme mit sehr hohem SchutzbedarfMUSS-Standortvorgabe: SicherheitsbereichSysteme die Komponenten mit hohem oder sehr hohem Schutzbedarfenthalten [Soweit im Sicherheitskonzept des Dienstanbieterskeine anderen Anforderungen definiert sind.] oder Systememit hohem SchutzbedarfMUSS-Standortvorgabe: SicherheitsbereichKleinere Unternehmenssysteme oder Systeme mit mittleremSchutzbedarfMUSS-Standortvorgabe: Geschützter BereichAnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 669 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03261 S Standort_von_Systemen_und_Komponenten_05:Sonstige Systememit niedrigem SchutzbedarfA_03262 S Standort_von_Systemen_und_Komponenten_06: Temporäre Konfigurationenoder Komponenten,die zu einem Demo- oderTestsystem gehören.A_03263 S Standort_von_Systemen_und_Komponenten_07: Einheiten fürdie Kontrolle der NetzwerkkommunikationA_03264SStandort_von_Systemen_und_Komponenten_08: LAN-ManagementsystemeA_03265 S Standort_von_Systemen_und_Komponenten_09: Bridges, Gateways,Repeater, Router, WiringHubs, Wiring ClosetsA_03266SStandort_von_Systemen_und_Komponenten_10: DrahtloseNetzwerkzugängeSonstige Systeme mit niedrigem SchutzbedarfMUSS-Standortvorgabe: Raum verschlossen, wenn unbeaufsichtigtTemporäre Konfigurationen/Komponenten, die zu einem DemooderTestsystem gehören und keine produktiven / klassifiziertenAssets umfassenStandortvorgabe: Raum verschlossen, wenn unbeaufsichtigtAlle Einheiten für die Kontrolle der Netzwerkkommunikation (unabhängigvom unterstützten Systemservice)MUSS-Standortvorgabe: Geschützter BereichLAN-ManagementsystemeMUSS-Standortvorgabe: Raum verschlossen, wenn unbeaufsichtigtBridges, Gateways, Repeater, Router, Wiring Hubs, Wiring ClosetsMUSS-Standortvorgabe: Geschützter BereichDrahtlose Netzwerkzugänge(WLAN-Technologie DARF in den Sicherheitszonen 2 bis 7 desZonenkonzeptes NICHT eingesetzt werden, siehe [gemNWSich])MUSS-Standortvorgabe: Montiert im Deckenbereich oderAnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 670 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo ArtA_03267STitel Beschreibung Rel. QuelleÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturStandort_von_Systemen_und_Komponenten_11: ModemsA_03268 S Standort_von_Systemen_und_Komponenten_12: Aktive Ports inhierarchischen LANs auf LAN-Segmenten.A_03269 SA_03270SStandort_von_Systemen_und_Komponenten_13: Aktive Ports inLAN-BenutzersegmentenMUSS-Standortvorgabe: Nicht allgemein zugängliche GebäudebereicheStandort_von_Systemen_und_Komponenten_14: Sniffer-EinheitenA_03271 S Zugang_zu Systemen_und_Komponenten_01:Begrenzen des Zugangs/EinrichtungendesDienstbetreibersMontiert in einer Mindesthöhe von 2,5 m über dem Boden oderGeschützter Bereich oderIn einem abgesperrten Büro oderPhysisch gesichert, um Diebstahl oder Manipulationsversuche zuverhindernModemsMUSS-Standortvorgabe: Gleicher Status wie die Systeme/Komponenten,an die diese Einheiten angeschlossen sindAktive Ports in hierarchischen LANs auf LAN-Segmenten, die nichtvon Benutzern verwendet werden (z. B. Backbones)MUSS-Standortvorgabe: Geschützter BereichAktive Ports (unabhängig davon, ob ein System oder eine Einheitangeschlossen ist) in LAN-Benutzersegmenten. Hinweis: AktivePorts sind in allgemein zugänglichen Gebäudebereichen nur dannzulässig, wenn diese überwacht werden.Sniffer-EinheitenMUSS-Standortvorgabe: Nur autorisierten Personen mit einemgültigen geschäftlichen Grund gestattetGrundlegender Aufgabenbereich(Dienstbetreiber performt):Begrenzen des Zugangs zu LAN-Servern und Infrastruktureinheitenin den Einrichtungen des DienstbetreibersAnhangG 2AnhangG 2AnhangG 2AnhangG 2AnhangG 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 671 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03272 S Zugang_zu Systemen_und_Komponenten_02:Begrenzen des Zugangs/Einrichtungendes spezifischenDienstesA_03273SA_03274SDrucker_01: Ausdrucke MÜS-SEN geschützt werden.Drucker_02: Maßnahmen zumSchutz der Druckausgaben.Optionaler Aufgabenbereich(Dienstbetreiber performt):Begrenzen des Zugangs zu LAN-Servern und Infrastruktureinheitenin den Einrichtungen des spezifischen DienstesAusdrucke MÜSSEN zu jeder Zeit geschützt werden, solange siesich unter der Kontrolle des Dienstbetreibers befinden. In folgendenSituationen MÜSSEN Ausdrucke gegen unbefugten Zugriffgeschützt werden:• Ausdrucken von Daten auf einem Drucker• Zusammenstellen, Vorbereiten und Aufbewahren von Ausdruckenfür Auslieferung und Versand• Auslieferung und Versand, solange sich die Ausdrucke unter derKontrolle von Dienstbetreibern befinden• Kontrollierte Vernichtung von nicht benötigten bzw. beschädigtenAusdruckenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Festlegung und Implementieren von Maßnahmen zum Schutz dervom Dienstbetreiber kontrollierten Druckausgaben gegen unbefugtenZugriff entsprechend dem Schutzbedarf der auszudruckendenDatenAnhangG 2AnhangG 2AnhangG 2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 672 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3 - Logische ZugriffskontrollenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.1.1 Access control policy (Zugangskontrollpolicy).Dieses Kapitel behandelt verschiedene Aspekte der logischen Zugriffskontrolle. Mit derlogischen Zugriffskontrolle wird der Zugriff auf Host- oder LAN-Systeme, Daten und Systemparameterkontrolliert.Die logischen Zugriffskontrollen umfassen die folgenden Hauptbereiche. Die entsprechendenAnforderungen werden in diesem Dokument erläutert.• Identifizieren und Authentifizieren von Benutzern 64 : Sicherstellen, dass jedempotenziellen Benutzer des Systems eine eindeutige Kennung (z. B. eineBenutzer-ID) zugeordnet werden kann. Wenn sich der Benutzer am Systemanmeldet, MUSS durch eine weitere Identifikationsstufe (z. B. ein Kennwort)sichergestellt werden, dass der Benutzer die Person ist, für die er sich ausgibt.• Definieren und Schützen von Assets: Sicherstellen, dass jede Ressourceauf dem System identifiziert werden kann, und dass der Zugriff auf diese Assetsim definierten Umfang nur autorisierten Benutzern gewährt und nicht autorisiertenBenutzern verweigert werden kann.• System- und Sicherheitsadministratoren: Sicherstellen, dass die Sicherheitsfunktionendes Systems nur von autorisierten Benutzern definiert, geändertoder deaktiviert werden können.• Protokollieren von Zugriffsversuchen: Sicherstellen, dass für jeden erfolgreichenoder fehlgeschlagenen Zugriffsversuch auf das System oder auf geschützteAssets innerhalb des Systems ein Protokolleintrag erstellt wird.• Melden von Zugriffsverletzungen: Sicherstellen, dass nicht autorisierteZugriffsversuche auf Systeme oder Informationen durch sofortige oder spätereAnalysen als Zugriffsverletzungen erkannt werden.G3.1 - Identifizieren und Authentifizieren von BenutzernG3.1.1 - Benutzer-IDsEntsprechende Anforderungen gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.2.1 User registration (Anmeldung von Benutzern) und Ziffer11.5.2 User identification and authentication (Benutzeridentifikation und -authentisierung).Die Zugriffsberechtigungen für die Systeme MÜSSEN auf der Basis der aktuellen geschäftlichenNotwendigkeiten vergeben und durch die Überprüfung der Identität von Benutzernund Anwendungen kontrolliert werden. Benutzer-IDs MÜSSEN einer bestimmten64 Benutzer sind interne und externe Mitarbeiter, die Zugriff zu einem System haben müssen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 673 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPerson eindeutig zugeordnet werden können. Dazu MUSS jedem Benutzer eine eindeutigeBenutzer-ID und ein geheimer Code (z. B. ein Kennwort) zugewiesen werden, die nurdem Eigner der Benutzer-ID bekannt sind. Die hier beschriebenen Benutzer-IDs sind dieIDs für die Anmeldung am System bzw. Server.Wenn im Sicherheitskonzept eine SmartCard oder andere, stärkere Credentials zur Authentifizierungvon Benutzern gefordert wird, hat diese Forderung Vorrang vor den imWeiteren gemachten Vorgaben.Verwendung einer Benutzer-ID durch eine Gruppe:• Die Verwendung einer Benutzer-ID durch eine Gruppe stellt grundsätzlich einRisiko da. Die Notwendigkeit MUSS jeweils im Sicherheitskonzept begründetwerden und es MUSS dargelegt werden, wieso die Sicherheit des Systemsdadurch nicht unzulässig reduziert wird.Unter folgenden Bedingungen DÜRFEN Benutzer-IDs bzw. Kennwörter von einer Gruppegemeinsam verwendet werden:• Die Software lässt die Verwaltung persönlicher Zugriffsaccounts nicht zu undspezielle Benutzer-IDs oder Kennwörter sind für den Zugriff auf Funktionen,die von einer bestimmten Personengruppe bzw. Rolle benötigt werden, unbedingterforderlich.• Die nicht autorisierte Verwendung der Benutzer-ID oder des Kennworts MUSSverhindert werden.• Der Zugriff MUSS nur auf die Funktionen eingeschränkt werden, die für dieGruppe genehmigt sind.• Alle Mitglieder der Gruppe MÜSSEN für die Daten zugriffsberechtigt sein, fürdie die Benutzer-ID zugriffsberechtigt ist.• Die Zuordnung MUSS sich aus manuell geführten Kontrollblättern nachvollziehenlassen.Wenn mindestens eine der folgenden Bedingungen zutrifft, KÖNNEN diese Benutzer-IDseinem bestimmten Tool an Stelle einer bestimmten Person zugeordnet und von allenGruppenmitgliedern verwendet werden, ohne dass das zugehörige Kennwort geändertwerden muss:• Die Benutzer-ID DARF NICHT über ein Netzwerk zugänglich sein.• Die Benutzer-ID DARF NICHT anders, als von einer dedizierten Workstationaus zugänglich sein, die sich in einem zutrittskontrollierten Bereich befindet.Benutzer-IDsGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Einrichten, Ändern, Inaktivieren und Entfernen von Benutzer-IDs sowieder zugehörigen Zugriffsberechtigungen für Mitarbeiter von Dienstbetreiber(Benutzer-ID-Administrator)DienstbetreiberPOptionale Aufgabenbereichegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 674 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVerantwortungen (P = Performt, A = Assistiert)Einrichten, Ändern, Inaktivieren und Entfernen von Benutzer-IDs sowieder zugehörigen Zugriffsberechtigungen für Mitarbeiter des spezifischenDienstes (Benutzer-ID-Administrator)Implementieren und Verwalten von Sicherheitsmaßnahmen für dieSubsysteme und Anwendungen, die zur Gewährleistung der Sicherheitnicht die Zugriffskontrollsoftware verwendenPPBenutzer-IDsZulassen der gemeinsamenVerwendung von Benutzer-IDsVerbindlicher WertGemeinsame Benutzer-IDs SOLLEN NICHT Verwendungfinden. Ausnahmen MÜSSEN wie oben angegebenumgesetzt werdenBerechtigung von Benutzer-IDsFür die Berechtigung von Benutzern für den Zugriff auf die verfügbaren ComputersystemeMUSS ein Prozess implementiert werden.Berechtigung von Benutzer-IDsGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Berechtigen von Benutzer-IDs für Mitarbeiter desDienstbetreibersDienstbetreiberPAufgabenbereiche für die nur Mitarbeiter eines bestimmtenDienstes berechtigt werden müssenVerantwortungen (P = Performt, A = Assistiert)Berechtigen von Benutzer-IDs für Mitarbeiter des spezifischenDienstesPBerechtigung von Benutzer-IDsAutorisierungsprozessAls Cluster verwalteteSystemeVerbindlicher WertManager des Benutzers benachrichtigenBenutzer-IDs SOLLEN nur für den Zugriff auf das Systemclusterund nicht für den Zugriff auf jeden einzelnen Knotendes Clusters erneut überprüft werden.Managementbenachrichtigung bei WiderrufEntsprechende Anforderung gemäß ISO/IEC 27002:2005gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 675 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDiese Ziffer entspricht Ziffer 8.3.3 Removal of access rights (Widerrufen von Zugriffsrechten).Wenn ein Benutzer aus dem Unternehmen ausscheidet, sich beurlauben lässt und nichterwartet wird, dass er wieder in ein reguläres Beschäftigungsverhältnis eintritt, oder wennfür ihn kein gültiger geschäftlicher Grund mehr vorliegt, auf bestimmte Daten zugreifen zukönnen, MUSS der zuständige Manager den bzw. die für die Benutzer-ID zuständigenAdministrator(en) hierüber informieren. Die für die Benutzer-ID zuständigen AdministratorenMÜSSEN über einen Prozess oder technische Kontrollmechanismen verfügen, um indiesem Fall den Zugriff des betreffenden Benutzers auf das bzw. die Systeme sofort nachder Managementbenachrichtigung zu unterbinden.Managementbenachrichtigung bei WiderrufGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Benachrichtigen der für die Benutzer-ID zuständigen Administratoren,wenn für Mitarbeiter des Dienstbetreibers keine Zugriffsnotwendigkeitmehr bestehtDienstbetreiberPOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Benachrichtigen der für die Benutzer-ID zuständigen Administratoren,wenn für Mitarbeiter des spezifischen Dienstes keine Zugriffsnotwendigkeitmehr bestehtPÜberprüfung des BeschäftigungsverhältnissesIn regelmäßigen Zeitabständen MUSS überprüft werden, ob der Eigner einer bestimmtenBenutzer-ID weiterhin im Unternehmen tätig ist. Bei Mitarbeitern von Auftragnehmern desUnternehmens ist zu überprüfen, ob der Eigner noch für das Unternehmen tätig ist. Istdies nicht mehr der Fall, MUSS eine der folgenden Aktionen ausgeführt werden:• Die Benutzer-ID MUSS vom System gelöscht werden. (Aus DokumentationsundRevisionsgründen ist Benutzer-ID noch für eine gewisse Zeit vorzuhalten.)• Die Gültigkeit der Benutzer-ID auf dem System MUSS widerrufen werden.• Das Kennwort der Benutzer-ID MUSS in einen dem früheren Eigner der IDunbekannten Wert geändert werden.Hinweis: Im Rahmen dieses Prozesses ist es nicht unbedingt erforderlich, die betroffeneBenutzer-ID aus den entsprechenden Zugriffssteuerungslisten (ACLs) zu löschen.Dieser Prozess dient als zusätzliche Sicherheit für den Fall, dass der für die Benutzer-IDzuständige Administrator vom Management nicht über das Ausscheiden eines Mitarbeitersunterrichtet wurde.Überprüfung des Beschäftigungsverhältnissesgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 676 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Prüfen des Beschäftigungsverhältnisses für Mitarbeiter des DienstbetreibersDienstbetreiberPOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Prüfen des Beschäftigungsverhältnisses für Mitarbeiter des spezifischenDienstesPÜberprüfung des BeschäftigungsverhältnissesIntervall für das Prüfen des Beschäftigungsverhältnissesbeim spezifischen DienstesNachweis für die Prüfung des Beschäftigungsverhältnissesund Aufzeichnung der entsprechendenKorrekturmaßnahmenVersetzen von Mitarbeitern an einen anderenStandort oder in einen anderen BereichVerbindlicher WertVierteljährlichAufbewahrung der aktuellen Überprüfungsunterlagensowie der Unterlagenzu den beiden vorhergehenden ÜberprüfungenLöschung erst erforderlich, wenn dergeschäftliche Grund erlischtÜberprüfung des BeschäftigungsverhältnissesIntervall für das Prüfen des Beschäftigungsverhältnisses beimDienstbetreiberVerbindlicherWerthalbjährlich.Erneute Überprüfung (Revalidierung) von Benutzer-IDs auf Vorliegen eines geschäftlichenGrundesEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.2.4 Review of user access rights (Überprüfung derZugriffsrechte der Benutzer).Für die erneute Überprüfung (Revalidierung) von Benutzer-IDs MUSS ein dokumentierterProzess implementiert werden. Im Rahmen dieser erneuten Überprüfung MÜSSEN dieBenutzer-IDs überprüft werden. Darüber hinaus MUSS festgestellt werden, ob noch eingültiger geschäftlicher Grund für die Zugriffsberechtigung des Benutzers auf das Systemvorliegt. Benutzer, deren geschäftlicher Grund für den Systemzugriff erloschen ist, MÜS-SEN zwecks Löschung ihrer ID dem für die Benutzer-ID zuständigen Administrator gemeldetwerden. Die Löschungen MÜSSEN mit Zeit und Grund dokumentiert werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 677 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie erneute Überprüfung KANN in Form eines Berichts an das zuständige Managementrealisiert werden, in dem alle Mitarbeiter aufgeführt sind, die über eine Zugriffsberechtigungfür das System verfügen. Das Management MUSS hierbei festgestellte Abweichungenweiterverfolgen und mit dem für die Benutzer-ID zuständigen Administrator abklären.Die erstellten Berichte KÖNNEN wieder zurückgegeben werden.Erneute Überprüfung (Revalidierung) von Benutzer-IDs auf Vorliegen eines geschäftlichenGrundesGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Erneutes Prüfen der Dienstbetreiber Benutzer-IdsOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Erneutes Prüfen der Benutzer-IDs des spezifischenDienstesDienstbetreiberPPErneute Überprüfung von Benutzer-IDsauf Vorliegen einesgeschäftlichen GrundesIntervall für die erneute Überprüfungvon Benutzer-IDsAls Cluster verwaltete SystemeNachweis für die Durchführung dererneuten Überprüfung von Benutzer-IDsVerbindlicher WertJährlichBenutzer-IDs SOLLEN nur für den Zugriff auf dasSystemcluster und nicht für den Zugriff auf jedeneinzelnen Knoten des Clusters erneut überprüftwerden.Aktuelle sowie vorhergehende erneute ÜberprüfungErneute Überprüfung von Benutzer-IDs auf Vorliegen eines geschäftlichenGrundesIntervall für die erneute Überprüfung von Benutzer-IDs des DienstbetreibersVerbindlicherWertJährlichG3.1.2 - KennwörterEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.2.3 User password management (Verwaltung von Benutzerpasswörtern)und Ziffer 11.5.3 Password management system (Passwortverwaltungssystem).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 678 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKennwörter können zur Authentisierung von Benutzern verwendet werden. Die Zuverlässigkeitdes gewählten Kennworts ist der wichtigste Faktor für den Schutz von Systemenund Anwendungen. Die Regeln für das Definieren von Kennwörtern, die im vorliegendenAbschnitt erläutert werden, gelten für alle Kennwörter, die für die Anmeldung an den verfügbarenSystemen und Subsystemen eingesetzt werden.Kennwörter Verbindlicher Wert Anforderungendes spezifischenDienstesMindestlänge für Kennwörter 8SyntaxBenutzer-ID im KennwortMaximum für Änderungsintervall(siehe folgenden Hinweis)Anzahl der Kennwortwechsel, beidenen das Kennwort nicht erneutverwendet werden kann,(Speichern des Hashwertes der angegebenenZahl von Kennwörtern fürmindesten 180 Tage. Neue Kennwörterwerden nur akzeptiert, wennsie nicht mit den verwendeten gespeichertenKennwörtern übereinstimmen)Gemeinsame Benutzung von KennwörternWerkseitig eingestellte Standardkennwörterfür gelieferte Betriebssystem-/Programmproduktezur Verwendungbei der System- und Produktinstallationbzw. -konfiguration„Kennphrasen“ oder „Smartcards“Kennwörter, die zwar innerhalb deso. a. Änderungsintervalls nicht geändertwurden, jedoch den Status „Abgelaufen“habenDas Kennwort MUSS eineMischung alphabetischer undnicht-alphabetischer Zeichen(Zahlen, Satzzeichen oderSonderzeichen) oder eine Mischungvon mindestens zweiArten von nicht-alphabetischenZeichen enthaltenNein90 Tage4Nur, wenn die individuelle Zuordnunggewährleistet istSobald wie möglich ändernZulässige Alternativen zuKennwörternKeine Verletzung der Anforderungenfür das Kennwortänderungsintervallgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 679 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturHinweis: Bestimmte Benutzer-IDs müssen über Kennwörter ohne Ablaufdatum verfügen.Diese Ausnahmen sind im Betriebskonzept des Dienstbetreibers beschrieben.Schutz von KennwörternSchutz von KennwörternKennwortübertragungKennwortspeicherungMindestanforderungDas Kennwort DARF NICHT im Klartext über Internet, öffentlicheNetzwerke oder drahtlose Endgeräte übertragen werden.Bei der Speicherung in Dateien oder Datenbanken MUSS dasKennwort in Form seines Hashwertes gespeichert werden.Anmeldeversuche mit ungültigem KennwortEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.5.1 Secure log-on procedures (Sichere Anmeldeverfahren).Im System MÜSSEN Kontrollmechanismen implementiert werden, die die Anzahl der Anmeldeversuchemit ungültigen Kennwörtern beschränken. Hierbei MUSS nach einer bestimmtenAnzahl aufeinander folgender ungültiger Anmeldeversuche die betreffende Benutzer-IDgelöscht oder gesperrt bzw. mit Hilfe eines Anmeldeinduktors das Zeitintervallbis zum nächsten Anzeigen der Anmeldeanzeige exponential, ausgehend von einem Wertvon 5 sec, erhöht werden.Anmeldeversuche mit ungültigem KennwortAufeinander folgende, ungültige Anmeldeversuche,nach denen weitere Anmeldungen verhindert oderverzögert werdenAnforderung5Zurücksetzen von KennwörternFür das Zurücksetzen von Kennwörtern MUSS ein Prozess implementiert werden. DerProzess MUSS entweder Vorkehrungen für eine positive Identifikation des Anforderersenthalten, oder das neue Kennwort MUSS an einen Manager gesendet oder in einer gesichertenMailbox (z. B. Telefonmail- oder primäre Benutzer-ID des Inhabers der Benutzer-ID) aufgezeichnet werden.Zurücksetzen von KennwörternGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Dienstbetreibergematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 680 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturZurücksetzen von KennwörternDefinieren von Prozesskriterien für das Zurücksetzen von Benutzerkennwörternund deren Weitergabe an autorisierte MitarbeiterZurücksetzen von Kennwörtern für Benutzer-IDs und Weitergabe dieserKennwörter an autorisierte MitarbeiterPPOptionale Aufgabenbereiche/Verantwortungen (P = Performt, A = Assistiert)Definieren von Prozesskriterien für das Zurücksetzen von Benutzerkennwörterndes spezifischen Dienstes und deren Weitergabe an autorisierteMitarbeiter (je nach Bedarf in regulärer Form oder für Gehörlose/Hörgeschädigte)Zurücksetzen von Kennwörtern für Benutzer-IDs des spezifischenDienstes und Weitergabe dieser Kennwörter an autorisierte MitarbeiterPPAuthentifizierungstickets und -tokensIn verteilten Datenverarbeitungsumgebungen können Authentifizierungsserver eingesetztwerden, um den Zugriff auf mehrere Systeme oder Services zu gewähren. Entweder beimAnmelden oder direkt anschließend wird ein Authentifizierungsprozess aufgerufen, dereinen Sitzungsschlüssel und ein zugehöriges Ticket generiert. Tokens und Tickets werdendann verwendet, um die Berechtigung eines Benutzers für den Zugriff auf oder die Verwendungeiner Ressource zu belegen.Die normale Gültigkeitsdauer eines Tokens für Benutzer mit System- oder Sicherheitsadministratorberechtigungsowie Endbenutzer MUSS sich nach dem jeweiligen Sicherheitsrisikorichten.Authentifizierungstickets und -tokensStandardmäßiger Höchstwert der Token-Gültigkeitfür System- und SicherheitsadministratorenStandardmäßiger Höchstwert der Token-Gültigkeitfür EndbenutzerAuthentifizierungstoolsZugriff auf Informationen oder Services aufanderen Systemen innerhalb einer verteiltenDatenverarbeitungsumgebungAnforderung12 Stunden30 StundenDürfen eingesetzt werden, wenn eshierdurch nicht zu unberechtigtenZugriffen auf unverschlüsselte Kennwörterkommen kannMUSS auf der Ausstellung von Ticketsmit Hilfe der Benutzer-ID und desKennworts sowie dem Austausch verschlüsselterTickets basierengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 681 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.1.3 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtA_03275STitel Beschreibung Rel. QuelleBenutzer_IDs_01: Vergabevon Zugriffsberechtigungen.A_03276 S Benutzer_IDs_02: EindeutigeZuordnung der zu einer Person.A_03277 SA_03278SBenutzer_IDs_03: EindeutigeZuordnung des geheimen Codes.Benutzer_IDs_04: Verwendungeiner Benutzer-ID durcheine GruppeDie Zugriffsberechtigungen für die Systeme MÜSSEN auf der Basisder aktuellen geschäftlichen Notwendigkeiten vergeben unddurch die Überprüfung der Identität von Benutzern und Anwendungenkontrolliert werdenBenutzer-IDs MÜSSEN einer bestimmten Person eindeutig zugeordnetwerden können.Jedem Benutzer muß eine eindeutige Benutzer-ID und ein geheimerCode (z. B. ein Kennwort) zugewiesen werden, die nur demEigner der Benutzer-ID bekannt sind.Die hier beschriebenen Benutzer-IDs sind die IDs für die Anmeldungam System bzw. Server.Die Verwendung einer Benutzer-ID durch eine Gruppe stellt grundsätzlichein Risiko da. Die Notwendigkeit MUSS jeweils im Sicherheitskonzeptbegründet werden und es MUSS dargelegt werden,wieso die Sicherheit des Systems dadurch nicht unzulässig reduziertwird.Unter folgenden Bedingungen DÜRFEN Benutzer-IDs bzw. Kennwörtervon einer Gruppe gemeinsam verwendet werden:• Die Software lässt die Verwaltung persönlicher Zugriffsaccountsnicht zu und spezielle Benutzer-IDs oder Kennwörter sind für denZugriff auf Funktionen, die von einer bestimmten Personengruppebzw. Rolle benötigt werden, unbedingt erforderlich.• Die nicht autorisierte Verwendung der Benutzer-ID oder desKennworts MUSS verhindert werden.• Der Zugriff MUSS nur auf die Funktionen eingeschränkt werden,die für die Gruppe genehmigt sind.• Alle Mitglieder der Gruppe MÜSSEN für die Daten zugriffsberechtigtsein, für die die Benutzer-ID zugriffsberechtigt ist.AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 682 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03279A_03280SSTitel Beschreibung Rel. QuelleBenutzer_IDs_05: Bedingungenfür die Verwendung einerBenutzer-ID durch eine GruppeBenutzer_IDs_06: Einrichten,Ändern, Inaktivieren und Entfernenvon Benutzer-Ids ( Mitarbeitervon Dienstbetreibers )A_03281 S Benutzer_IDs_07: Einrichten,Ändern, Inaktivieren und Entfernenvon Benutzer-Ids ( Mitarbeiterdes spezifischenDienstes)A_03282SBenutzer_IDs_08: Implementierenund Verwalten von zusätzlicherSicherheitsmaßnahmen.A_03283 S Benutzer_IDs_09: Zulassender gemeinsamen Verwendungvon Benutzer-Ids.• Die Zuordnung MUSS sich aus manuell geführten Kontrollblätternnachvollziehen lassen.Wenn mindestens eine der folgenden Bedingungen zutrifft, KÖN-NEN diese Benutzer-IDs einem bestimmten Tool an Stelle einerbestimmten Person zugeordnet und von allen Gruppenmitgliedernverwendet werden, ohne dass das zugehörige Kennwort geändertwerden muss:• Die Benutzer-ID DARF NICHT über ein Netzwerk zugänglichsein.• Die Benutzer-ID DARF NICHT anders, als von einer dediziertenWorkstation aus zugänglich sein, die sich in einem zutrittskontrolliertenBereich befindet.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Einrichten, Ändern, Inaktivieren und Entfernen von Benutzer-IDssowie der zugehörigen Zugriffsberechtigungen für Mitarbeiter desDienstbetreibers (Benutzer-ID-Administrator)Optionaler Aufgabenbereich(Dienstbetreiber performt):Einrichten, Ändern, Inaktivieren und Entfernen von Benutzer-IDssowie der zugehörigen Zugriffsberechtigungen für Mitarbeiter desspezifischen Dienstes (Benutzer-ID-Administrator)Optionaler Aufgabenbereich(Dienstbetreiber performt):Implementieren und Verwalten von Sicherheitsmaßnahmen für dieSubsysteme und Anwendungen, die zur Gewährleistung der Sicherheitnicht die Zugriffskontrollsoftware verwendenZulassen der gemeinsamen Verwendung von Benutzer-IDs:Gemeinsame Benutzer-IDs SOLLEN NICHT Verwendung finden.Ausnahmen MÜSSEN wie oben angegeben umgesetzt werdenAnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 683 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03284 S Benutzer_IDs_10: Berechtigenvon Benutzer-IDs für Mitarbeiterdes DienstbetreibersA_03285SBenutzer_IDs_11: Berechtigenvon Benutzer-IDs für Mitarbeiterdes spezifischen DienstesA_03286 S Benutzer_IDs_12: Benachrichtigender für die Benutzer-IDzuständigen Administratoren(Mitarbeiter des Dienstbetreibers)A_03287 S Benutzer_IDs_13: Benachrichtigender für die Benutzer-IDzuständigen Administratoren(Mitarbeiter des spezifischenDienstes)A_03288 SBenutzer_IDs_14: Prüfung derBenutzer-IDs.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Berechtigen von Benutzer-IDs für Mitarbeiter des DienstbetreibersAufgabenbereiche für die nur Mitarbeiter eines bestimmten Dienstesberechtigt werden müssen (Dienstbetreiber performt):Berechtigen von Benutzer-IDs für Mitarbeiter des spezifischenDienstesGrundlegender Aufgabenbereich(Dienstbetreiber performt):Benachrichtigen der für die Benutzer-ID zuständigen Administratoren,wenn für Mitarbeiter des Dienstbetreibers keine Zugriffsnotwendigkeitmehr bestehtOptionaler Aufgabenbereich(Dienstbetreiber performt):Benachrichtigen der für die Benutzer-ID zuständigen Administratoren,wenn für Mitarbeiter des spezifischen Dienstes keine Zugriffsnotwendigkeitmehr bestehtIn regelmäßigen Zeitabständen MUSS überprüft werden, ob derEigner einer bestimmten Benutzer-ID weiterhin im Unternehmentätig ist. Bei Mitarbeitern von Auftragnehmern des Unternehmensist zu überprüfen, ob der Eigner noch für das Unternehmen tätigist. Ist dies nicht mehr der Fall, MUSS eine der folgenden Aktionenausgeführt werden:• Die Benutzer-ID MUSS vom System gelöscht werden. (Aus Dokumentations-und Revisionsgründen ist Benutzer-ID noch für einegewisse Zeit vorzuhalten.)• Die Gültigkeit der Benutzer-ID auf dem System MUSS widerrufenwerden.• Das Kennwort der Benutzer-ID MUSS in einen dem früheren Eignerder ID unbekannten Wert geändert werden.AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 684 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03289 S Benutzer_IDs_15: Prüfen desBeschäftigungsverhältnissesfür Mitarbeiter des DienstbetreibersA_03290 S Benutzer_IDs_16: Prüfen desBeschäftigungsverhältnissesfür Mitarbeiter des spezifischenDienstes.A_03291 S Benutzer_IDs_17: Intervall fürdas Prüfen des Beschäftigungsverhältnissesbeim spezifischenDienst.A_03292SBenutzer_IDs_18: Nachweisfür die Prüfung des BeschäftigungsverhältnissesA_03293 S Benutzer_IDs_19: Intervall fürdas Prüfen des BeschäftigungsverhältnissesbeimDienstbetreiberA_03294 SBenutzer_IDs_20: Revalidierungder Benutzer-IDs.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Prüfen des Beschäftigungsverhältnisses für Mitarbeiter desDienstbetreibersOptionaler Aufgabenbereich(Dienstbetreiber performt):Prüfen des Beschäftigungsverhältnisses für Mitarbeiter des spezifischenDienstesIntervall für das Prüfen des Beschäftigungsverhältnisses beim spezifischenDienst: VierteljährlichNachweis für die Prüfung des Beschäftigungsverhältnisses undAufzeichnung der entsprechenden Korrekturmaßnahmen:Aufbewahrung der aktuellen Überprüfungsunterlagen sowie derUnterlagen zu den beiden vorhergehenden ÜberprüfungenIntervall für das Prüfen des Beschäftigungsverhältnisses beimDienstbetreiber: halbjährlichFür die erneute Überprüfung (Revalidierung) von Benutzer-IDsMUSS ein dokumentierter Prozess implementiert werden. ImRahmen dieser erneuten Überprüfung MÜSSEN die Benutzer-IDsüberprüft werden. Darüber hinaus MUSS festgestellt werden, obnoch ein gültiger geschäftlicher Grund für die Zugriffsberechtigungdes Benutzers auf das System vorliegt. Benutzer, deren geschäftlicherGrund für den Systemzugriff erloschen ist, MÜSSEN zwecksLöschung ihrer ID dem für die Benutzer-ID zuständigen Administratorgemeldet werden. Die Löschungen MÜSSEN mit Zeit undGrund dokumentiert werden.Die erneute Überprüfung KANN in Form eines Berichts an dasAnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 685 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03295 S Benutzer_IDs_21: Revalidierungder Dienstbetreiber Benutzer-IdsA_03296 S Benutzer_IDs_22:RevalidierungderBenutzer-IDs des spezifischenDienstesA_03297A_03298SSBenutzer_IDs_23: Intervall fürdie RevalidierungBenutzer_IDs_24: Benutzer-Ids auf Clustersystemen.A_03299 S Benutzer_IDs_25: Nachweisüber die Durchführung derRevalidierung.A_03300 S Benutzer_IDs_26: Intervall fürdie Revalidierung von Benutzer-IDsdes DienstbetreibersA_03301 SKennwörter_01: KennwortlängeA_03302 S Kennwörter_02: Komplexitätsanforderungenzuständige Management realisiert werden, in dem alle Mitarbeiteraufgeführt sind, die über eine Zugriffsberechtigung für das Systemverfügen. Das Management MUSS hierbei festgestellte Abweichungenweiterverfolgen und mit dem für die Benutzer-ID zuständigenAdministrator abklären. Die erstellten Berichte KÖNNENwieder zurückgegeben werden.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Revalidierung der Dienstbetreiber Benutzer-IdsOptionaler Aufgabenbereich(Dienstbetreiber performt):Revalidierung der Benutzer-IDs des spezifischen DienstesIntervall für die Revalidierung von Benutzer-IDs: JährlichAls Cluster verwaltete Systeme:Benutzer-IDs SOLLEN nur für den Zugriff auf das Systemclusterund nicht für den Zugriff auf jeden einzelnen Knoten des Clusterserneut überprüft werden.Nachweis über die Durchführung der Revalidierung von Benutzer-IDs:Aktuelle sowie vorhergehende erneute ÜberprüfungIntervall für die Revalidierung von Benutzer-IDs des Dienstbetreibers:JährlichMindestlänge für Kennwörter:8Kennwort-Syntax : Das Kennwort MUSS eine Mischung alphabetischerund nicht-alphabetischer Zeichen (Zahlen, Satzzeichen oderAnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1Anhanggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 686 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03303 S Kennwörter_03: Komplexitätsanforderungen/ Ausschlußkriterien.A_03304A_03305A_03306A_03307A_03308A_03309SSSSSSKennwörter_04: Änderungsintervall.Kennwörter_05: KennworthistoryKennwörter_06: GemeinsameBenutzung von KennwörternKennwörter_07: Ändern vonStandardkennwörtern.Kennwörter_08: Alternative zuKennwörtern.Kennwörter_09: Behandlungabgelaufener Kennwörter.A_03310 S Kennwörter_10: Keine Klartextübertragungvon Kennwörtern.Sonderzeichen) oder eine Mischung von mindestens zwei Artenvon nicht-alphabetischen Zeichen enthaltenBenutzer-ID im Kennwort; NeinMaximum für Änderungsintervall (siehe folgenden Hinweis) : 90TageAnzahl der Kennwortwechsel, bei denen das Kennwort nicht erneutverwendet werden kann: 4(Speichern des Hashwertes der angegebenen Zahl von Kennwörternfür mindesten 180 Tage. Neue Kennwörter werden nur akzeptiert,wenn sie nicht mit den verwendeten gespeicherten Kennwörternübereinstimmen)Gemeinsame Benutzung von Kennwörtern :Nur, wenn die individuelle Zuordnung gewährleistet istWerkseitig eingestellte Standardkennwörter für gelieferte Betriebssystem-/Programmproduktezur Verwendung bei der System- undProduktinstallation bzw. -konfiguration :Sobald wie möglich ändern„Kennphrasen“ oder „Smartcards“ sind Zulässige Alternativen zuKennwörternKennwörter, die zwar innerhalb des o. a. Änderungsintervalls nichtgeändert wurden, jedoch den Status „Abgelaufen“ haben:Keine Verletzung der Anforderungen für das KennwortänderungsintervallKennwortübertragung:Das Kennwort DARF NICHT im Klartext über Internet, öffentlicheNetzwerke oder drahtlose Endgeräte übertragen werden.G 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 687 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03311A_03312SSTitel Beschreibung Rel. QuelleKennwörter_11: KennwortspeicherungKennwörter_12: Beschränkungvon Anmeldeversuchenmit ungültigen Kennwörtern.A_03313 S Kennwörter_13: Maßnahmenbei Anmeldeveruchen mit ungültigenKennwörtern.A_03314 SKennwörter_14: Zurücksetzenvon Kennwörtern.A_03315 S Kennwörter_15:Definieren vonProzesskriterien für das Zurücksetzenvon BenutzerkennwörternA_03316 SKennwörter_16: Zurücksetzenvon Kennwörtern für Benutzer-IdsA_03317 S Kennwörter_17:Definieren vonProzesskriterien für das Zurücksetzenvon Benutzer-Kennwortspeicherung:Bei der Speicherung in Dateien oder Datenbanken MUSS dasKennwort in Form seines Hashwertes gespeichert werdenIm System MÜSSEN Kontrollmechanismen implementiert werden,die die Anzahl der Anmeldeversuche mit ungültigen Kennwörternbeschränken. Hierbei MUSS nach einer bestimmten Anzahl aufeinanderfolgender ungültiger Anmeldeversuche die betreffendeBenutzer-ID gelöscht oder gesperrt bzw. mit Hilfe eines Anmeldeinduktorsdas Zeitintervall bis zum nächsten Anzeigen der Anmeldeanzeigeexponential, ausgehend von einem Wert von 5 sec,erhöht werden.Aufeinander folgende, ungültige Anmeldeversuche, nach denenweitere Anmeldungen verhindert oder verzögert werden: 5Für das Zurücksetzen von Kennwörtern MUSS ein Prozess implementiertwerden. Der Prozess MUSS entweder Vorkehrungen füreine positive Identifikation des Anforderers enthalten, oder dasneue Kennwort MUSS an einen Manager gesendet oder in einergesicherten Mailbox (z. B. Telefonmail- oder primäre Benutzer-IDdes Inhabers der Benutzer-ID) aufgezeichnet werdenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Definieren von Prozesskriterien für das Zurücksetzen von Benutzerkennwörternund deren Weitergabe an autorisierte MitarbeiterGrundlegender Aufgabenbereich(Dienstbetreiber performt):Zurücksetzen von Kennwörtern für Benutzer-IDs und Weitergabedieser Kennwörter an autorisierte MitarbeiterOptionaler Aufgabenbereich(Dienstbetreiber performt):Definieren von Prozesskriterien für das Zurücksetzen von Benut-AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 688 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03318A_03319SSTitel Beschreibung Rel. Quellekennwörtern des spezifischenDienstesKennwörter_18: Zurücksetzenvon Kennwörtern für Benutzer-IDs des spezifischen DienstesKennwörter_19: Einsatz vonAuthentisierungsservern.A_03320 S Kennwörter_20: Höchstwertder Token-Gültigkeit für System-und SicherheitsadministratorenA_03321 S Kennwörter_21:Höchstwertder Token-Gültigkeit für Endbenutzer.A_03322 SKennwörter_22: Einsatz vonAuthentifizierungstoolsA_03323 S Kennwörter_23: Zugriff aufInformationen oder Serviceszerkennwörtern des spezifischen Dienstes und deren Weitergabean autorisierte Mitarbeiter (je nach Bedarf in regulärer Form oderfür Gehörlose/Hörgeschädigte)Optionaler Aufgabenbereich(Dienstbetreiber performt):Zurücksetzen von Kennwörtern für Benutzer-IDs des spezifischenDienstes und Weitergabe dieser Kennwörter an autorisierte MitarbeiterIn verteilten Datenverarbeitungsumgebungen können Authentisierungsservereingesetzt werden, um den Zugriff auf mehrere Systemeoder Services zu gewähren. Entweder beim Anmelden oderdirekt anschließend wird ein Authentifizierungsprozess aufgerufen,der einen Sitzungsschlüssel und ein zugehöriges Ticket generiert.Tokens und Tickets werden dann verwendet, um die Berechtigungeines Benutzers für den Zugriff auf oder die Verwendung einerRessource zu belegen.Die normale Gültigkeitsdauer eines Tokens für Benutzer mit System-oder Sicherheitsadministratorberechtigung sowie EndbenutzerMUSS sich nach dem jeweiligen Sicherheitsrisiko richtenStandardmäßiger Höchstwert der Token-Gültigkeit für System- undSicherheitsadministratoren:12 StundenStandardmäßiger Höchstwert der Token-Gültigkeit für Endbenutzer:30 StundenAuthentifizierungstools :Dürfen eingesetzt werden, wenn es hierdurch nicht zu unberechtigtenZugriffen auf unverschlüsselte Kennwörter kommen kannZugriff auf Informationen oder Services auf anderen Systemeninnerhalb einer verteilten Datenverarbeitungsumgebung :AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1AnhangG 3.1Anhanggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 689 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelleauf anderen Systemen innerhalbeiner verteilten DatenverarbeitungsumgebungMUSS auf der Ausstellung von Tickets mit Hilfe der Benutzer-IDund des Kennworts sowie dem Austausch verschlüsselter TicketsbasierenG 3.1gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 690 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.2 - Definieren und Schützen von AssetsAls Assets werden z. B. Texte, Programme und Daten bezeichnet. Objekte, die einer bestimmtenPerson oder Gruppe gehören, werden als Benutzerassets bezeichnet. Bei Objekten,die bestimmten Systemservices oder Funktionen zugeordnet sind, spricht man vonBetriebssystemassets. Als Betriebssystemassets werden die Datenobjekte bezeichnet,die Bestandteil folgender Systemkomponenten sind:• Systemkontrollprogramm sowie die zugehörigen Mechanismen für dieZugriffskontrolle• Subsysteme und LizenzprogrammeDefinieren und Schützen von AssetsGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assist)Installieren, Pflegen und Erweitern neuer oder vorhandener Softwarezur Datenzugriffskontrolle (im Bedarfsfall), sofern Dienstbetreiber denService für notwendig erachtetImplementieren der Funktionen und Merkmale der Zugriffskontrollsoftware,die die im vorliegenden Dokument definierten Anforderungen desspezifischen Dienstes in Bezug auf die geltenden SicherheitsverfahrenerfüllenDienstbetreiberPPG3.2.1 - Klassifizierung von Assets und DatenobjektenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 7.2.1 Classification guidelines (Richtlinien für die Einstufung).Die Klassifizierung bildet die rechtliche und physische Basis für den Schutz von Datengegen Verlust, Missbrauch und unberechtigten Zugriff etc.Die Klassifizierung von Assets erfolgt im Sicherheitskonzept des Dienstbetreibers auf Basisder Vorgaben der gematik.Der Dienstbetreiber muss alle Assets identifizieren und die Wichtigkeit dieser Assets dokumentieren.Das Inventar der Assets MUSS alle Informationen enthalten, die zur Wiederherstellungnach einer Katastrophe nötig sind, einschließlich der Art des Assets, Format, Ort, Backup-Informationen und Lizenzinformationen.Softwareverwaltunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 691 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie Betreiber müssen einen geordneten Zufluss von Software-Assets nachweisen können,der die folgenden Anforderungen erfüllen MUSS:• Jegliche Software wird erfasst (Versionsnummer, Updates) – auch Firmware.• Die Quelle der Software ist nachvollziehbar.• Die Authentizität der Quelle oder die Integrität der Software wurde überprüft.• Ihre Verwendung wurde prozesskonform freigegeben.• Ihre Verwendung wird dokumentiert.• Die Software ist zentral beim Betreiber verfügbar solange sie im Einsatz istund sechs Monate darüber hinaus.Auf diese Weise ist die Verfügbarkeit der Software bei Neuinstallationen (z. B. nach Störungen),Zusatzinstallationen (zur Kapazitätserweiterung) oder Testinstallationen (z. B.zur Analyse von Sicherheitsproblemen) jederzeit gewährleistet.Historie von Konfigurationsdaten und SoftwareständenSicherheitsprobleme entwickeln sich oft über einen längeren Zeitraum und müssen deshalbretrospektiv analysierbar sein, indem sie z.B. in der Produktions-Referenzumgebungnachgestellt werden. Vereinfachend darf angenommen werden, dass Sicherheitsproblemekaum von Produktionsdaten, sehr wohl aber von Konfigurationsdaten und Softwareständenabhängen.Deshalb MÜSSEN Konfigurationsdaten und Softwarestände über einen Zeitraum von 3Monate auf Tagesbasis und über einen Zeitraum von 10 Jahren auf Monatsbasis nachvollziehbarund wieder herstellbar sein.Zur Beurteilung, ob festgestellte Abweichungen oder Änderungen geplant sind oder einenSicherheitsvorfall darstellen, MÜSSEN Konfigurationsänderungen vollständig dokumentiertsein. Der Zugriff muss sowohl chronologisch als auch über den Namen der Komponentejederzeit möglich sein.Klassifizierung von Datenobjekten und AssetsKlassifizierung von Datenobjekten durch den DienstbetreiberVerantwortung für die Klassifizierung von DatenobjektenVerantwortlich für die Klassifizierung von AssetsVerbindlicher WertNicht erforderlichgematikDienstbetreiberG3.2.2 - Schutz vertraulicher InformationenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 7.2.2 Information labelling and handling (Kennzeichnung undBehandlung von Informationen).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 692 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturBenutzer und Assetverantwortliche MÜSSEN den Schutzbedarf der Informationen bezüglichder Vertraulichkeit berücksichtigen.Schutz vertraulicher InformationenOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Feststellen der von den Systemen/Servern unterstützten Klassifizierungsstufebezüglich des Schutzbedarfes der VertraulichkeitInformieren der Benutzer darüber, dass Informationen mit einem bestimmtenSchutzbedarf nicht mit einem bestimmten System verarbeitetwerden könnenDienstbetreiberPPSchutz vertraulicher InformationenVerfügbarkeit von vertraulichen Informationenfür BenutzerDurchführung normaler Aktivitätenzur Systemunterstützung, wie z.B.SystemdatensicherungenÜbertragung vertraulicher Daten überdas Internet, öffentliche Netzwerkeoder drahtlose EndgeräteVerbindlicher WertNur für Benutzer, die aus geschäftlichen GründenZugriff benötigen und über eine explizite BerechtigungverfügenExplizite Zugriffsberechtigung des Eigners derBenutzerressource wird nicht benötigtVerschlüsseln (Verschlüsselungsanforderungensiehe Anhang F)G3.2.3 - Change ManagementEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.1.2 Change Management.Assets (insbesondere auch Operative Systeme und Anwendungen) MÜSSEN Gegenstandeines strengen Änderungsmanagements sein. Bei der Durchführung von ÄnderungenMÜSSEN folgende Punkte nachweislich berücksichtigt worden sein:• Identifikation und Aufzeichnung aller Änderungen;• Planung und Testen von Änderungen;• Bewertung der potentiellen Auswirkungen, auch im Hinblick auf die Sicherheitvon solchen Änderungen;• Formeller Genehmigungsprozess für Änderungen;• Benachrichtigung und Information aller relevanten Personen über die Detailsder Änderung;gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 693 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Rückfallverfahren, welches die Vorgehensweisen und Verantwortungen fürAbbruch und Wiedererlangung des Ursprungszustands für den Fall regelt,dass eine Änderung erfolglos ist oder unvorhergesehene Ereignisse auftreten.Dabei SOLL das Change Management des Dienstbetreibers folgende Punkte enthalten:• Sicherstellen, dass Änderungen nur von durch ihre Rolle befugten Personeneingereicht werden• Überprüfung der kontroll- und integritätssichernden Verfahren um sicher zustellen, dass diese nicht durch die Änderung kompromittiert werden• Identifikation aller Software, Informationen, Datenbanken und von Hardwaredie Verbesserungen benötigen• Sicherstellen, dass die gesamte Systemdokumentation bei jeder Fertigstellungjeder Änderung aktualisiert wird und dass die alte Dokumentation archiviertwird• Pflege einer Versionskontrolle für alle Software Updates• Pflege eines Nachweises über alle Änderungsanfragen• Sicherstellen, dass die Betriebsdokumentation und die Benutzeranweisungenentsprechend geändert werden um geeignet zu bleibenG3.2.4 - TestumgebungEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.1.4 Separation of development, test, and operational facilities.Die Stufe der Aufteilung zwischen Produktions-, Produktionsreferenz- und Testumgebung,welche notwendig ist, um Probleme in der Produktion zu verhindern, müssen im Sicherheitskonzeptdes Betreibers identifiziert und mit angemessenen Maßnahmen umgesetztwerden. Sie sind bis auf das MPLS physisch zu trennen.Die folgenden Punkte MÜSSEN beachtet werden:• Der Umgang mit kryptographischen Identitäten im Testsystem MUSS im Sicherheitskonzeptbeschrieben sein.• Regeln für die Überführung von Software aus dem Entwicklungs- in den ProduktionsstatusMÜSSEN definiert und dokumentiert sein.• Compiler, Editoren und andere Entwicklungs- oder Systemwerkzeuge DÜR-FEN für produktive Systeme nicht im Zugriff liegen.• Die Testumgebung SOLL das Produktionssystem so exakt wie möglich nachbilden.• Benutzer SOLLEN unterschiedliche Benutzerprofile für Produktions- und Testsystemehaben, Menüs SOLLEN entsprechende Identifikationsmeldungendarstellen, um das Risiko von Fehlern zu reduzieren. Auch Kennungen fürgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 694 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturWartungsfirmen und Servicepersonal sind auf beiden Systemen unterschiedlichzu gestalten.• Die folgenden Richtlinien MÜSSEN zum Schutz von Produktivdaten angewendetwerden, wenn diese zu Testzwecken genutzt werden:oooooWenn personenbezogene oder andere sensible Informationen zu Testzweckenverwendet werden, MÜSSEN alle sensiblen Inhalte entfernt oder sostark verändert werden, dass eine Wiedererkennung nicht mehr möglichist.Zugangkontrollverfahren, die auf operativen Anwendungssysteme anwendbarsind, MÜSSEN ebenfalls auf Testanwendungssystemen angewendetwerden.Es MUSS jedes Mal eine gesonderte Genehmigung notwendig sein wennProduktivdaten auf ein Testanwendungssystem kopiert werden.Produktivdaten MÜSSEN sofort von einem Testanwendungssystem gelöschtwerden, nachdem das Testen abgeschlossen wurde;Das Kopieren und Verwenden von Produktivdaten MUSS protokolliert werden.G3.2.5 - BetriebssystemassetsEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.5.4 Use of system utilities (Gebrauch von Systemdienstprogrammen),Ziffer 12.4.1 Control of operational software (Kontrolle von Software in laufendenSystemen) und Ziffer 15.3.2 Protection of system audit tools (Schutz der Systemaudittools).Die Integrität von Betriebssystemassets MUSS durch das Definieren entsprechender Optionenfür den Zugriffsschutz gewährleistet werden. Veränderungen an BetriebssystemassetsMÜSSEN durch regelmäßige Integritätsprüfungen entsprechend des Schutzbedarfesverarbeiteter Datenobjekte erkannt werden. Die Verfahren sind im Sicherheitskonzeptzu dokumentieren.BetriebssystemassetsGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Identifizieren der Sicherheitsanforderungen für BetriebssystemassetsImplementieren der Sicherheitsanforderungen für Betriebssystemassetsüber die Zugriffskontrollsoftware, wobei alle Änderungen durchdas Change Management (Change Control Process) gesteuert werden.DienstbetreiberPPBetriebssystemassetsVerbindlicher Wertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 695 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAktualisierungszugriff aufBetriebssystemassetsLesezugriff auf BetriebssystemassetsAusführung von BetriebssystemassetsNur für im Betriebskonzept ausdrücklich ermächtigteBenutzer.Für alle Benutzer zulässig, es sei denn, dem Benutzerwird hierdurch die Umgehung der SicherheitskontrollenermöglichtDurch alle Benutzer, es sei denn, dem Benutzer wirdhierdurch die Umgehung der Sicherheitskontrollen ermöglichtG3.2.6 - VerschlüsselungEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.5.3 Password management system (Kennwortverwaltungssystem)und Ziffer 12.3.1 Policy on the use of cryptographic controls (Policy für denEinsatz kryptographischer Maßnahmen).Zur Durchführung von Verschlüsselung werden Chiffrierschlüssel verwendet, deren Längeabhängig von den geltenden Sicherheitsanforderungen ist. Bei beiden Verschlüsselungsverfahren(Secret-Key und Public/Private-Key) MÜSSEN Verwaltungsprozesse definiertsein, mit denen die während der Gültigkeitsdauer der Chiffrierschlüssel auszuführendenAktionen (z. B. Erstellung, Verteilung, Validierung, Aktualisierung, Speicherung, Verwendungund Feststellung des Ablaufs der Gültigkeit) verwaltet werden können.Wenn Schlüssel zerstört oder für berechtigte Parteien unzugänglich gemacht werden,MUSS es mit einem Verfahren zur Wiederherstellung der Informationen möglich sein, denSchlüssel und die verschlüsselten Informationen wiederherzustellen, falls nicht andereVorgehensweisen vorgeschrieben werden Die Verfahren MÜSSEN im Betriebskonzeptbeschrieben werden.VerschlüsselungGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Definieren und Bereitstellen der Datenverschlüsselungsanforderungendes spezifischen Dienstes für DienstbetreiberDienstbetreiber gematikPOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Bereitstellen und Unterstützen von Verschlüsselungsprodukten(für Hardware und/oder Software) entsprechend derim vorliegenden Dokument definierten RichtlinienGewährleisten der Sicherheit und Verteilen der ChiffrierschlüsselPPAAgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 696 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDie umzusetzenden Standards bezüglich der Länge der Schüssel und der zulässigen Algorithmensind im Kryptographiekonzept definiert, das von der gematik herausgegebenwird. Darüber hinaus gelten folgende Anforderungen für den Einsatz von Schlüsseln, fallsder Einsatzbereich nicht im Kryptographiekonzept thematisiert wird:VerschlüsselungAktivieren von Verschlüsselungsservices, die als integraler Bestandteilder Betriebssysteme, Subsysteme und Anwendungen implementiertsindGeheime Chiffrierschlüssel (auch als symmetrische oder gemeinsameSchlüssel bezeichnet)Public/Private-Chiffrierschlüsselpaare (auch als asymmetrische oderduale Schlüssel bezeichnet) solange nicht ECC nach Vorgabe desKryptokonzepts eingesetzt werdenChiffrierschlüssel für die Übertragung vertraulicher Daten in öffentlichenNetzwerken, sofern nicht Stromverschlüsselung eingesetzt wirdVerbindlicherWertJaMindestens 128Bit LängeMindestens 1024Bit LängeMindestens 128Bit LängeHinweis: Systeme/Plattformen, die Verschlüsselungsservices unterstützen, sind im Architekturkonzeptaufzuführen.G3.2.7 - Potenziell gefährlicher CodeEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.4.1 Controls against malicious code (Kontrollen gegenbösartigen Code).Um die Verbreitung von potenziell gefährlichem Code zu verhindern, MUSS eine Virenschutzsoftwareverwendet werden, wenn sie für die entsprechenden Systeme verfügbarist.Potenziell gefährlicher CodeGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Bereitstellen und Verwalten von Virenschutzsoftware für verwalteteServerReagieren auf Virenangriffe und Einleiten von Fehlerbehebungsmaßnahmenzur Eliminierung festgestellter Viren auf verwalteten ServernDienstbetreiberPPOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 697 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturIdentifizieren und Implementieren der Sicherheitsanforderungen fürAssets, die sich auf Arbeitsplatzrechnern befindenKontinuierliches Aktualisieren von Signaturdateien für den Virenschutzauf ArbeitsplatzrechnernDurchführen von Selbstprüfungen für alle Datenträger und Arbeitsplatzrechnern,die möglicherweise von einem Virus befallen sindReagieren auf Virenangriffe und Einleiten von Fehlerbehebungsmaßnahmenzur Eliminierung festgestellter Viren auf ArbeitsplatzrechnernPPPPPotenziell gefährlicher CodeScan-Intervall für VirenschutzprogrammAktualität der Version desVirenschutzprogrammsSuchen von neuen Virendefinitionenfür das VirenschutzprogrammVerbindlicher WertMindestens einmal pro Woche:Scan aller Dateien und ObjekteUpdate der Version innerhalb von zwei Monaten ab VerfügbarkeitMindestens einmal täglich, wenn die Daten über dasNetzwerk zugänglich sind. Andernfalls ist mindestenseinmal pro Woche eine manuelle Signaturaktualisierungdurchzuführen.Wenn ein System oder Server mit einem Computervirus infiziert wurde, MUSS der Systemadministratorsich an die zuständige, vom Dienstbetreiber vorgesehene Servicefunktionwenden, um den durch den Virus verursachten Schaden auf ein Minimum zu begrenzen.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 698 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.2.8 - Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtA_03324A_03325A_03326A_03327SSSSTitel Beschreibung Rel. QuelleSchutz_von_Assets_01: Installieren,Pflegen und Erweiternneuer oder vorhandenerSoftware zur Datenzugriffskontrolle.Schutz_von_Assets_02: Implementierender Funktionenund Merkmale der ZugriffskontrollsoftwareSchutz_von_Assets_03: Inventarder AssetsSchutz_von_Assets_04:Nachweis des geordnetenZufluss von Software-Assets.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Installieren, Pflegen und Erweitern neuer oder vorhandener Softwarezur Datenzugriffskontrolle (im Bedarfsfall), sofern Dienstbetreiberden Service für notwendig erachtetGrundlegender Aufgabenbereich(Dienstbetreiber performt):Implementieren der Funktionen und Merkmale der Zugriffskontrollsoftware,die die im vorliegenden Dokument definierten Anforderungendes spezifischen Dienstes in Bezug auf die geltenden SicherheitsverfahrenerfüllenDas Inventar der Assets MUSS alle Informationen enthalten, diezur Wiederherstellung nach einer Katastrophe nötig sind, einschließlichder Art des Assets, Format, Ort, Backup-Informationenund LizenzinformationenDie Betreiber müssen einen geordneten Zufluss von Software-Assets nachweisen können, der die folgenden Anforderungen erfüllenMUSS:• Jegliche Software wird erfasst (Versionsnummer, Updates) –auch Firmware.• Die Quelle der Software ist nachvollziehbar.• Die Authentizität der Quelle oder die Integrität der Software wurdeüberprüft.• Ihre Verwendung wurde prozesskonform freigegeben.• Ihre Verwendung wird dokumentiert.AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 699 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03328A_03329A_03330A_03331A_03332A_03333SSSSSSTitel Beschreibung Rel. QuelleSchutz_von_Assets_05:Nachvollziehbarkeit und Wiederherstellbarkeitvon Konfigurationsdaten.Schutz_von_Assets_06: Dokumentationvon Konfigurationsänderungen.Schutz_von_Assets_07: Klassifizierungvon Datenobjektendurch den Dienstbetreiber.Schutz_von_Assets_08: Verantwortungfür die Klassifizierungvon DatenobjektenSchutz_von_Assets_09: Verantwortungfür die Klassifizierungvon AssetsSchutz_vertraulicher_Informationen_01: Zuständigkeit vonBenutzern und Assetverantwortlichen.Die Software ist zentral beim Betreiber verfügbar solange sie imEinsatz ist und sechs Monate darüber hinaus.Konfigurationsdaten und Softwarestände MÜSSEN über einenZeitraum von 3 Monaten auf Tagesbasis und über einen Zeitraumvon 10 Jahren auf Monatsbasis nachvollziehbar und wieder herstellbarseinZur Beurteilung, ob festgestellte Abweichungen oder Änderungengeplant sind oder einen Sicherheitsvorfall darstellen, MÜSSENKonfigurationsänderungen vollständig dokumentiert sein. DerZugriff muss sowohl chronologisch als auch über den Namen derKomponente jederzeit möglich sein.Klassifizierung von Datenobjekten durch den Dienstbetreiber: NichterforderlichVerantwortung für die Klassifizierung von Datenobjekten: gematikVerantwortlich für die Klassifizierung von Assets: DienstbetreiberBenutzer und Assetverantwortliche MÜSSEN den Schutzbedarfder Informationen bezüglich der Vertraulichkeit berücksichtigenAnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 700 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03334A_03335A_03336A_03337SSSSTitel Beschreibung Rel. QuelleSchutz_vertraulicher_Informationen_02: Feststellen der vonden Systemen/Servern unterstütztenKlassifizierungsstufe.Schutz_vertraulicher_Informationen_03: Information der BenutzerSchutz_vertraulicher_Informationen_04: Verfügbarkeit vonvertraulichen Informationen fürBenutzer.Schutz_vertraulicher_Informationen_05: Durchführung normalerAktivitäten zur Systemunterstützung.A_03338 S Schutz_vertraulicher_Informationen_06: Übertragung vertraulicherDaten über das Internet,öffentliche Netzwerkeoder drahtlose Endgeräte.A_03339 SChange_Management_01:Einbindung aller Assets in dasChange-Management.Optionaler Aufgabenbereich(Dienstbetreiber performt):Feststellen der von den Systemen/Servern unterstützten Klassifizierungsstufebezüglich des Schutzbedarfes der VertraulichkeitOptionaler Aufgabenbereich(Dienstbetreiber performt):Informieren der Benutzer darüber, dass Informationen mit einembestimmten Schutzbedarf nicht mit einem bestimmten System verarbeitetwerden könnenVerfügbarkeit von vertraulichen Informationen für Benutzer:Nur für Benutzer, die aus geschäftlichen Gründen Zugriff benötigenund über eine explizite Berechtigung verfügenDurchführung normaler Aktivitäten zur Systemunterstützung, wiez.B. Systemdatensicherungen :Explizite Zugriffsberechtigung des Eigners der Benutzerressourcewird nicht benötigtÜbertragung vertraulicher Daten über das Internet, öffentlicheNetzwerke oder drahtlose Endgeräte:Verschlüsseln (Verschlüsselungsanforderungen siehe Anhang F)Assets (insbesondere auch Operative Systeme und Anwendungen)MÜSSEN Gegenstand eines strengen Änderungsmanagementssein.:Identifikation und Aufzeichnung aller Änderungen;Planung und Testen von Änderungen;Bewertung der potentiellen Auswirkungen, auch im Hinblick auf dieSicherheit von solchen Änderungen;AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 701 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03340A_03341SSTitel Beschreibung Rel. QuelleChange_Management_02:dentifikation und Aufzeichnungaller Änderungen.Change_Management_03:Planung und Testen von Änderungen.A_03342 S Change_Management_04:Bewertung der potentiellenAuswirkungen, auch im Hinblickauf die Sicherheit vonsolchen ÄnderungenA_03343 SA_03344SChange_Management_05:Formeller Genehmigungsprozessfür ÄnderungenChange_Management_06:Benachrichtigung und Informationaller relevanten Personenüber die Details der Änderung.Formeller Genehmigungsprozess für Änderungen;Benachrichtigung und Information aller relevanten Personen überdie Details der Änderung;Rückfallverfahren, welches die Vorgehensweisen und Verantwortungenfür Abbruch und Wiedererlangung des Ursprungszustandsfür den Fall regelt, dass eine Änderung erfolglos ist oder unvorhergeseheneEreignisse auftreten.Mussanforderung an das Change Management:Identifikation und Aufzeichnung aller Änderungen;Mussanforderung an das Change Management:Planung und Testen von Änderungen;Mussanforderung an das Change Management:Bewertung der potentiellen Auswirkungen, auch im Hinblick auf dieSicherheit von solchen Änderungen;Mussanforderung an das Change Management:Formeller Genehmigungsprozess für Änderungen;Mussanforderung an das Change Management:Benachrichtigung und Information aller relevanten Personen überdie Details der Änderung;AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 702 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03345A_03346SSTitel Beschreibung Rel. QuelleChange_Management_07:Identifikation und Aufzeichnungaller Änderungen.Change_Management_08:Planung und Testen von Änderungen.A_03347 S Change_Management_09:Sicherstellen, dass Änderungennur von durch ihre Rollebefugten Personen eingereichtwerden.A_03348SChange_Management_10:Überprüfung der kontroll- undintegritätssichernden VerfahrenA_03349 S Change_Management_11:Identifikation aller Software,Informationen, Datenbankenund von Hardware die Verbesserungenbenötigen.A_03350 S Change_Management_12:Sicherstellen, dass die gesamteSystemdokumentation beijeder Fertigstellung jeder Änderungaktualisiert wird unddass die alte Dokumentationarchiviert wird.Mussanforderung an das Change Management:Identifikation und Aufzeichnung aller Änderungen;Mussanforderung an das Change Management:Planung und Testen von Änderungen;Sollanforderung an das Change Management:Sicherstellen, dass Änderungen nur von durch ihre Rolle befugtenPersonen eingereicht werdenSollanforderung an das Change Management:Überprüfung der kontroll- und integritätssichernden Verfahren umsicher zu stellen, dass diese nicht durch die Änderung kompromittiertwerdenSollanforderung an das Change Management:Identifikation aller Software, Informationen, Datenbanken und vonHardware die Verbesserungen benötigenSollanforderung an das Change Management:Sicherstellen, dass die gesamte Systemdokumentation bei jederFertigstellung jeder Änderung aktualisiert wird und dass die alteDokumentation archiviert wirdAnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 703 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03351A_03352A_03353A_03354A_03355A_03356SSSSSSTitel Beschreibung Rel. QuelleChange_Management_13:Pflege einer Versionskontrollefür alle Software Updates.Change_Management_14:Pflege eines Nachweises überalle Änderungsanfragen.Change_Management_15:Aktuelle und geeignete Betriebsdokumentationund Benutzeranweisungen.Testumgebung_01: Trennungvon roduktions-, Produktionsreferenz-und Testumgebung.Testumgebung_02: Umgangmit kryptographischen Identitätenim Testsystem.Testumgebung_03: Regeln fürdie Überführung von Softwareaus dem Entwicklungs- in denProduktionsstatus.A_03357 S Testumgebung_04: Entwicklungs-oder SystemwerkzeugeSollanforderung an das Change Management:Pflege einer Versionskontrolle für alle Software UpdatesSollanforderung an das Change Management:Pflege eines Nachweises über alle ÄnderungsanfragenSollanforderung an das Change Management:Sicherstellen, dass die Betriebsdokumentation und die Benutzeranweisungenentsprechend geändert werden um geeignet zu bleibenDie Stufe der Aufteilung zwischen Produktions-, Produktionsreferenz-und Testumgebung, welche notwendig ist, um Probleme inder Produktion zu verhindern, MÜSSEN im Sicherheitskonzept desBetreibers identifiziert und mit angemessenen Maßnahmen umgesetztwerden. Sie sind bis auf das MPLS physisch zu trennen.Der Umgang mit kryptographischen Identitäten im TestsystemMUSS im Sicherheitskonzept beschrieben sein.Regeln für die Überführung von Software aus dem Entwicklungsinden Produktionsstatus MÜSSEN definiert und dokumentiert sein.Compiler, Editoren und andere Entwicklungs- oder SystemwerkzeugeDÜRFEN für produktive Systeme nicht im Zugriff liegen.AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 704 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03358A_03359A_03360A_03361A_03362A_03363SSSSSSTestumgebung_05: Die TestumgebungSOLL das Produktionssystemso exakt wie möglichnachbilden.Testumgebung_06: Benutzerprofileund Menüs in Testumgebungen.Testumgebung_07: Schutzvon Produktivdaten.Testumgebung_08: Nutzungvon personenbezogenen oderanderen sensiblen Informationenzu Testzwecken.Testumgebung_09: Zugangkontrollverfahrenauf Testanwendungssystemen.Testumgebung_10: Genehmigungzur Nutzung von Produktivdatenauf Testsystemen.Die Testumgebung SOLL das Produktionssystem so exakt wiemöglich nachbildenBenutzer SOLLEN unterschiedliche Benutzerprofile für Produktions-und Testsysteme haben, Menüs SOLLEN entsprechendeIdentifikationsmeldungen darstellen, um das Risiko von Fehlern zureduzieren. Auch Kennungen für Wartungsfirmen und Servicepersonalsind auf beiden Systemen unterschiedlich zu gestalten.Die folgenden Richtlinien [ Testumgebung_08 - Testumgebung_12]MÜSSEN zum Schutz von Produktivdaten angewendet werden,wenn diese zu Testzwecken genutzt werdenWenn personenbezogene oder andere sensible Informationen zuTestzwecken verwendet werden, MÜSSEN alle sensiblen Inhalteentfernt oder so stark verändert werden, dass eine Wiedererkennungnicht mehr möglich ist.Zugangkontrollverfahren, die auf operativen Anwendungssystemeanwendbar sind, MÜSSEN ebenfalls auf Testanwendungssystemenangewendet werden.Es MUSS jedes Mal eine gesonderte Genehmigung notwendigsein wenn Produktivdaten auf ein Testanwendungssystem kopiertwerden.AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 705 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03364A_03365A_03366A_03367A_03368A_03369SSSSSSTitel Beschreibung Rel. QuelleTestumgebung_11: Löschungder Produktivdaten vom testsystemunmittelbar nach Testende.Testumgebung_12: Protokollierungdes Transfers von Produktivdatenauf Testsysteme.Betriebsystem_Assets_01:Identifizieren der Sicherheitsanforderungenfür Betriebssystemassets.Betriebsystem_Assets_02:Implementieren der SicherheitsanforderungenfürBetriebssystemassets.Betriebsystem_Assets_03:Aktualisierungszugriff aufBetriebssystemassets.Betriebsystem_Assets_04:Lesezugriff auf BetriebssystemassetsA_03370 S Betriebsystem_Assets_05:Ausführen von Betriebssyste-Produktivdaten MÜSSEN sofort von einem Testanwendungssystemgelöscht werden, nachdem das Testen abgeschlossen wurde;Das Kopieren und Verwenden von Produktivdaten in TestsystemeMUSS protokolliert werden.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Identifizieren der Sicherheitsanforderungen für BetriebssystemassetsGrundlegender Aufgabenbereich(Dienstbetreiber performt):Implementieren der Sicherheitsanforderungen für Betriebssystemassetsüber die Zugriffskontrollsoftware, wobei alle Änderungendurch das Change Management (Change Control Process) gesteuertwerden.Aktualisierungszugriff auf Betriebssystemassets:Nur für im Betriebskonzept ausdrücklich ermächtigte Benutzer.Lesezugriff auf Betriebssystemassets:Für alle Benutzer zulässig, es sei denn, dem Benutzer wird hierdurchdie Umgehung der Sicherheitskontrollen ermöglichtAusführung von Betriebssystemassets:Durch alle Benutzer, es sei denn, dem Benutzer wird hierdurch dieAnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2Anhanggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 706 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellemassets. Umgehung der Sicherheitskontrollen ermöglicht. G 3.2A_03371A_03372A_03373A_03374A_03375SSSSSVerschlüsselung_01: Keymanagementund Schlüssellänge.Verschlüsselung_02:Datenwiederherstellung beizerstörten oder nicht verfügbarenSchlüsseln.Verschlüsselung_03: Definierenund Bereitstellen der Datenverschlüsselungsanforderungen.Verschlüsselung_04: Bereitstellenund Unterstützen vonVerschlüsselungsproduktenVerschlüsselung_05: Gewährleistender Sicherheit und Verteilender Chiffrierschlüssel.Zur Durchführung von Verschlüsselung werden Chiffrierschlüsselverwendet, deren Länge abhängig von den geltenden Sicherheitsanforderungenist. Bei beiden Verschlüsselungsverfahren (Secret-Key und Public/Private-Key) MÜSSEN Verwaltungsprozesse definiertsein, mit denen die während der Gültigkeitsdauer der Chiffrierschlüsselauszuführenden Aktionen (z. B. Erstellung, Verteilung,Validierung, Aktualisierung, Speicherung, Verwendung undFeststellung des Ablaufs der Gültigkeit) verwaltet werden können.Wenn Schlüssel zerstört oder für berechtigte Parteien unzugänglichgemacht werden, MUSS es mit einem Verfahren zur Wiederherstellungder Informationen möglich sein, den Schlüssel und dieverschlüsselten Informationen wiederherzustellen, falls nicht andereVorgehensweisen vorgeschrieben werden Die Verfahren MÜS-SEN im Betriebskonzept beschrieben werdenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Definieren und Bereitstellen der Datenverschlüsselungsanforderungendes spezifischen Dienstes für DienstbetreiberOptionaler Aufgabenbereich(Dienstbetreiber performt):Bereitstellen und Unterstützen von Verschlüsselungsprodukten (fürHardware und/oder Software) entsprechend der im vorliegendenDokument definierten RichtlinienOptionlaer Aufgabenbereich(Dienstbetreiber performt):Gewährleisten der Sicherheit und Verteilen der ChiffrierschlüsselAnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 707 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03376A_03377A_03378SSSTitel Beschreibung Rel. QuelleVerschlüsselung_06: Aktivierenvon VerschlüsselungsservicesVerschlüsselung_07:MindestlängegeheimeChiffrierschlüsselVerschlüsselung_08: Mindestlängevon Public/Private-Chiffrierschlüsselpaaren.A_03379 S Verschlüsselung_09: Mindestlängeder Chiffrierschlüssel fürdie Übertragung vertraulicherDaten in öffentlichen Netzwerken.A_03380 SA_03381A_03382SSGefährlicher_Code_01: Einsatzvon Virenschutzsoftware.Gefährlicher_Code_02: Bereitstellenund Verwalten vonVirenschutzsoftware für verwalteteServer.Gefährlicher_Code_03: Reaktionauf VirenangriffeAktivieren von Verschlüsselungsservices, die als integraler Bestandteilder Betriebssysteme, Subsysteme und Anwendungenimplementiert sind: JaGeheime Chiffrierschlüssel (auch als symmetrische oder gemeinsameSchlüssel bezeichnet) : Mindestens 128 Bit LängePublic/Private-Chiffrierschlüsselpaare (auch als asymmetrischeoder duale Schlüssel bezeichnet) solange nicht ECC nach Vorgabedes Kryptokonzepts eingesetzt werden: Mindestens 1024 BitLängeChiffrierschlüssel für die Übertragung vertraulicher Daten in öffentlichenNetzwerken, sofern nicht Stromverschlüsselung eingesetztwird: Mindestens 128 Bit LängeUm die Verbreitung von potenziell gefährlichem Code zu verhindern,MUSS eine Virenschutzsoftware verwendet werden, wennsie für die entsprechenden Systeme verfügbar ist.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Bereitstellen und Verwalten von Virenschutzsoftware für verwalteteServerGrundlegender Aufgabenbereich(Dienstbetreiber performt):Reagieren auf Virenangriffe und Einleiten von Fehlerbehebungs-AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 708 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03383 S Gefährlicher_Code_04: Identifizierenund Implementierender Sicherheitsanforderungenfür Assets auf Arbeitsplatzrechnern.A_03384A_03385A_03386A_03387A_03388SSSSSGefährlicher_Code_05: KontinuierlichesAktualisieren vonSignaturdateien für den Virenschutz.Gefährlicher_Code_06:Selbstprüfungen auf Arbeitsplatzrechnern.Gefährlicher_Code_07: Einleitenvon Fehlerbehebungsmaßnahmen.Gefährlicher_Code_08: Scan-Intervall für Virenschutzprogramm.Gefährlicher_Code_09: Aktualitätder Version des Virenschutzprogramms.maßnahmen zur Eliminierung festgestellter Viren auf verwaltetenServernIdentifizieren und Implementieren der Sicherheitsanforderungen fürAssets, die sich auf Arbeitsplatzrechnern befindenKontinuierliches Aktualisieren von Signaturdateien für den Virenschutzauf ArbeitsplatzrechnernDurchführen von Selbstprüfungen für alle Datenträger und Arbeitsplatzrechnern,die möglicherweise von einem Virus befallen sindReagieren auf Virenangriffe und Einleiten von Fehlerbehebungsmaßnahmenzur Eliminierung festgestellter Viren auf ArbeitsplatzrechnernScan-Intervall für Virenschutzprogramm:Mindestens einmal pro Woche:Scan aller Dateien und ObjekteAktualität der Version des Virenschutzprogramms:Update der Version innerhalb von zwei Monaten ab VerfügbarkeitAnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 709 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03389STitel Beschreibung Rel. QuelleGefährlicher_Code_10: Suchenvon neuen Virendefinitionenfür das Virenschutzprogramm.Suchen von neuen Virendefinitionen für das Virenschutzprogramm:Mindestens einmal täglich, wenn die Daten über das Netzwerkzugänglich sind. Andernfalls ist mindestens einmal pro Woche einemanuelle Signaturaktualisierung durchzuführen.AnhangG 3.2gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 710 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.3 - System- und SicherheitsadministratorberechtigungEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.2.2.Privilege Management (Verwaltung von Privilegien),Ziffer 11.2.4 Review of user access rights (Überprüfung der Zugriffsrechte von Benutzern)und Ziffer 12.4.1 Control of operational software (Kontrolle von Software in laufenden Systemen).Privilegierte Berechtigungen ermöglichen einem Benutzer die Verwaltung eines Systemsoder Servers. Der Benutzer kann damit Benutzer-IDs definieren oder ändern, die Sicherheitskontrollendes Systems festlegen oder Systemkomponenten ändern. Endbenutzernwerden keine privilegierten Berechtigungen gewährt. Sie werden beschränkt und kontrolliert.Im folgenden Abschnitt wird die Gewährung und Verwaltung der Berechtigungen aufeinem System oder Server beschrieben.Bei den folgenden Berechtigungen handelt es sich um privilegierte Berechtigungen:Systemberechtigung: Die Berechtigung für eine Person durch die Zuordnung von Attributen,Privilegien oder Zugriffsrechten, die für die verwendete Software gelten und die zurAusführung von Systemunterstützungs- und Systemwartungsaufgaben erforderlich sind.Sicherheitsadministratorberechtigung: Die Berechtigung für eine Person durch dieZuordnung von Attributen oder Privilegien, die für bestimmte Zugriffskontrollsysteme geltenund zur Definition und zur Verwaltung systemweiter Sicherheitskontrollen erforderlichsind.Die Anforderungen in Kapitel G 3.3 gelten für die folgenden BereicheEnthalten Alle im Betriebskonzept festgelegten Benutzer mit privilegierten BerechtigungenG3.3.1 - VerwaltungFür die Genehmigung und Gewährung von privilegierten Berechtigungen MUSS ein Prozessimplementiert werden.Verwaltung privilegierter BerechtigungenGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Prüfen neuer Anforderungen für privilegierte BenutzerberechtigungenGenehmigen von Anforderungen für privilegierte BenutzerberechtigungenErteilen von Anforderungen für privilegierte BenutzerberechtigungenDienstbetreiberPPPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 711 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturEntfernen der Berechtigungen, die vom zuständigen Management alsnicht mehr autorisiert identifiziert wurdenPVerwaltung privilegierter BerechtigungenFreigabeverantwortlicher für privilegierte BerechtigungenZuweisung privilegierter BerechtigungenSystem-IDs mit Betriebssystemberechtigung(Servicemaschinen, gestartete Tasks, Agenten,Benutzer-IDs für installierte Systemeusw.)Privilegierte Berechtigungen implementiertdurch Vergabe von GruppenzugriffVerbindlicher WertLeiter der Abteilung, die für die Festlegungund die Aufrechterhaltung der Sicherheitskontrollenauf dem System/Serververantwortlich istGenehmigung vor der Gewährungoderin Übereinstimmung mit der Jobbeschreibung(genehmigt durch den Freigabeverantwortlichenfür privilegierte Berechtigungen)Hinweis: Alle anmeldeberechtigten PersonenMÜSSEN einen gültigen geschäftlichenGrund vorweisen könnenMöglicherweise Zuordnung zu einer bestimmtenAbteilungAlle Mitglieder der Gruppe MÜSSEN einengültigen geschäftlichen Grund vorweisenkönnen und die privilegierte BerechtigungMUSS genehmigt werdenG3.3.2 - ManagementFür die regelmäßige Überprüfung, dass privilegierte Berechtigungen nur autorisierten Benutzerngewährt wurden, MUSS ein Prozess implementiert werden. Dies kann währendder Sicherheitsstatusprüfung geschehen. Ein zweiter, eigenständiger Prozess MUSS alledrei Monate durchgeführt werden, um das Fortbestehen eines geschäftlichen Grundes fürdie erneute Gewährung der früher gewährten privilegierten Berechtigungen erneut zu prüfen.Management privilegierter BerechtigungenGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Prüfen der Zuweisungen privilegierter BerechtigungenErneutes Prüfen des Fortbestehens eines geschäftlichen Grundes fürdie Gewährung privilegierter BerechtigungenKontrollieren und Übernehmen der Verantwortung für die Benutzerprofilevon Sicherheitsbeauftragten/-administratoren auf allen Systemen,DienstbetreiberPPPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 712 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturfür die Dienstbetreiber die Sicherheitsverantwortung übernimmtManagement der Berechtigungen für SystemundSicherheitsadministratorenPrüfen der Zuweisungen privilegierter Berechtigungen,um sicherzustellen, dass nur autorisierteBenutzer über privilegierte Berechtigungen verfügen.Dies umfasst privilegierte Berechtigungen,die explizit oder im Rahmen einer Gruppenzuweisungzugewiesen werden.Erneutes Prüfen der Zuweisungen privilegierterBerechtigungen, um das Fortbestehen eines geschäftlichenGrundes für die jeweiligen Benutzersicherzustellen. Dies umfasst privilegierte Berechtigungen,die explizit oder im Rahmen einerGruppenzuweisung zugewiesen werden.Nachweis für die Durchführung der erneuten Ü-berprüfung privilegierter BerechtigungenVerbindlicher WertWährend der Sicherheitsstatusprüfungalle 3 MonateMindestens zwei abgeschlosseneerneute Überprüfungen für den angegebenenZeitraum aufbewahren undMindestaufbewahrungsdauer 2 Jahregematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 713 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.3.2 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03390 S Administrator_Berechtigung_Verwaltung_01: Prüfen neuer Anforderungenfür privilegierte Benutzerberechtigungen.A_03391 S Administrator_Berechtigung_Verwaltung_02:Genehmigen von Anforderungenfür privilegierte Benutzerberechtigungen.A_03392 S Administrator_Berechtigung_Verwaltung_03: Erteilen von Anforderungenfür privilegierte Benutzerberechtigungen.A_03393 S Administrator_Berechtigung_Verwaltung_04:Entfernen der Berechtigungen.A_03394 S Administrator_Berechtigung_Verwaltung_05: Freigabeverantwortungfür privilegierte Berechtigungen.A_03395 S Administrator_Berechtigung_Verwaltung_06: Zuweisung privilegierterGrundlegender Aufgabenbereich(Dienstbetreiber performt):Prüfen neuer Anforderungen für privilegierte BenutzerberechtigungenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Genehmigen von Anforderungen für privilegierte BenutzerberechtigungenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Erteilen von Anforderungen für privilegierte BenutzerberechtigungenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Entfernen der Berechtigungen, die vom zuständigen Managementals nicht mehr autorisiert identifiziert wurdenFreigabeverantwortlicher für privilegierte Berechtigungen: Leiterder Abteilung, die für die Festlegung und die Aufrechterhaltung derSicherheitskontrollen auf dem System/Server verantwortlich istZuweisung privilegierter Berechtigungen:Genehmigung vor der GewährungoderAnhangG 3.3AnhangG 3.3AnhangG 3.3AnhangG 3.3AnhangG 3.3AnhangG 3.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 714 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleBerechtigungen.A_03396 S Administrator_Berechtigung_Verwaltung_07: System-IDs mit Betriebssystemberechtigung.A_03397 S Administrator_Berechtigung_Verwaltung_08: Privilegierte Berechtigungenimplementiert durch Vergabevon Gruppenzugriff.A_03398 S Administrator_Berechtigung_Management_01: Prüfen der Zuweisungenprivilegierter BerechtigungenA_03399 S Administrator_Berechtigung_Management_02: Erneutes Prüfen desFortbestehens eines geschäftlichenGrundes für die Gewährungprivilegierter Berechtigungen.A_03400 S Administrator_Berechtigung_Management_03: Kontrollieren und Übernehmender Verantwortung fürdie Benutzerprofile.in Übereinstimmung mit der Jobbeschreibung (genehmigt durchden Freigabeverantwortlichen für privilegierte Berechtigungen)Hinweis: Alle anmeldeberechtigten Personen MÜSSEN einen gültigengeschäftlichen Grund vorweisen könnenSystem-IDs mit Betriebssystemberechtigung (Servicemaschinen,gestartete Tasks, Agenten, Benutzer-IDs für installierte Systemeusw.):Möglicherweise Zuordnung zu einer bestimmten AbteilungPrivilegierte Berechtigungen implementiert durch Vergabe vonGruppenzugriff:Alle Mitglieder der Gruppe MÜSSEN einen gültigen geschäftlichenGrund vorweisen können und die privilegierte Berechtigung MUSSgenehmigt werdenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Prüfen der Zuweisungen privilegierter BerechtigungenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Erneutes Prüfen des Fortbestehens eines geschäftlichen Grundesfür die Gewährung privilegierter BerechtigungenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Kontrollieren und Übernehmen der Verantwortung für die Benutzerprofilevon Sicherheitsbeauftragten/-administratoren auf allenSystemen, für die Dienstbetreiber die SicherheitsverantwortungübernimmtAnhangG 3.3AnhangG 3.3AnhangG 3.3AnhangG 3.3AnhangG 3.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 715 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03401 S Administrator_Berechtigung_Management_05: Prüfen der Zuweisungenprivilegierter Berechtigungen.A_03402 S Administrator_Berechtigung_Management_06: Erneutes Prüfen derZuweisungen privilegierterBerechtigungen.A_03403SAdministrator_Berechtigung_Management_07:Nachweis für die Durchführungder erneuten Überprüfung.Prüfen der Zuweisungen privilegierter Berechtigungen, um sicherzustellen,dass nur autorisierte Benutzer über privilegierte Berechtigungenverfügen. Dies umfasst privilegierte Berechtigungen, dieexplizit oder im Rahmen einer Gruppenzuweisung zugewiesenwerden:Während der SicherheitsstatusprüfungErneutes Prüfen der Zuweisungen privilegierter Berechtigungen,um das Fortbestehen eines geschäftlichen Grundes für die jeweiligenBenutzer sicherzustellen. Dies umfasst privilegierte Berechtigungen,die explizit oder im Rahmen einer Gruppenzuweisungzugewiesen werden:alle 3 MonateNachweis für die Durchführung der erneuten Überprüfung privilegierterBerechtigungen:Mindestens zwei abgeschlossene erneute Überprüfungen für denangegebenen Zeitraum aufbewahren und Mindestaufbewahrungsdauer2 JahreAnhangG 3.3AnhangG 3.3AnhangG 3.3gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 716 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.4 - Protokollieren von ZugriffsversuchenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.10.1 Audit Logging (Protokollierung von Überprüfungen),Ziffer 10.10.4 Administrator and operator logs (Administrator- und Bedienerprotokolle) undZiffer 13.2.3 Collection of evidence (Sammeln von Beweisen).Der Grad der notwendigen Überwachung für einzelne Einrichtungen MUSS durch eineRisikobetrachtung festgelegt werden. Eine Organisation MUSS alle relevanten rechtlichenAnforderungen die für seine Überwachung anwendbar sind erfüllen. Die Bereiche die beachtetwerden SOLLEN sind:• Genehmigter Zugang unter Berücksichtigung von:oooooDer Benutzerkennung (ID)Datum und Uhrzeit von relevanten EreignissenEreignistypenZugriff auf DateienProgramme und Werkzeuge die benutzt wurden• Alle privilegierten Operationen wie:oooNutzung privilegierter Benutzerkonten wie z. B. Supervisor, Root, AdministratorSystem Start und StopAnschließen und Entfernen von Ein-/Ausgabegeräten• Unbefugte Zugriffsversuche wie:oooofehlgeschlagene oder zurückgewiesene Benutzeraktionenfehlgeschlagene oder zurückgewiesene Aktionen die mit Daten und anderenRessourcen in Zusammenhang stehenVerletzungen der Zugriffspolicy und Benachrichtigungen von Netzwerkübergängenund FirewallsAlarme von proprietären Einbruchmeldesystemen (IDS)• Systemalarme und Fehler wie:ooooKonsolen Alarme und MeldungenAusnahmen im SystemprotokollAlarme des NetzwerkmanagementsAlarme die von dem Zugangskontrollsystem herrührengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 717 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Änderungen oder der Versuch von Änderungen an den Sicherheitseinstellungendes Systems oder an dessen Sicherheitsmaßnahmen.Protokolldaten müssen vor Veränderung und Löschung geschützt werdenWie in den folgenden Abschnitten ausgeführt, MÜSSEN die Protokollsätze, die den Zugriffauf Systeme, Assets oder ausgewählte Funktionen dokumentieren, aufbewahrt werden.Hierdurch wird sichergestellt, dass die darin enthaltenen Informationen zu Prüfzweckenoder bei der Untersuchung nicht autorisierter Zugriffsoperationen zur Verfügung stehen.Prüfprotokolle SOLLEN, sofern relevant, die folgenden Elemente beinhalten:• Benutzerkennung• Datum, Uhrzeit, Details von Schlüsselereignissen wie An- und Abmeldung• Terminal Identifikation und Ort• Aufzeichnungen von erfolgreichen und zurückgewiesenen Zugriffsversuchenauf Daten und Ressourcen• Änderungen der Systemkonfiguration• Nutzung von Systemwerkzeugen und Anwendungen• Zugriff auf Dateien und die Art des Zugriffs• Netzwerkadressen und Protokolle• Alarmierungen durch das Zugriffskontrollsystem• Aktivierung und Deaktivierung von Schutzsystemen wie Virenscannern undEinbruchmeldesystemen (IDS)Protokollieren von ZugriffsversuchenGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Aufzeichnen und Verwalten von Zugriffsprotokollen für einen gemeinsamvereinbarten Zeitraum und Bereitstellen von Berichten zur Aufbewahrungdieser Protokolle für den Projektverantwortlichen des spezifischenDienstes auf entsprechende Anforderung hinDienstbetreiberPProtokollieren von ZugriffsversuchenAufbewahrungszeitraum für ProtokollsätzeVerbindlicher Wert2 JahreG3.4.1 - Protokollieren von Systemzugriffen und Aktivitäten von Systemadministratoren undBetreibernAktivitäten von Systemadministratoren und Betreibern SOLLEN protokolliert werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 718 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDiese Protokolle SOLLEN beinhalten:• Die Zeit zu der ein Ereignis (Erfolg oder Fehlschlag) stattfand• Informationen über das Ereignis (z. B. welche Dateien bearbeitet wurden) o-der das Versagen (z. B. welcher Fehler sich ereignete und was dagegen unternommenwurde)• Welches Benutzerkonto und welcher Administrator oder Betreiber beteiligt war• Welche Prozesse beteiligt waren.Die Protokolldateien von Systemadministratoren oder Betreibern SOLLEN regelmäßigkontrolliert werden.Ein IDS, das außerhalb der Kontrolle von System- und Netzwerkadministratoren steht,kann dazu genutzt werden die Aktivitäten von System und Netzwerkadministration auf dieBefolgung der Vorschriften zu überprüfen.Protokollieren von SystemzugriffenAnmeldeversucheVerbindlicher WertAlle erfolgreichen und fehlgeschlagenen VersucheG3.4.2 - Protokollieren von AssetszugriffenProtokollieren von AssetszugriffenProtokollieren des Zugriffs auf BenutzerassetsProtokollieren der Aktualisierungszugriffe auf OSR 65 s, dienicht als Ausnahme aufgeführt sindProtokollieren der Lesezugriffe auf OSRs, die als potenziellerRisikofaktor für die Umgehung der Systemsicherheitseinrichtungenaufgeführt sind 66Protokollieren der Lesezugriffe auf OSRs, die nicht als potenziellerRisikofaktor für die Umgehung der Systemsicherheitseinrichtungenaufgeführt sindProtokollieren der Ausführungsversuche auf OSRs, die alspotenzieller Risikofaktor für die Umgehung der Systemsicherheitseinrichtungenaufgeführt sindProtokollieren der Ausführungsversuche auf OSRs, die nichtals potenzieller Risikofaktor für die Umgehung der Systemsicherheitseinrichtungenaufgeführt sindVerbindlicher WertGemäß Definition desVerantwortlichenAlle erfolgreichen undfehlgeschlagenenZugriffsversucheAlle erfolgreichen undfehlgeschlagenenZugriffsversucheNicht erforderlichAlle erfolgreichen undfehlgeschlagenenZugriffsversucheNicht erforderlich65 Operation System Ressource66 Gemäß den entsprechenden Festlegungen im Sicherheitskonzept und im Betriebskonzept.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 719 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.4.3 - Protokollieren von AktivitätenProtokollieren von AktivitätenSicherheitsadministrator- oder SystemberechtigungVerbindlicher WertProtokollieren von Befehlen zum Ändern vonOSRs und des SicherheitsstatusG3.4.4 - Protokollieren von NetzwerkaktivitätenProtokollieren von NetzwerkaktivitätenZugriff durch erfolgreiche Zuordnungeiner Netzwerk-IP-AdresseVerbindlicher WertProtokollieren von Datum und Uhrzeit der Zuordnung,IP-Adresse, zugehöriger MAC-Adresse, Domänennameund Hostnamegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 720 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.4.5 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03404 S Protokoll_Zugriffsversuche_01:Grad der notwendigen Überwachungwird durch Risikobertrachtungfestgelegt.Der Grad der notwendigen Überwachung für einzelne EinrichtungenMUSS durch eine Risikobetrachtung festgelegt werden. EineOrganisation MUSS alle relevanten rechtlichen Anforderungen diefür seine Überwachung anwendbar sind erfüllen. Die Bereiche diebeachtet werden SOLLEN sind:• Genehmigter Zugang unter Berücksichtigung von:• Der Benutzerkennung (ID)• Datum und Uhrzeit von relevanten Ereignissen• Ereignistypen• Zugriff auf Dateien• Programme und Werkzeuge die benutzt wurden• Alle privilegierten Operationen wie:• Nutzung privilegierter Benutzerkonten wie z. B. Supervisor, Root,Administrator• System Start und Stop• Anschließen und Entfernen von Ein-/Ausgabegeräten• Unbefugte Zugriffsversuche wie:• fehlgeschlagene oder zurückgewiesene Benutzeraktionen• fehlgeschlagene oder zurückgewiesene Aktionen die mit Datenund anderen Ressourcen in Zusammenhang stehen• Verletzungen der Zugriffspolicy und Benachrichtigungen vonNetzwerkübergängen und Firewalls• Alarme von proprietären Einbruchmeldesystemen (IDS)• Systemalarme und Fehler wie:• Konsolen Alarme und MeldungenAnhangG3.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 721 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03405 S Protokoll_Zugriffsversuche_02:Protokolldatenmüssen vor Veränderungund Löschung geschütztwerden.A_03406 S Protokoll_Zugriffsversuche_03:Aufbewahrung von Protokollen.A_03407 S Protokoll_Zugriffsversuche_04:Inhaltder Prüfprotokolle.• Ausnahmen im Systemprotokoll• Alarme des Netzwerkmanagements• Alarme die von dem Zugangskontrollsystem herrühren• Änderungen oder der Versuch von Änderungen an den Sicherheitseinstellungendes Systems oder an dessen Sicherheitsmaßnahmen.Protokolldaten müssen vor Veränderung und Löschung geschütztwerdenProtokollsätze, die den Zugriff auf Systeme, Assets oder ausgewählteFunktionen dokumentieren, MÜSSEN aufbewahrt werden.Prüfprotokolle SOLLEN, sofern relevant, die folgenden Elementebeinhalten:• Benutzerkennung• Datum, Uhrzeit, Details von Schlüsselereignissen wie An- undAbmeldung• Terminal Identifikation und Ort• Aufzeichnungen von erfolgreichen und zurückgewiesenenZugriffsversuchen auf Daten und Ressourcen• Änderungen der Systemkonfiguration• Nutzung von Systemwerkzeugen und Anwendungen• Zugriff auf Dateien und die Art des Zugriffs• Netzwerkadressen und Protokolle• Alarmierungen durch das Zugriffskontrollsystem• Aktivierung und Deaktivierung von Schutzsystemen wie Virenscannernund Einbruchmeldesystemen (IDS)AnhangG3.4AnhangG3.4AnhangG3.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 722 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03408 S Protokoll_Zugriffsversuche_05:Aufzeichnenund Verwalten vonZugriffsprotokollenA_03409 S Protokoll_Zugriffsversuche_06:Aufbewahrungszeitraum fürProtokollsätze.A_03410 S Protokoll_Administrator_Zugriffe_01: Aktivitäten von Systemadministratorenund Betreibern.A_03411 S Protokoll_Administrator_Zugriffe_02: Regelmäßige Kontrolle derProtokolldateien.A_03412 S Protokoll_Administrator_Zugriffe_03: Einsatz von IDS.Grundlegender Aufgabenbereich(Dienstbetreiber performt):Aufzeichnen und Verwalten von Zugriffsprotokollen für einen gemeinsamvereinbarten Zeitraum und Bereitstellen von Berichtenzur Aufbewahrung dieser Protokolle für den Projektverantwortlichendes spezifischen Dienstes auf entsprechende AnforderunghinAufbewahrungszeitraum für Protokollsätze: 2 JahreAktivitäten von Systemadministratoren und Betreibern SOLLENprotokolliert werdenDiese Protokolle SOLLEN beinhalten:• Die Zeit zu der ein Ereignis (Erfolg oder Fehlschlag) stattfand• Informationen über das Ereignis (z. B. welche Dateien bearbeitetwurden) oder das Versagen (z. B. welcher Fehler sich ereigneteund was dagegen unternommen wurde)• Welches Benutzerkonto und welcher Administrator oder Betreiberbeteiligt war• Welche Prozesse beteiligt waren.Die Protokolldateien von Systemadministratoren oder BetreibernSOLLEN regelmäßig kontrolliert werdenEin IDS, das außerhalb der Kontrolle von System- und Netzwerkadministratorensteht, kann dazu genutzt werden die Aktivitätenvon System und Netzwerkadministration auf die Befolgung derVorschriften zu überprüfenAnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 723 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03413 S Protokoll_Administrator_Zugriffe_04: Protokollierung von Anmeldeversuchen.A_03414 S Protokoll_Asset_Zugriffe_01:Protokollierung des Zugriffsauf BenutzerassetsA_03415 S Protokoll_Asset_Zugriffe_02:Protokollierung der Aktualisierungszugriffeauf OSRs.A_03416 S Protokoll_Asset_Zugriffe_03:Protokollieren der Lesezugriffeauf OSRs (potenzieller Risikofaktor)A_03417 S Protokoll_Asset_Zugriffe_04:Protokollieren der Lesezugriffeauf OSRs (kein potenziellerRisikofaktor).A_03418 S Protokoll_Asset_Zugriffe_05:Protokollieren der Ausführungsversucheauf OSRs (potenziellerRisikofaktor)A_03419 S Protokoll_Asset_Zugriffe_06(kein potenzieller Risikofaktor)einrichtungen aufgeführt sind: Nicht erforderlichSicherheitsadministrator- oder Systemberechtigung:Protokollieren von Befehlen zum Ändern von OSRs und des SicherheitsstatusA_03420 S Protokoll_Aktivitäten_01: Protokollierenvon Befehlen zumÄndern von OSRs und desSicherheitsstatusA_03421Protokoll_Netzwerk_Aktivitäten_01:SProtokollierung von Anmeldeversuchen: Alle erfolgreichen undfehlgeschlagenen VersucheProtokollierung des Zugriffs auf Benutzerassets:Gemäß Definition des VerantwortlichenProtokollierung der Aktualisierungszugriffe auf OSRs [OperationSystem Ressource], die nicht als Ausnahme aufgeführt sind:Alle erfolgreichen und fehlgeschlagenen ZugriffsversucheProtokollieren der Lesezugriffe auf OSRs, die als potenzieller Risikofaktorfür die Umgehung der Systemsicherheitseinrichtungenaufgeführt sind: Alle erfolgreichen und fehlgeschlagenen ZugriffsversucheProtokollieren der Lesezugriffe auf OSRs, die nicht als potenziellerRisikofaktor für die Umgehung der Systemsicherheitseinrichtungenaufgeführt sind: Nicht erforderlichProtokollieren der Ausführungsversuche auf OSRs, die als potenziellerRisikofaktor für die Umgehung der Systemsicherheitseinrichtungenaufgeführt sind: Alle erfolgreichen und fehlgeschlagenenZugriffsversucheProtokollieren der Ausführungsversuche auf OSRs, die nicht alspotenzieller Risikofaktor für die Umgehung der Systemsicherheits-Zugriff durch erfolgreiche Zuordnung einer Netzwerk-IP-Adresse:Protokollieren von Datum und Uhrzeit der Zuordnung, IP-Adresse,AnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4AnhangG3.4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 724 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleZugriff durch erfolgreiche Zuordnungeiner Netzwerk-IP-Adressezugehöriger MAC-Adresse, Domänen-name und Hostnamegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 725 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.5 Melden von ZugriffsverletzungenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.10.2 Monitoring system use (Kontrolle der Systembenutzung).G3.5.1 - Ungültige AnmeldungenFür die Bereitstellung von Berichten zu ungültigen Anmeldeversuchen MUSS ein Prozessdefiniert werden. 67Ungültige AnmeldungenOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Bereitstellen von Berichten zu ungültigen AnmeldeversuchenDienstbetreiberPUngültige AnmeldungenVerfügbarkeit von BerichtenVerbindlicher WertAuf Anforderung67 Details zum Prozess der unmittelbaren Alarmmeldung finden sich in „Spezifikation Fehler-und Alertmanagement“ in der Version 0.0.50 [gemSpec_FM].gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 726 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG3.5.2 – Zusammenfassung der AusgangsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_03422A_03423A_03424SSGrundlegender Aufgabenbereich(Dienstbetreiber performt):Bereitstellen von Berichten zu ungültigen AnmeldeversuchenVerfügbarkeit von Berichten: Auf AnforderungReport_Ungültige_Anmeldung_01:Prozess zur Bereitstellung vonBerichten zu ungültigen Anmeldeversuchen.Report_Ungültige_Anmeldung_02:Bereitstellen von Berichten zuungültigen AnmeldeversuchenReport_Ungültige_Anmeldung_03:Verfügbarkeit von BerichtenFür die Bereitstellung von Berichten zu ungültigen AnmeldeversuchenMUSS ein Prozess definiert werden Anhang G3.5Anhang G3.5Anhang G3.5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 727 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG4 - SicherheitsstatusprüfungAlle Systeme MÜSSEN in periodischen Zeitabständen auf ihren Sicherheitsstatus überprüftwerden. Alle Abweichungen von den erwarteten oder erforderlichen Werten, diewährend der Prüfung des Sicherheitsstatus festgestellt werden, MÜSSEN entsprechendder in den folgenden Abschnitten aufgeführten Informationen korrigiert, und dokumentiertwerden.G4.1 - SicherheitsstatusprüfungEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.2.4 Review of user access rights (Überprüfung derZugriffsrechte von Benutzern) und 15.2.2 Technical compliance checking (Prüfung undEinhaltung technischer Normen).Die Sicherheitsstatusprüfung MUSS in periodischen Zeitabständen durchgeführt werden,um den Sicherheitsstatus des Systems festzustellen.SicherheitsstatusprüfungGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Durchführen von Sicherheitsstatusprüfungen des SystemsDurchführen entsprechender Maßnahmen beim Auftreten von AbweichungenDienstbetreiberPPSicherheitsstatusprüfungIntervall für ProduktivsystemeIntervall für alle anderen SystemeOptionen für das ZugriffskontrollsystemSicherheitsadministrator- undSystemberechtigungOSR-ZugriffskontrollenZugriffsberechtigungslisten fürOSRsProgramme zur Feststellung vonpotenziell gefährlichem CodeZugriffs- und AktivitätenprotokolleNachweise für die Durchführungder SicherheitsstatusprüfungVerbindlicher WertVierteljährlichHalbjährlichPrüfen der Übereinstimmung mit den Anweisungenim BetriebskonzeptÜberprüfen, ob ausschließlich autorisierte Benutzerdie Berechtigung habenÜberprüfen der Übereinstimmung mit den Anweisungenim BetriebskonzeptÜberprüfen, ob nur autorisierte Benutzer innerhalbder Liste über Berechtigungen verfügen, die über dievon Endbenutzern hinausgehenPrüfen der Installation und Funktionsfähigkeit dererforderlichen ProgrammePrüfen der Verfügbarkeit der ProtokolleAufbewahrungsfrist beträgt zwei Jahregematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 728 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbweichungen bei der SicherheitsstatusprüfungZeitfenster für KorrekturenMeldung an die gematik entsprechend der Vorgabenin der Dokumentation zum Alarmmanagement , dassdiese Abweichungen nicht innerhalb der vorgesehenenZeit korrigiert werden könnenProduktivsysteme – 3 WerktageAlle sonstigen Systeme – 45 WerktageG4.2 - Überprüfen der SystemaktivitätDas Management des Dienstbetreibers sowie der Sicherheitsbeauftragte der gematik unddie zuständigen Prüffunktionen haben das Recht, alle Aufzeichnungen zur Systemaktivitätzu prüfen. Dieses Recht wird insbesondere in Anspruch genommen um möglichen Hinweisenauf einen Missbrauch der vergebenen Berechtigungen nachzugehen.G4.3 - Missbrauch von BerechtigungenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 8.2.3 Disciplinary process (Disziplinarverfahren).Personen, denen Sicherheits- oder Systemadministratorberechtigungen gewährt wurden,erhalten vom zuständigen Management eine Vertrauensposition. Diese Vertrauenspositionist jedoch nicht mit dem Einverständnis des Managements gleichzusetzen, die vorhandenenAssets für andere als die definierten Geschäftszwecke einzusetzen. Der Missbrauchvergebener Berechtigungen stellt eine Verletzung des in eine Person gesetztenVertrauens dar, die nicht toleriert werden kann.Das zuständige Management MUSS geeignete Maßnahmen ergreifen, wenn als Ursacheeiner Abweichung der Missbrauch vergebener Berechtigungen identifiziert wird.Missbrauch von BerechtigungenGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Management, das die geeigneten Maßnahmen einleitet,wenn der Missbrauch der vergebenen Berechtigungen voneinem Dritten begangen wurdeManagement, das die geeigneten Maßnahmen einleitet,wenn der Missbrauch der vergebenen Berechtigungen voneinem Mitarbeiter des Dienstanbieters begangen wurdeDienstbetreiber gematikPPMissbrauch von BerechtigungenVerbindlicher Wertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 729 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturPersonen, die benachrichtigt werden MÜSSEN,wenn bei der Sicherheitsstatusprüfung ein schwerwiegendesSicherheitsproblem mit vermutlichemBerechtigungsmissbrauch festgestellt wirdSicherheitsbeauftragte des Dienstbetreibersund Sicherheitsbeauftragterder gematik.G4.4 - Unterstützung für externe AuditsEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 15.3.1 Information systems audit controls (Kontrollen für dieÜberprüfung von IT-Systemen).Audits werden von der gematik selbst oder durch Dritte im Auftrag der gematik durchgeführt.Der Umfang eines Audits ist variabel und kann z. B. die IT-Sicherheit oder Geschäftsregelnumfassen.Unterstützung für externe AuditsGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Dienstbetreiber gematikEinrichten einer dienstspezifischen Auditstelle für die Definitionvon Auditregeln und für die Koordinierung der vomDienstbetreiber selbst und von der gematik initiierten Auditaktivitäten.Unterstützen der Auditaktivitäten der gematik, z. B. durchDatensammlung, Installation von Audittools und Erstellungvon BerichtenEntwickeln und Implementieren von Aktionsplänen seitensdes Dienstbetreibers für alle Auditresultate, die nicht mit denSpezifikationen im vorliegenden Dokument oder im VertragübereinstimmenOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert))Einrichten einer zentralen Auditstelle für die Definition vonAuditregeln und für die Koordinierung sämtlicher AuditaktivitätenUnterstützen sämtlicher Auditaktivitäten, z. B. durch Datensammlung,Installation von Audittools und Erstellung vonBerichtenPPPAPAAPAgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 730 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG4.4 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtA_03425STitel Beschreibung Rel. QuellePrüfung_Sicherheitsstatus_01:Periodische Überprüfung desSicherheitsstatus.A_03426 S Prüfung_Sicherheitsstatus_02:Durchführen von Sicherheitsstatusprüfungendes Systems.A_03427 S Prüfung_Sicherheitsstatus_03:Durchführen entsprechenderMaßnahmen beim Auftretenvon AbweichungenA_03428 S Prüfung_Sicherheitsstatus_04:Intervall für ProduktivsystemeA_03429 S Prüfung_Sicherheitsstatus_05:Intervall für alle anderen SystemeA_03430 S Prüfung_Sicherheitsstatus_06:Zugriffskontrollsystem:A_03431 S Prüfung_Sicherheitsstatus_07:Sicherheitsadministrator- undSystemberechtigungAlle Systeme MÜSSEN in periodischen Zeitabständen auf ihrenSicherheitsstatus überprüft werden. Alle Abweichungen von denerwarteten oder erforderlichen Werten, die während der Prüfungdes Sicherheitsstatus festgestellt werden, MÜSSEN entsprechendder in den folgenden Abschnitten aufgeführten Informationen korrigiert,und dokumentiert werdenGrundlegender Aufgabenbereich(Dienstbetreiber performt):Durchführen von Sicherheitsstatusprüfungen des SystemsGrundlegender Aufgabenbereich(Dienstbetreiber performt):Durchführen entsprechender Maßnahmen beim Auftreten von AbweichungenIntervall für Produktivsysteme : VierteljährlichIntervall für alle anderen Systeme: HalbjährlichOptionen für das Zugriffskontrollsystem: Prüfen der Übereinstimmungmit den Anweisungen im BetriebskonzeptSicherheitsadministrator- und Systemberechtigung: Überprüfen, obausschließlich autorisierte Benutzer die Berechtigung habenAnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 731 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03432 S Prüfung_Sicherheitsstatus_08:OSR-ZugriffskontrollenA_03433 S Prüfung_Sicherheitsstatus_09:Zugriffsberechtigungslisten fürOSRsA_03434 S Prüfung_Sicherheitsstatus_10:Programme zur Feststellungvon potenziell gefährlichemCodeA_03435 S Prüfung_Sicherheitsstatus_11:Zugriffs- und Aktivitätenprotokolle.A_03436 S Prüfung_Sicherheitsstatus_12:Nachweise für die Durchführungder SicherheitsstatusprüfungA_03437 S Prüfung_Sicherheitsstatus_13:Abweichungen bei der Sicherheitsstatusprüfung:A_03438 S Prüfung_Sicherheitsstatus_14:Zeitfenster für KorrekturenA_03439 S Prüfung_Systemaktivität_01:Prüfrecht der Aufzeichnungenzur Systemaktivität.OSR-Zugriffskontrollen : Überprüfen der Übereinstimmung mit denAnweisungen im BetriebskonzeptZugriffsberechtigungslisten für OSRs : Überprüfen, ob nur autorisierteBenutzer innerhalb der Liste über Berechtigungen verfügen,die über die von Endbenutzern hinausgehenProgramme zur Feststellung von potenziell gefährlichem Code:Prüfen der Installation und Funktionsfähigkeit der erforderlichenProgrammeZugriffs- und Aktivitätenprotokolle : Prüfen der Verfügbarkeit derProtokolleNachweise für die Durchführung der Sicherheitsstatusprüfung :Aufbewahrungsfrist beträgt zwei JahreAbweichungen bei der Sicherheitsstatusprüfung: Meldung an diegematik entsprechend der Vorgaben in der Dokumentation zumAlarmmanagement , dass diese Abweichungen nicht innerhalb dervorgesehenen Zeit korrigiert werden könnenZeitfenster für Korrekturen: Produktivsysteme – 3 WerktageAlle sonstigen Systeme – 45 WerktageDas Management des Dienstbetreibers sowie der Sicherheitsbeauftragteder gematik und die zuständigen Prüffunktionen MÜS-SEN das Recht haben, alle Aufzeichnungen zur Systemaktivität zuprüfen. Dieses Recht wird insbesondere in Anspruch genommenum möglichen Hinweisen auf einen Missbrauch der vergebenenBerechtigungen nachzugehenAnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 732 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03440 S Missbrauch_Berechtigungen_01:Sicherheits- oder Systemadministratorberechtigungen.A_03441 S Missbrauch_Berechtigungen_02:Einleitung geeigneter Maßnahmenbei MißbrauchdurchDritte.A_03442 S Missbrauch_Berechtigungen_03:Einleitung geeigneter Maßnahmenbei Mißbrauch durchMitarbeiter des Dienstanbieters.A_03443 S Missbrauch_Berechtigungen_04:Benachrichtigung bei Berechtigungsmissbrauch.A_03444 S Unterstützung_externer_Audits_01:Audits durch gematik.Personen, denen Sicherheits- oder Systemadministratorberechtigungengewährt wurden, erhalten vom zuständigen Managementeine Vertrauensposition. Diese Vertrauensposition ist jedoch nichtmit dem Einverständnis des Managements gleichzusetzen, dievorhandenen Assets für andere als die definierten Geschäftszweckeeinzusetzen. Der Missbrauch vergebener Berechtigungen stellteine Verletzung des in eine Person gesetzten Vertrauens dar, dienicht toleriert werden kann.Das zuständige Management MUSS geeignete Maßnahmen ergreifen,wenn als Ursache einer Abweichung der Missbrauch vergebenerBerechtigungen identifiziert wird.Grundlegender Aufgabenbereich(gematik performt):Management, das die geeigneten Maßnahmen einleitet, wenn derMissbrauch der vergebenen Berechtigungen von einem Drittenbegangen wurdeGrundlegender Aufgabenbereich(Dienstbetreiber performt):Management, das die geeigneten Maßnahmen einleitet, wenn derMissbrauch der vergebenen Berechtigungen von einem Mitarbeiterdes Dienstanbieters begangen wurdePersonen, die benachrichtigt werden MÜSSEN, wenn bei der Sicherheitsstatusprüfungein schwerwiegendes Sicherheitsproblemmit vermutlichem Berechtigungsmissbrauch festgestellt wird:Sicherheitsbeauftragte des Dienstbetreibers und Sicherheitsbeauftragterder gematik.Auditrecht für gematik:Audits werden von der gematik selbst oder durch Dritte im Auftragder gematik durchgeführt. Der Umfang eines Audits ist variabelund kann z. B. die IT-Sicherheit oder Geschäftsregeln umfassenAnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 733 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03445 S Unterstützung_externer_Audits_02:Einrichten einer dienstspezifischenAuditstelle.A_03446 S Unterstützung_externer_Audits_03:Unterstützen der Auditaktivitätender gematik.A_03447 S Unterstützung_externer_Audits_04:Entwickeln und Implementierenvon Aktionsplänen.A_03448 S Unterstützung_externer_Audits_05:Einrichten einer zentralen Auditstelle.A_03449SUnterstützung_externer_Audits_06:Unterstützen sämtlicher Auditaktivitäten.Grundlegender Aufgabenbereich(Dienstbetreiber: performt,gematik: assistiert):Einrichten einer dienstspezifischen Auditstelle für die Definition vonAuditregeln und für die Koordinierung der vom Dienstbetreiberselbst und von der gematik initiierten AuditaktivitätenGrundlegender Aufgabenbereich(Dienstbetreiber: performt):Unterstützen der Auditaktivitäten der gematik, z. B. durch Datensammlung,Installation von Audittools und Erstellung von BerichtenGrundlegender Aufgabenbereich(Dienstbetreiber: performt,gematik: assistiert):Entwickeln und Implementieren von Aktionsplänen seitens desDienstbetreibers für alle Auditresultate, die nicht mit den Spezifikationenim vorliegenden Dokument oder im Vertrag übereinstimmenOptionaler Aufgabenbereich(Dienstbetreiber:assistiert ,gematik: performt):Einrichten einer zentralen Auditstelle für die Definition von Auditregelnund für die Koordinierung sämtlicher AuditaktivitätenOptionaler Aufgabenbereich(Dienstbetreiber: performt,gematik: assistiert):Unterstützen sämtlicher Auditaktivitäten, z. B. durch Datensammlung,Installation von Audittools und Erstellung von BerichtenAnhangG 4AnhangG 4AnhangG 4AnhangG 4AnhangG 4gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 734 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG5- Wechselmedien und DatensicherungEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.7 Media Handling (Umgang mit Datenträgern).Speichermedien umfassen Magnetbänder sowie auswechselbare und nicht auswechselbareoptische oder magnetische Platten und Kassetten. Als Speichermedienverwalterbezeichnet man eine Person, die für die Aufbewahrung von Wechselmedien für anderePersonen verantwortlich ist.Im Rahmen des vorliegenden Kapitels gelten die folgenden Definitionen:• Sicherungsmedien: Medien, die reguläre System-/Datensicherungen enthaltenund ausschließlich für die Wiederherstellung und Sicherung verwendetwerden.• Herstellermedien: Medien, die von Software- und Hardwarelieferanten zurVerteilung ihrer Produkte verwendet werden.• Archivierungsmedien: Sonstige Wechselmedien, bei denen es sich wederum Sicherungs- noch um Herstellermedien handelt. In der Regel enthalten sievon Anwendungen erzeugte/verwendete Daten.WechselmedienGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)SpeichermedienverwalterDienstbetreiberPG5.1 - SpeichermedienetikettenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 7.2.2 Information labelling and handling (Kennzeichnung undBehandlung von Informationen).Auf der Oberfläche von Wechselmedien KÖNNEN Etiketten in geeigneter Form angebrachtwerden, die Informationen zum Eigner des Speichermediums sowie zur Klassifizierungder darauf enthaltenen Daten angeben.SpeichermedienetikettenVerbindlicherWertgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 735 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturExterne Etiketten mit einer Eigentümerangabe oder Informationenzur KlassifizierungNicht erforderlichG5.2 - Physischer Schutz von SpeichermedienEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.8.3 Physical media in transit (Physische Speichermedienbeim Transport).Physischer Schutz von SpeichermedienGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Bereitstellen sicherer Aufbewahrungsmöglichkeiten für WechselmedienDienstbetreiberPPhysischer Schutz von SpeichermedienAufbewahren von Sicherungs-, Hersteller-und ArchivierungsmedienAbschließen von Bandlaufwerken undMedieneinheiten (z. B. Bandroboter,Direktzugriffsspeicher-Jukeboxes)Verbindlicher WertAufbewahrung entsprechend dem Schutzbedarfder gespeicherten Datenobjekte:οοin geschützten oder kontrollierten Sicherheitsbereichenin einem Büroraum bzw. Schrank, derverschlossen ist, wenn die Beaufsichtigungnicht gewährleistet istAbschließen nicht erforderlich, wenn sich dieEinheiten in einem geschützten oder kontrolliertenSicherheitsbereich bzw. in einem Büroraumbefinden, der abgeschlossen ist, wenn dieBeaufsichtigung nicht gewährleistet istSicherungs- und Herstellermedien(unbeschriebene Medien)Verlagern von Sicherungs- und Archivierungsmedienvon und zu einer autorisiertenSpeichermedien-AufbewahrungseinrichtungEinlegen von Sicherungs- und Archivierungsmedienin die entsprechendenLaufwerkeAufbewahrung in einem Büroraum bzw. Schrankdes für die Verwaltung zuständigen Mitarbeitersder verschlossen ist, wenn die Beaufsichtigungnicht gewährleistet istNachweis MUSS über Lieferbelege oder einegleichwertige Methode erbracht werdenBei der Durchführung MUSS gewährleistet sein,dass keine nicht autorisierten Zugriffs- und Einlegeoperationendurchgeführt werdengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 736 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG5.3 - Bestandskontrolle für ArchivierungsmedienEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 7.1.1 Inventory of assets (Inventar der Werte).Übernahme von Archivierungsmedien zu Beginn des Betriebes:Wenn der Dienstbetreiber die Verantwortung für die Verwaltung einer Bandbibliothek desAuftraggebers übernimmt, wird als erstes in Zusammenarbeit mit dem Auftraggeber eineBestandsaufnahme durchgeführt. Die vollständige Bestandsaufnahme der Wechselmedien(einschließlich der zugehörigen Dokumentation) MUSS von beiden Parteien freigegeben,dokumentiert, unterzeichnet und für die Dauer des Vertrags (oder für die im Vertragangegebene Zeitdauer) aufbewahrt werden.Bestandskontrolle für ArchivierungsmedienGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Dienstbetreiber gematikWährend der Übergangszeit – Ausführen einer Übernahmeinventuraller zur Archivierung verwendeten Wechselmedien(z. B. Bänder, Platten etc.), für die Dienstbetreiber sicherheitsrelevanteVerantwortungen übernommen hatDurchführen einer Bestandsprüfung und -abstimmung undumgehendes Informieren des Sicherheitsverantwortlichender gematik, wenn hierbei Fehler festgestellt wurdenKlären der bei der jährlichen Bandbestandsprüfung der zurArchivierung verwendeten Wechselmedien festgestelltenAbweichungen und Informieren des Sicherheitsverantwortlichender gematik über Fehler und eingeleiteten MaßnahmenImplementieren von Maßnahmen zur wirkungsvollen Beseitigungvon Restdaten auf Wechselmedien vor deren Entsorgungoder erneuten Verwendung außerhalb der Bibliothekdes spezifischen DienstesPPPPABestandskontrolle für ArchivierungsmedienBestandsabstimmungBestandsaufnahme durchgeführt von (derSpeichermedienverwalter kann ebenfallsteilnehmen)Die Bestandsabstimmung MUSS folgendeErgebnisse erbringen:Verbindlicher WertjährlichMindestens eine Person, die nicht unmittelbarmit der Verwaltung von Medien befasstistAnfangsbestand (Bestand am Ende der vorherigenZählung)gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 737 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturBestandskontrolle für ArchivierungsmedienHinweis: Bei den Empfehlungen handeltes sich um Mindestanforderungen. DieListe der Empfehlungen kann erweitert,nicht jedoch gekürzt werden.Zusammensetzung des ArchivierungsmedienbestandsAbweichungen bei der BestandsaufnahmeAufbewahren der BestandsaufnahmendokumentationErforderliche Unterschrift für abgeschlosseneBestandsaufnahmendokumentationVerbindlicher WertZugang neuer Medien (Medien, die von anderenStellen eingegangen sind)Entnahme abgegebener Medien (Medien, diean andere Stellen versendet wurden)Zugang neuer Medien, die zur Bibliothek hinzugefügtwurdenEntnahme von AusschussmedienEndsumme: Aktueller Bestand (Gesamtzahlder in der Bibliothek verwalteten Bänder)Archivierungsmedien einschließlich bereitsgeöffneter, leerer oder beschädigter Mediensowie Medien in automatischen oder robotergesteuertenSpeicherbibliothekenBelegen und dem zuständigen DienstbetreiberManagement meldenDie neuesten Aufzeichnungen MÜSSEN aufbewahrtwerden. Die Bestandsaufnahmendokumentationumfasst die Aufzeichnungen zurBestandsabstimmung und weitere Informationensowie die unterzeichnete Seite mit derGesamtbestandsabstimmung der zuvordurchgeführten Bestandsaufnahme.Verantwortlicher Manager für die ArchivierungsmedienbibliothekG5.4 - RestdatenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 9.2.6 Secure disposal or re-use of equipment (Sichere Entsorgungoder Wiederverwendung von Geräten) und Ziffer 10.7.2 Disposal of media (Beseitigungvon Datenträgern).Als Restdaten werden Informationen bezeichnet, die verarbeitet werden können und ausfrüheren Bearbeitungsschritten auf den Speichermedien vorhanden sind.Restdaten Verbindlicher WertRestdatenRestdaten vor der Entsorgung des zugehörigen Speichermediums oder dessenWeiterverwendung durch andere Kunden unlesbar machen. DabeiMÜSSEN die Vorgaben des BSI beachtet werden. Die Klassifizierung derMedien MUSS im Sicherheitskonzept beschrieben werden,gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 738 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG5.5 - DatensicherungskonzeptEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.5 Back-upDie folgenden Punkte MÜSSEN für ein Backup berücksichtigt werden:• Der notwendige Grad eines Backups MUSS definiert sein;• Genaue und vollständige Aufzeichnungen der Backup Kopien sowie dokumentierteVerfahren zur Wiederherstellung MÜSSEN erstellt werden;• Das Ausmaß (z. B. ob ein vollständiges oder ein differentielles Backup durchgeführtwerden soll) als auch die Frequenz, mit der Backups erzeugt werden,MUSS die Geschäftsanforderungen der Organisation reflektieren. Dazu gehörenauch die Sicherheitsanforderungen der betroffenen Informationen sowiederen Kritikalität im Hinblick auf Betriebsunterbrechungen;• Backups SOLLEN in einer ausreichenden Entfernung gelagert werden, um sicherzustellen,dass eine Katastrophe am Ursprungsort die Backups nicht beeinträchtigt;• Backups MÜSSEN einen angemessenen Schutz vor physischen Einflüssenund Umwelteinflüssen erhalten, der den Standards, mit denen die Ursprungsdatengeschützt werden, entspricht. Die Kontrolle von Medien am HauptstandortSOLL auf den Standort des Backups ausgedehnt werden;• Backup Medien MÜSSEN regelmäßig geprüft werden, um so sicherzustellen,dass man sich im Notfall auf das Backup verlassen kann;• Wiederherstellungsprozeduren SOLLEN regelmäßig überprüft und getestetwerden um sicherzustellen, dass sie funktionieren und in den vorgegebenenzeitlichen Rahmen durchgeführt werden können, die in den Verfahrensanweisungenfür Wiederherstellung vorgegeben werden;• In Situationen in denen Vertraulichkeit von Bedeutung ist, SOLLEN Backupsdurch Verschlüsselung geschützt werden.G5.5.1 - ArchivierungAufzeichnungen MÜSSEN in Übereinstimmung mit gesetzlichen, behördlichen, vertraglichenund geschäftlichen Anforderungen vor Verlust, Zerstörung und Fälschung geschütztwerden.Aufzeichnungen MÜSSEN nach Typen kategorisiert werden, z. B. Auditprotokolle, Systemkonfigurationenund betriebliche Verfahren, wobei für jeden Aufzeichnungstyp genaueAngaben zu Aufbewahrungsdauer und Speichermedientyp festzuhalten sind.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 739 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG 5.6 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03450 S Wechselmedien_Datensicherung_01:SpeichermedienverwalterA_03451 S Wechselmedien_Datensicherung_02:Etikettierungder Wechselmedien.A_03452 S Wechselmedien_Datensicherung_03:ExterneEtiketten mit EigentümerangabeA_03453A_03454A_03455SSSSchutz_Speichermedien_01:Aufbewahrungsmöglichkeitenfür WechselmedienSchutz_Speichermedien_02:Aufbewahren von Sicherungs-,Hersteller- und Archivierungsmedien.Schutz_Speichermedien_03:Abschließen von Bandlaufwerkenund MedieneinheitenGrundlegender Aufgabenbereich(Dienstbetreiber: performt):SpeichermedienverwalterAuf der Oberfläche von Wechselmedien KÖNNEN Etiketten in geeigneterForm angebracht werden, die Informationen zum Eignerdes Speichermediums sowie zur Klassifizierung der darauf enthaltenenDaten angebenExterne Etiketten mit einer Eigentümerangabe oder Informationenzur Klassifizierung:Nicht erforderlich.Grundlegender Aufgabenbereich(Dienstbetreiber: performt)Bereitstellen sicherer Aufbewahrungsmöglichkeiten für WechselmedienAufbewahren von Sicherungs-, Hersteller- und Archivierungsmedien:Aufbewahrung entsprechend dem Schutzbedarf der gespeichertenDatenobjekte:• in geschützten oder kontrollierten Sicherheitsbereichen• in einem Büroraum bzw. Schrank, der verschlossen ist, wenn dieBeaufsichtigung nicht gewährleistet istAbschließen von Bandlaufwerken und Medieneinheiten (z. B.Bandroboter, Direktzugriffsspeicher-Jukeboxes) : Abschließennicht erforderlich, wenn sich die Einheiten in einem geschütztenoder kontrollierten Sicherheitsbereich bzw. in einem Büroraumbefinden, der abgeschlossen ist, wenn die Beaufsichtigung nichtgewährleistet istAnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 740 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03456A_03457A_03458A_03459A_03460SSSSSTitel Beschreibung Rel. QuelleSchutz_Speichermedien_04:Aufbewahrung von Sicherungs-und Herstellermedien.Schutz_Speichermedien_05:Verlagern von SicherungsundArchivierungsmedien.Schutz_Speichermedien_06:Einlegen von Sicherungs- undArchivierungsmedienSpeichermedien_Bestandskontrolle_01:BestandsaufnahmeSpeichermedien_Bestandskontrolle_02:ÜbernahmeinventurA_03461 S Speichermedien_Bestandskontrolle_03:Bestandsprüfung und -abstimmungSicherungs- und Herstellermedien (unbeschriebene Medien) : Aufbewahrungin einem Büroraum bzw. Schrank des für die Verwaltungzuständigen Mitarbeiters der verschlossen ist, wenn die Beaufsichtigungnicht gewährleistet istVerlagern von Sicherungs- und Archivierungsmedien von und zueiner autorisierten Speichermedien-Aufbewahrungseinrichtung:Nachweis MUSS über Lieferbelege oder eine gleichwertige Methodeerbracht werdenEinlegen von Sicherungs- und Archivierungsmedien in die entsprechendenLaufwerke:Bei der Durchführung MUSS gewährleistet sein, dass keine nichtautorisierten Zugriffs- und Einlegeoperationen durchgeführt werdenWenn der Dienstbetreiber die Verantwortung für die Verwaltungeiner Bandbibliothek des Auftraggebers übernimmt, wird als erstesin Zusammenarbeit mit dem Auftraggeber eine Bestandsaufnahmedurchgeführt. Die vollständige Bestandsaufnahme der Wechselmedien(einschließlich der zugehörigen Dokumentation) MUSSvon beiden Parteien freigegeben, dokumentiert, unterzeichnet undfür die Dauer des Vertrags (oder für die im Vertrag angegebeneZeitdauer) aufbewahrt werden.Grundlegender Aufgabenbereich(Dienstbetreiber: performt,gematik:assistiert)Während der Übergangszeit – Ausführen einer Übernahmeinventuraller zur Archivierung verwendeten Wechselmedien (z. B. Bänder,Platten etc.), für die Dienstbetreiber sicherheitsrelevante Verantwortungenübernommen hatGrundlegender Aufgabenbereich(Dienstbetreiber: performt)Durchführen einer Bestandsprüfung und -abstimmung und umgehendesInformieren des Sicherheitsverantwortlichen der gematik,AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 741 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Afo-ID Anfo ArtTitel Beschreibung Rel. Quellewenn hierbei Fehler festgestellt wurdenA_03462A_03463SSÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturSpeichermedien_Bestandskontrolle_04:jährlichen Bandbestandsprüfung/Klären von Abweichungen.Speichermedien_Bestandskontrolle_05:Maßnahmen zur wirkungsvollenBeseitigung von Restdaten.A_03464 S Speichermedien_Bestandskontrolle_06:Bestandsabstimmung:A_03465 S Speichermedien_Bestandskontrolle_07:Druchführung der Bestandaufnahme.A_03466 SSpeichermedien_Bestandskontrolle_01:Ergebnisse der Bestandsabstimmung.Grundlegender Aufgabenbereich(Dienstbetreiber: performt)Klären der bei der jährlichen Bandbestandsprüfung der zur Archivierungverwendeten Wechselmedien festgestellten Abweichungenund Informieren des Sicherheitsverantwortlichen der gematik überFehler und eingeleiteten MaßnahmenGrundlegender Aufgabenbereich(Dienstbetreiber: performt)Implementieren von Maßnahmen zur wirkungsvollen Beseitigungvon Restdaten auf Wechselmedien vor deren Entsorgung odererneuten Verwendung außerhalb der Bibliothek des spezifischenDienstesBestandsabstimmung: jährlichBestandsaufnahme durchgeführt von (der Speichermedienverwalterkann ebenfalls teilnehmen):Mindestens eine Person, die nicht unmittelbar mit der Verwaltungvon Medien befasst istDie Bestandsabstimmung MUSS folgende Ergebnisse erbringen:Anfangsbestand (Bestand am Ende der vorherigen Zählung)Zugang neuer Medien (Medien, die von anderen Stellen eingegangensind)Entnahme abgegebener Medien (Medien, die an andere Stellenversendet wurden)Zugang neuer Medien, die zur Bibliothek hinzugefügt wurdenEntnahme von AusschussmedienEndsumme: Aktueller Bestand (Gesamtzahl der in der Bibliothekverwalteten Bänder)AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 742 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03467 S Speichermedien_Bestandskontrolle_08:Zusammensetzung des Archivierungsmedienbestands.A_03468 S Speichermedien_Bestandskontrolle_09:Abweichungen bei der BestandsaufnahmeA_03469 SSpeichermedien_Bestandskontrolle_10:Aufbewahren der BestandsaufnahmendokumentationA_03470 S Speichermedien_Bestandskontrolle_11:Unterschrift für abgeschlosseneBestandsaufnahmendokumentation.A_03471 SDatensicherungkonzept_01:Definition des Backup Grades.A_03472 S Datensicherungkonzept_02:Genaue und vollständige Aufzeichnungender Backup Kopien.A_03473 SDatensicherungkonzept_03:Umfang und Frequenz vonBackups.Zusammensetzung des Archivierungsmedienbestands:Archivierungsmedien einschließlich bereits geöffneter, leerer oderbeschädigter Medien sowie Medien in automatischen oder robotergesteuertenSpeicherbibliothekenAbweichungen bei der Bestandsaufnahme:Belegen und dem zuständigen Dienstbetreiber Management meldenAufbewahren der Bestandsaufnahmendokumentation:Die neuesten Aufzeichnungen MÜSSEN aufbewahrt werden. DieBestandsaufnahmendokumentation umfasst die Aufzeichnungenzur Bestandsabstimmung und weitere Informationen sowie dieunterzeichnete Seite mit der Gesamtbestandsabstimmung der zuvordurchgeführten BestandsaufnahmeErforderliche Unterschrift für abgeschlossene Bestandsaufnahmendokumentation:Verantwortlicher Manager für die ArchivierungsmedienbibliothekDer notwendige Grad eines Backups MUSS definiert sein;Genaue und vollständige Aufzeichnungen der Backup Kopien sowiedokumentierte Verfahren zur Wiederherstellung MÜSSEN erstelltwerden;Das Ausmaß (z. B. ob ein vollständiges oder ein differentiellesBackup durchgeführt werden soll) als auch die Frequenz, mit derBackups erzeugt werden, MUSS die Geschäftsanforderungen derOrganisation reflektieren. Dazu gehören auch die Sicherheitsanforderungender betroffenen Informationen sowie deren KritikalitätAnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 743 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelleim Hinblick auf Betriebsunterbrechungen;A_03474A_03475SSDatensicherungkonzept_04:Lagerung von Backups.Datensicherungkonzept_05:Schutz vor physischen Einflüssenund Umwelteinflüssen.A_03476 S Datensicherungkonzept_06:Regelmäßige Prüfung derBackup Medien.A_03477 SDatensicherungkonzept_07:Regelmäßiger Test des Wiederherstellungsvorgangs.A_03478 SDatensicherungkonzept_08:Verschlüselung von Backups.A_03479 S Archivierungskonzept_01:Schutz der Aufzeichnungengemäß gesetzlichen, behördlichen,vertraglichen und geschäftlichenAnforderungen.A_03480S Archivierungskonzept_02: Kategoriesierungder Aufzeichungen.Backups SOLLEN in einer ausreichenden Entfernung gelagertwerden, um sicherzustellen, dass eine Katastrophe am Ursprungsortdie Backups nicht beeinträchtigtBackups MÜSSEN einen angemessenen Schutz vor physischenEinflüssen und Umwelteinflüssen erhalten, der den Standards, mitdenen die Ursprungsdaten geschützt werden, entspricht. Die Kontrollevon Medien am Hauptstandort SOLL auf den Standort desBackups ausgedehnt werden;Backup Medien MÜSSEN regelmäßig geprüft werden, um so sicherzustellen,dass man sich im Notfall auf das Backup verlassenkann;Wiederherstellungsprozeduren SOLLEN regelmäßig überprüft undgetestet werden um sicherzustellen, dass sie funktionieren und inden vorgegebenen zeitlichen Rahmen durchgeführt werden können,die in den Verfahrensanweisungen für Wiederherstellung vorgegebenwerden;In Situationen in denen Vertraulichkeit von Bedeutung ist, SOLLENBackups durch Verschlüsselung geschützt werden.Aufzeichnungen MÜSSEN in Übereinstimmung mit gesetzlichen,behördlichen, vertraglichen und geschäftlichen Anforderungen vorVerlust, Zerstörung und Fälschung geschützt werden.Aufzeichnungen MÜSSEN nach Typen kategorisiert werden, z. B.Auditprotokolle, Systemkonfigurationen und betriebliche Verfahren,wobei für jeden Aufzeichnungstyp genaue Angaben zu Aufbewahrungsdauerund Speichermedientyp festzuhalten sind.AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5AnhangG 5gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 744 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 745 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG6 - Management von SicherheitszwischenfällenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 13.1.1 Reporting information security events (Meldung sicherheitsrelevanterEreignisse) und Ziffer 13.1.2 Reporting security weaknesses (Meldungvon Sicherheitsschwachstellen).Ein Sicherheitszwischenfall kann interne oder externe Ursachen haben, sich auf externeStandorte auswirken und in seiner Wertigkeit variieren. Als IT-Sicherheitszwischenfällebezeichnet man u. a. Systemeinbrüche, die Zerstörung von Daten, Manipulationen, kriminelleHandlungen oder andere schwerwiegende Beeinträchtigungen der Systemsicherheit.Andere Zwischenfälle können in der Regel durch das zuständige Standortmanagementund das zugehörige Personal bearbeitet werden.Sicherheitszwischenfälle werden weiter unterschieden:• Sicherheitsereignisse verursachen einen vermuteten Verlust der primärenSchutzziele Vertraulichkeit und Integrität von Informationsobjekten.• Sicherheitsvorfälle verursachen einen bestätigten Verlust der primärenSchutzziele Vertraulichkeit und Integrität von Informationsobjekten.Melden von SicherheitszwischenfällenGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Dienstbetreiber gematikUnverzügliches Informieren des verantwortlichen Koordinatorsüber alle Sicherheitsschwachstellen und Vorschlagenmöglicher GegenmaßnahmenOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Koordinieren der Maßnahmen bei Verdacht von möglichenSicherheitszwischenfällen und Durchführen der UntersuchungsmaßnahmenPAAPMelden von SicherheitszwischenfällenBenachrichtigen bei der Feststellungeines möglichen oder bereits aufgetretenenSicherheitszwischenfallsProtokollierungVerbindlicher WertUnverzügliches Benachrichtigen des Sicherheitsverantwortlichendes Dienstbetreibers undSicherheitsverantwortlicher der gematikErstellen einer Protokolldatei (mit Datums-, ZeitundQuellenangaben), um alle Informationen zuidentifizieren, die in Beziehung zu dem Ereignisstehengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 746 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnalyseSichten bzw. Mildern der Schäden, die an denverfügbaren Assets und Daten zu verzeichnensindNach Entdeckung eines sicherheitsrelevanten Vorfalls verhalten sich alle Beteiligten aufSeiten des Dienstbetreibers gemäß den folgenden Regeln, falls keine anders lautendenAnweisungen des Koordinators für sicherheitsrelevante Vorfälle vorliegen:• Es darf nicht versucht werden, die Untersuchungen selbst durchzuführen oderdas System zu „bereinigen“.• Informationen zu den durchgeführten Untersuchungen sind streng vertraulichund dürfen nur Personen zugänglich gemacht werden, die einen triftigenGrund vorweisen können.• Keine Kontakte zu Personen oder Organisationen herstellen, die als Tatverdächtigein Betracht kommen. Der Dienstbetreiber nimmt keinen Kontaktzu Personen oder Organisationen im Namen des Auftraggebers auf.• Keine Aussage gegenüber Dritten (Presse, etc.)Alle Beteiligten auf Seiten des Dienstbetreibers verhalten sich gemäß der folgenden Regel:• Es darf nicht versucht werden, selbst im Gegenzug in das System der verdächtigtenPerson oder Organisation einzubrechen.G6.1 - Anforderungen an das Incident ManagementEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 13 Information security incident management.Das Meldeverfahren SOLL Folgendes beinhalten:• geeignete Feedbackverfahren, um sicherzustellen, dass diejenigen, die ein Informationssicherheitsereignisgemeldet haben, nach Behandlung und Abschlussdes Ereignisses über die Resultate informiert werden;• Formulare für das Melden von Informationssicherheitsereignissen, die die Meldungunterstützen, und der berichtenden Person helfen, sich an alle notwendigenAktionen im Fall eines Informationssicherheitsereignisses zu erinnern;• das korrekte Verhalten im Fall eines Informationssicherheitsereignisses, d. h.:• sofortigen Notieren aller wichtigen Details (z. B. Nichteinhaltung oder Verstoß,auftretende Störungen, Nachrichten auf dem Bildschirm, seltsames Verhalten);• keine eigenen Aktionen ausführen, sondern sofort bei der Anlaufstelle melden;• Bezug zu einem etablierten formalen Disziplinarverfahren für die Behandlungvon Angestellten, Auftragnehmern und Drittbenutzern, die einen Sicherheitsverstoßbegangen haben.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 747 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturDer Dienstbetreiber ist verpflichtet, alle beobachteten oder vermuteten Sicherheitsschwachstellenin Systemen oder Services zu notieren und zu melden.Zusätzlich zu der Meldung von Informationssicherheitsereignissen und SchwachstellenSOLL die Überwachung von Systemen, Alarmen und Schwachstellen benutzt werden, umSicherheitsvorfälle zu identifizieren.Beispiele für Informationssicherheitsereignisse und –Vorfälle sind (Typen und Prioritätenmüssen definiert werden):• Verlust von Services, Geräten oder Einrichtungen;• Störungen oder Überlastungen von Systemen;• menschliche Fehler;• Nichteinhaltung von Policies und Verfahren;• Verstöße gegen physische Sicherheitseinrichtungen;• unkontrollierte Änderungen von Systemen;• Fehler in Software und Hardware;• Zugriffsverletzungen.• Vermutete SicherheitsschwachstelleDie folgenden Richtlinien für Verfahren für das Management von InformationssicherheitsvorfällenMÜSSEN in Betracht gezogen werden:• Verfahren MÜSSEN eingerichtet werden, um die verschiedenen Arten von Informationssicherheitsvorfällenzu behandeln, einschließlich:ooooooAusfälle von Informationssystemen und Verlust von Services;bösartiger Code;Denial of Service;Fehler aufgrund von unvollständigen oder ungenauen GeschäftsdatenVerstöße gegen Vertraulichkeit und Integrität;Missbrauch von Informationssystemen;• zusätzlich zu den normalen Notfallplänen MÜSSEN die Verfahren auch Folgendesabdecken:oooooAnalyse und Ermittlung der Ursache des Vorfalls;Eingrenzung;Planung und Umsetzung von korrigierenden Aktionen um, falls nötig, erneutesAuftreten zu verhindern;Kommunikation mit denjenigen, die durch die Wiederherstellung nach demVorfall betroffen oder an ihr beteiligt sind;Meldung des Vorgangs an die entsprechenden Behörden;gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 748 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• nach Bedarf MÜSSEN Auditprotokolle und ähnliche Beweise für folgendeZwecke gesammelt und gesichert werden:ooointerne Problemanalyse;Gebrauch als forensisches Beweismittel im Zusammenhang mit möglichemVertragsbruch, Verstoß gegen Vorschriften, oder bei zivil- oder strafrechtlichenVerfahren, z. B. bei Computermissbrauch- oder Datenschutzgesetzen;Verhandlungen mit Software- und Dienstanbietern über Entschädigungsleistungen;• Aktionen zur Wiederherstellung nach Sicherheitsverstößen und zur Behebungvon Systemausfällen MÜSSEN sorgfältig und ausdrücklich kontrolliert werden;die Verfahren MÜSSEN sicherstellen, dass:oooonur eindeutig identifizierte und berechtigte Mitarbeiter Zugang zu Systemenund Daten im aktiven Einsatz erhalten;alle vorgenommenen Notfallmaßnahmen detailliert dokumentiert werden;Notfallmaßnahmen an das Management berichtet und ordnungsgemäßnachgeprüft werden;die Integrität von Geschäftssystemen und Maßnahmen mit minimaler Verzögerungbestätigt werden kann.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 749 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG6.2 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03481 S Security_Incident_Management_01:Informieren des Koordinatorsund Vorschlagen von Gegenmaßnahmen.A_03482 S Security_Incident_Management_02:Koordinieren der Maßnahmenbei Verdacht von möglichenSicherheitszwischenfällen.A_03483 S Security_Incident_Management_03:Unverzügliches Benachrichtigendes Sicherheitsverantwortlichen.A_03484 S Security_Incident_Management_04:Erstellen einer Protokolldateimit Datums-, Zeit- und Quellenangaben.A_03485 S Security_Incident_Management_05:Analyse: Sichten bzw. Mildernder SchädenGrundlegender Aufgabenbereich(Dienstbetreiber: performt,gematik: assistiert)Unverzügliches Informieren des verantwortlichen Koordinatorsüber alle Sicherheitsschwachstellen und Vorschlagen möglicherGegenmaßnahmenOptionaler Aufgabenbereich(Dienstbetreiber: assistiert,gematik: performt)Koordinieren der Maßnahmen bei Verdacht von möglichen Sicherheitszwischenfällenund Durchführen der UntersuchungsmaßnahmenBenachrichtigen bei der Feststellung eines möglichen oder bereitsaufgetretenen Sicherheitszwischenfalls:Unverzügliches Benachrichtigen des Sicherheitsverantwortlichendes Dienstbetreibers und Sicherheitsverantwortlicher der gematikProtokollierung:Erstellen einer Protokolldatei (mit Datums-, Zeit- und Quellenangaben),um alle Informationen zu identifizieren, die in Beziehung zudem Ereignis stehenAnalyse:Sichten bzw. Mildern der Schäden, die an den verfügbaren Assetsund Daten zu verzeichnen sindAnhangG 6AnhangG 6AnhangG 6AnhangG 6AnhangG 6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 750 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03486 S Security_Incident_Management_06:Verhaltensregeln bei sicherheitsrelevantenVorfällen.A_03487 S Security_Incident_Management_07:Gestaltung des Meldeverfahrens.Nach Entdeckung eines sicherheitsrelevanten Vorfalls verhaltensich alle Beteiligten auf Seiten des Dienstbetreibers gemäß denfolgenden Regeln, falls keine anders lautenden Anweisungen desKoordinators für sicherheitsrelevante Vorfälle vorliegen:• Es darf nicht versucht werden, die Untersuchungen selbst durchzuführenoder das System zu „bereinigen“.• Informationen zu den durchgeführten Untersuchungen sindstreng vertraulich und dürfen nur Personen zugänglich gemachtwerden, die einen triftigen Grund vorweisen können.• Keine Kontakte zu Personen oder Organisationen herstellen, dieals Tatverdächtige in Betracht kommen. Der Dienstbetreiber nimmtkeinen Kontakt zu Personen oder Organisationen im Namen desAuftraggebers auf.• Keine Aussage gegenüber Dritten (Presse, etc.)Alle Beteiligten auf Seiten des Dienstbetreibers verhalten sich gemäßder folgenden Regel:• Es darf nicht versucht werden, selbst im Gegenzug in das Systemder verdächtigten Person oder Organisation einzubrechenDas Meldeverfahren SOLL Folgendes beinhalten:• geeignete Feedbackverfahren, um sicherzustellen, dass diejenigen,die ein Informationssicherheitsereignis gemeldet haben, nachBehandlung und Abschluss des Ereignisses über die Resultateinformiert werden;• Formulare für das Melden von Informationssicherheitsereignissen,die die Meldung unterstützen, und der berichtenden Personhelfen, sich an alle notwendigen Aktionen im Fall eines Informationssicherheitsereignisseszu erinnern;• das korrekte Verhalten im Fall eines Informationssicherheitsereignisses,d. h.:• sofortigen Notieren aller wichtigen Details (z. B. Nichteinhaltungoder Verstoß, auftretende Störungen, Nachrichten auf dem Bild-AnhangG 6AnhangG 6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 751 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03488 S Security_Incident_Management_08:Nutzung der SystemüberwachungA_03489 S Security_Incident_Management_09:Verfahren in Abhängigkeit vonder spezifischen Art eines Sicherheitsvorfalls.A_03490 S Security_Incident_Management_10:Ausgestaltung der Verfahren.A_03491 S Security_Incident_Management_11:schirm, seltsames Verhalten);• keine eigenen Aktionen ausführen, sondern sofort bei der Anlaufstellemelden;• Bezug zu einem etablierten formalen Disziplinarverfahren für dieBehandlung von Angestellten, Auftragnehmern und Drittbenutzern,die einen Sicherheitsverstoß begangen haben.Zusätzlich zu der Meldung von Informationssicherheitsereignissenund Schwachstellen SOLL die Überwachung von Systemen, Alarmenund Schwachstellen benutzt werden, um Sicherheitsvorfällezu identifizieren.Verfahren MÜSSEN eingerichtet werden, um die verschiedenenArten von Informationssicherheitsvorfällen zu behandeln, einschließlich:• Ausfälle von Informationssystemen und Verlust von Services;• bösartiger Code;• Denial of Service;• Fehler aufgrund von unvollständigen oder ungenauen Geschäftsdaten• Verstöße gegen Vertraulichkeit und Integrität;• Missbrauch von Informationssystemen;zusätzlich zu den normalen Notfallplänen MÜSSEN die Verfahrenauch Folgendes abdecken:• Analyse und Ermittlung der Ursache des Vorfalls;• Eingrenzung;• Planung und Umsetzung von korrigierenden Aktionen um, fallsnötig, erneutes Auftreten zu verhindern;• Kommunikation mit denjenigen, die durch die Wiederherstellungnach dem Vorfall betroffen oder an ihr beteiligt sind;• Meldung des Vorgangs an die entsprechenden Behörden;nach Bedarf MÜSSEN Auditprotokolle und ähnliche Beweise fürfolgende Zwecke gesammelt und gesichert werden:AnhangG 6AnhangG 6AnhangG 6Anhanggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 752 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03492STitel Beschreibung Rel. QuelleBeweissicherung und Auditprotokolle.• interne Problemanalyse;• Gebrauch als forensisches Beweismittel im Zusammenhang mitmöglichem Vertragsbruch, Verstoß gegen Vorschriften, oder beizivil- oder strafrechtlichen Verfahren, z. B. bei Computermissbrauch-oder Datenschutzgesetzen;• Verhandlungen mit Software- und Dienstanbietern über Entschädigungsleistungen;Aktionen zur Wiederherstellung nach Sicherheitsverstößen und zurBehebung von Systemausfällen MÜSSEN sorgfältig und ausdrücklichkontrolliert werden; die Verfahren MÜSSEN sicherstellen,dass:• nur eindeutig identifizierte und berechtigte Mitarbeiter Zugang zuSystemen und Daten im aktiven Einsatz erhalten;• alle vorgenommenen Notfallmaßnahmen detailliert dokumentiertwerden;• Notfallmaßnahmen an das Management berichtet und ordnungsgemäßnachgeprüft werden;• die Integrität von Geschäftssystemen und Maßnahmen mit minimalerVerzögerung bestätigt werden kannSecurity_Incident_Management_12:Wiederherstellungsmaßnahmennach Sicherheitsverstößen.G 6AnhangG 6gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 753 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG7 - Sicherheits-/IntegritätsempfehlungsprozessEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 12.6.1 Control of technical vulnerabilities (Kontrolle technischerSchwachstellen).Eine Sicherheits-/Integritätsempfehlung ist eine Warnung zu einem Sicherheitsrisiko innerhalbeines Programms oder Prozesses, welches nicht autorisierten Benutzern dasArbeiten mit privilegierten Berechtigungen auf einem System, die Umgehung der Zugriffskontrolleoder den unberechtigten Zugriff auf bestimmte Daten ermöglicht. Für die Installationder erforderlichen Fixes innerhalb definierter Zeitabstände MUSS ein Sicherheits-/Integritätsempfehlungsprozess befolgt werden. Für diesen Prozess gelten die folgendenKernvoraussetzungen:• Die Bewertung des Sicherheitsrisikos basiert auf der Abschätzung der vorhandenenSchwachstellen und der Risikoeinstufung für eine unberechtigteSystemnutzung.• Prozess für die Benachrichtigung über die Verfügbarkeit von Fixes.• Prozess für die zeitliche Planung der Anwendung von Sicherheits-/Integritätsfixes.• Der Prozess kann überprüft werden.G7.1 - WertigkeitSicherheits-/Integritätsempfehlungen sind bestimmten Kategorien zugeordnet, die zurFeststellung der Implementierungszeit verwendet werden. Im Folgenden sind die Kriterienaufgeführt, die bei der Zuordnung verwendet werden.Schwachstellenbeurteilung:• Große Schwachstelle: Umgehung der Zugriffskontrollsysteme oderunberechtigter Zugriff auf eine Benutzer-ID mit System- oderSicherheitsadministratorberechtigung, ohne dass hierzu eine Endbenutzer-IDerforderlich ist.• Mittlere Schwachstelle: Umgehung der Zugriffskontrollsysteme oderunberechtigter Zugriff auf eine Benutzer-ID mit System- oderSicherheitsadministratorberechtigung über eine vorhandene Endbenutzer-ID,oder nicht autorisierter Zugriff auf Daten, ohne dass hierzu eine Endbenutzer-ID erforderlich ist.• Geringe Schwachstellen: Nicht autorisierter Zugriff auf Daten einerEndbenutzer-ID.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 754 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKategorie für die unberechtigte Nutzung:• Geringer Nutzungsaufwand: Die Schwachstelle kann von einem Benutzer mitGrundkenntnissen dazu genutzt werden, die Zugriffskontrollen zu umgehen.Hierbei werden keine Kenntnisse zur Funktionsweise des Betriebssystemsoder der Umgebung vorausgesetzt. Es wird z. B. nach einer einfachenProzedur vorgegangen.• Mittlerer Nutzungsaufwand: Die Schwachstelle kann von einem Benutzer mitmittleren Kenntnissen dazu genutzt werden, die Zugriffskontrollen zuumgehen. Hierbei werden Kenntnisse in der Benutzung derBefehlsschnittstelle im Betriebssystem oder in der Umgebung vorausgesetzt.• Hoher Nutzungsaufwand: Die Schwachstelle kann von einem Benutzer mitfortgeschrittenen Kenntnissen dazu genutzt werden, die Zugriffskontrollen zuumgehen. Hierbei werden Kenntnisse eines Produktspezialisten oderProduktentwicklers in der Benutzung der Befehlsschnittstelle imBetriebssystem oder in der Umgebung vorausgesetzt.Wertigkeitsbeurteilungen für Sicherheits-/IntegritätsempfehlungenKategorie für die unberechtigteNutzungGrosseSchwachstelleMittlereSchwachstelleNiedriger Nutzungsaufwand Hoch Hoch MittelMittlerer Nutzungsaufwand Hoch Mittel NiedrigHoher Nutzungsaufwand Mittel Niedrig NiedrigGeringeSchwachstelleG7.2 - BenachrichtigungszeitplanSobald ein Sicherheits-/Integritätsfix verfügbar ist, übermittelt der Dienstbetreiber eineBenachrichtigung mit detaillierten Informationen und Angaben zur Wertigkeitsbeurteilung.Benachrichtigungszeitplan für Sicherheits-/IntegritätsfixesHohe WertigkeitMittlere WertigkeitNiedrige WertigkeitVerbindlicherWert3 Werktage10 Werktage30 WerktageAnforderungen des spezifischenDienstesG7.3 - ImplementierungszeitplanNach erfolgter Benachrichtigung wird vom Auftraggeber und vom Dienstbetreiber-Implementierungsteamein Implementierungszeitplan für Sicherheits-/Integritätsfixes vereinbart.Der Implementierungszeitplan MUSS folgenden Faktoren Rechnung tragen:• Tests, falls gewünschtgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 755 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastruktur• Verfügbarkeit der Systeme, auf denen die Fixes angewandt werden, um dieunerwünschte Unterbrechung kritischer Verarbeitungsprozesse zu verhindern• Anzahl der Systeme, auf denen die Fixes angewandt werdenHinweis: Laut Zeitplan ist es nicht erforderlich, dass der Fix auf allen Systemen/Serverngleichzeitig installiert wird. Im Zeitplan können je nach Vereinbarung der Vertragspartnerdasselbe Datum oder verschiedene Daten angegeben sein.ImplementierungszeitplanGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Festlegen eines Implementierungszeitplans für identifizierte FixesBeschaffen und Anwenden von Sicherheits-/Integritätsfixes innerhalbdes vereinbarten ZeitraumsDienstbetreiberPPImplementierungszeitplanImplementierungszeitplanZeitraum für die Erstellung eines ImplementierungszeitplansZeitraum für die Aufbewahrung eines ImplementierungszeitplansEinzuleitende Maßnahmen, wenn keinImplementierungszeitplan erstellt wirdVerbindlicher WertGenehmigter Zeitplan MUSS dokumentiertwerden10 WerktageAufbewahren aller Zeitpläne für die derzeitigeProduktversion für 18 MonateInstallieren des empfohlenen Fixes währenddes nächsten geplanten WartungszyklusHinweis: Nach Beginn eines Wartungszykluskann sich die Empfehlung auf den nächstenZyklus verschiebengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 756 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG7.4 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtA_03493A_03494SSTitel Beschreibung Rel. QuelleSicherheits_Prozess_01: Prozessgestaltung.Sicherheits_Prozess_02: Kategorisierungvon Schwachstellen.Eine Sicherheits-/Integritätsempfehlung ist eine Warnung zu einemSicherheitsrisiko innerhalb eines Programms oder Prozesses, welchesnicht autorisierten Benutzern das Arbeiten mit privilegiertenBerechtigungen auf einem System, die Umgehung der Zugriffskontrolleoder den unberechtigten Zugriff auf bestimmte Daten ermöglicht.Für die Installation der erforderlichen Fixes innerhalb definierterZeitabstände MUSS ein Sicherheits-/Integritätsempfehlungsprozess befolgt werden. Für diesen Prozessgelten die folgenden Kernvoraussetzungen:• Die Bewertung des Sicherheitsrisikos basiert auf der Abschätzungder vorhandenen Schwachstellen und der Risikoeinstufungfür eine unberechtigte Systemnutzung.• Prozess für die Benachrichtigung über die Verfügbarkeit von Fixes.• Prozess für die zeitliche Planung der Anwendung von Sicherheits-/Integritätsfixes.• Der Prozess kann überprüft werden.Sicherheits-/Integritätsempfehlungen sind bestimmten Kategorienzugeordnet, die zur Feststellung der Implementierungszeit verwendetwerden. Im Folgenden sind die Kriterien aufgeführt, die beider Zuordnung verwendet werden.Schwachstellenbeurteilung:• Große Schwachstelle: Umgehung der Zugriffskontrollsystemeoder unberechtigter Zugriff auf eine Benutzer-ID mit System- oderSicherheitsadministratorberechtigung, ohne dass hierzu eine Endbenutzer-IDerforderlich ist.• Mittlere Schwachstelle: Umgehung der ZugriffskontrollsystemeAnhangG 7AnhangG 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 757 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtA_03495STitel Beschreibung Rel. QuelleSchwachstellen_Wertigkeit_01:Wertigkeitvon Sicherheitsempfehlungen.oder unberechtigter Zugriff auf eine Benutzer-ID mit System- oderSicherheitsadministratorberechtigung über eine vorhandene Endbenutzer-ID,oder nicht autorisierter Zugriff auf Daten, ohne dasshierzu eine Endbenutzer-ID erforderlich ist.• Geringe Schwachstellen: Nicht autorisierter Zugriff auf Daten einerEndbenutzer-ID.Kategorie für die unberechtigte Nutzung:• Geringer Nutzungsaufwand: Die Schwachstelle kann von einemBenutzer mit Grundkenntnissen dazu genutzt werden, die Zugriffskontrollenzu umgehen. Hierbei werden keine Kenntnisse zurFunktionsweise des Betriebssystems oder der Umgebung vorausgesetzt.Es wird z. B. nach einer einfachen Prozedur vorgegangen.• Mittlerer Nutzungsaufwand: Die Schwachstelle kann von einemBenutzer mit mittleren Kenntnissen dazu genutzt werden, dieZugriffskontrollen zu umgehen. Hierbei werden Kenntnisse in derBenutzung der Befehlsschnittstelle im Betriebssystem oder in derUmgebung vorausgesetzt.• Hoher Nutzungsaufwand: Die Schwachstelle kann von einemBenutzer mit fortgeschrittenen Kenntnissen dazu genutzt werden,die Zugriffskontrollen zu umgehen. Hierbei werden Kenntnisseeines Produktspezialisten oder Produktentwicklers in der Benutzungder Befehlsschnittstelle im Betriebssystem oder in der Umgebungvorausgesetzt.Wertigkeitsbeurteilungen für Sicherheits-/Integritätsempfehlungen:Niedriger Nutzungsaufwand-Große Schwachstelle: Kategorie HochNiedriger Nutzungsaufwand-Mittlere Schwachstelle: KategorieHochNiedriger Nutzungsaufwand-Geringe Schwachstelle: KategorieHochAnhangG 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 758 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleMittlerer Nutzungsaufwand-Große Schwachstelle: Kategorie HochMittlerer Nutzungsaufwand-Mittlere Schwachstelle: Kategorie MittelMittlerer Nutzungsaufwand-Geringe Schwachstelle: KategorieNiedrigA_03496 S Schwachstellen_Benachrichtigungs_Zeitplan_01: Benachrichtigungszeitplan.A_03497 SSchwachstellen_Implementierungs_Zeitplan_01: Erstellung und Umfangdes Implementierungszeitplans.A_03498 S Schwachstellen_Implementierungs_Zeitplan_02: Festlegen eines Implementierungszeitplansfür identifizierteFixesA_03499 S Schwachstellen_Implementierungs_Zeitplan_03: Beschaffen und Anwendenvon Sicherheits-Hoher Nutzungsaufwand-Große Schwachstelle: Kategorie MittelHoher Nutzungsaufwand-Mittlere Schwachstelle: Kategorie NiedrigHoher Nutzungsaufwand-Geringe Schwachstelle: Kategorie NiedrigBenachrichtigungszeitplan für Sicherheits-/Integritätsfixes:Hohe Wertigkeit: 3 WerktageMittlere Wertigkeit: 10 WerktageNiedrige Wertigkeit: 30 WerktageNach erfolgter Benachrichtigung wird vom Auftraggeber und vomDienstbetreiber-Implementierungsteam ein Implementierungszeitplanfür Sicherheits-/Integritätsfixes vereinbart. Der ImplementierungszeitplanMUSS folgenden Faktoren Rechnung tragen:• Tests, falls gewünscht• Verfügbarkeit der Systeme, auf denen die Fixes angewandt werden,um die unerwünschte Unterbrechung kritischer Verarbeitungsprozessezu verhindern• Anzahl der Systeme, auf denen die Fixes angewandt werdenGrundlegender Aufgabenbereich(Dienstbetreiber: performt):Festlegen eines Implementierungszeitplans für identifizierte FixesGrundlegender Aufgabenbereich(Dienstbetreiber: performt):Beschaffen und Anwenden von Sicherheits-/Integritätsfixes inner-AnhangG 7AnhangG 7AnhangG 7AnhangG 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 759 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelle/Integritätsfixes.halb des vereinbarten ZeitraumsA_03503SA_03500 S Schwachstellen_Implementierungs_Zeitplan_04: Genehmigung und Dokumentationdes Zeitplans.A_03501 S Schwachstellen_Implementierungs_Zeitplan_05: Zeitraum für die Erstellungeines ImplementierungszeitplansA_03502 S Schwachstellen_Implementierungs_Zeitplan_06: Zeitraum für die Aufbewahrungeines Implementierungszeitplans.Schwachstellen_Implementierungs_Zeitplan_07: Einzuleitende Maßnahmen,wenn kein Implementierungszeitplanerstellt wirdImplementierungszeitplan:Genehmigter Zeitplan MUSS dokumentiert werdenZeitraum für die Erstellung eines Implementierungszeitplans:10 WerktageZeitraum für die Aufbewahrung eines Implementierungszeitplans:Aufbewahren aller Zeitpläne für die derzeitige Produktversion für18 MonateEinzuleitende Maßnahmen, wenn kein Implementierungszeitplanerstellt wird:Installieren des empfohlenen Fixes während des nächsten geplantenWartungszyklusHinweis: Nach Beginn eines Wartungszyklus kann sich die Empfehlungauf den nächsten Zyklus verschiebenAnhangG 7AnhangG 7AnhangG 7AnhangG 7gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 760 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG8 - Notfallpläne/ Business ContinuityEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 14 Business continuity management.Pläne MÜSSEN entwickelt und umgesetzt werden, um den Betrieb aufrechtzuerhaltenoder wiederherzustellen, und um die Verfügbarkeit von Informationen auf dem erforderlichenLevel und in dem erforderlichen Zeitraum nach Unterbrechungen oder Ausfällen vonkritischen Geschäftsprozessen sicherzustellen.Der Planungsprozess für Business Continuity SOLL die folgenden Punkte berücksichtigen:• Identifizierung und Vereinbarung der Verantwortlichkeiten und Verfahren fürBusiness Continuity;• Identifizierung des akzeptablen Verlusts von Informationen und Services;• Umsetzung von Verfahren um eine Wiederherstellung des Geschäftsbetriebsund der Verfügbarkeit von Informationen innerhalb des geforderten Zeitrahmenszu ermöglichen; besondere Aufmerksamkeit muss der Beurteilung internerund externer Geschäftsabhängigkeiten und den vorhandenen Verträgenzukommen• zu befolgende Betriebsverfahren, abhängig von dem Abschluss der Wiederherstellung;• Dokumentation vereinbarter Verfahren und Prozesse;• angemessene Ausbildung für Mitarbeiter in den vereinbarten Verfahren undProzessen, einschließlich des Krisenmanagements;• Testen und Aktualisierung der Pläne.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 761 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG8.1 – Zusammenfassung der AusgangsanforderungenAfo-ID Art Titel Beschreibung Rel. QuelleA_03504A_03505SSNotfall_Pläne_01: Esmüssen Notfallpläneerstellt weden.Notfall_Pläne_02:Planungen für BusinessContinuity.Pläne MÜSSEN entwickelt und umgesetzt werden, um den Betrieb aufrechtzuerhaltenoder wiederherzustellen, und um die Verfügbarkeit vonInformationen auf dem erforderlichen Level und in dem erforderlichenZeitraum nach Unterbrechungen oder Ausfällen von kritischen GeschäftsprozessensicherzustellenDer Planungsprozess für Business Continuity SOLL die folgendenPunkte berücksichtigen:• Identifizierung und Vereinbarung der Verantwortlichkeiten und Verfahrenfür Business Continuity;• Identifizierung des akzeptablen Verlusts von Informationen und Services;• Umsetzung von Verfahren um eine Wiederherstellung des Geschäftsbetriebsund der Verfügbarkeit von Informationen innerhalb des gefordertenZeitrahmens zu ermöglichen; besondere Aufmerksamkeit mussder Beurteilung interner und externer Geschäftsabhängigkeiten undden vorhandenen Verträgen zukommen• zu befolgende Betriebsverfahren, abhängig von dem Abschluss derWiederherstellung;• Dokumentation vereinbarter Verfahren und Prozesse;• angemessene Ausbildung für Mitarbeiter in den vereinbarten Verfahrenund Prozessen, einschließlich des Krisenmanagements;• Testen und Aktualisierung der Pläne.Anhang G 8Anhang G 8gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 762 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG9 - Anwendungs-/EndbenutzersicherheitG9.1 - AnwendungssicherheitEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 12.1 Security requirements of information systems (Sicherheitsanforderungenfür IT-Systeme), Ziffer 12.2 Correct processing in applications (OrdnungsgemäßeVerarbeitung innerhalb von Anwendungen) und Ziffer 12.4.3 Accesscontrol to program source (Zugriffskontrolle zur Programmquelle).Die Sicherheit der verwendeten Programme MUSS gewährleistet und die Daten der eingesetztenAnwendungen MÜSSEN gegen den nicht autorisierten Zugriff und die nichtautorisierte Verwendung geschützt werden. Hierzu MÜSSEN die folgenden Angaben derAnwendung bei der gematik erfragt werden:• Informationen zum öffentlichen Zugriff für die Programme und Daten• Liste der Benutzer, die zusätzlich Zugriff auf die Programme und Daten benötigen• Prüfvoraussetzungen für die Programme und DatenOhne Einhaltung des festgelegten Genehmigungsprozesses der gematik werden keineÄnderungen an den Schutzmaßnahmen für die Programme oder Daten vorgenommen.AnwendungssicherheitOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Dienstbetreiber gematikDefinieren der Sicherheitsanforderungen für AnwendungsassetsImplementieren der Sicherheitsanforderungen für Anwendungsassetsmit Hilfe der ZugriffskontrollsoftwareAPPG9.2 - EndbenutzersicherheitEndbenutzersicherheitOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Definieren der Sicherheitsanforderungen für EndbenutzerdatenDienstbetreiberPImplementieren der Sicherheitsanforderungen für Endbenutzerdatenmit Hilfe der ZugriffskontrollsoftwareVerantwortung für den Schutz klassifizierter DatenPPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 763 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturEndbenutzersicherheitRessource mit nicht klassifiziertenDatenVerbindlicher WertDer für die entsprechende Ressource verantwortlichekann die Standardeinstellungen für den Zugriffsschutzexplizit änderngematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 764 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

G9.3 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtA_03506STitel Beschreibung Rel. QuelleÜbergreifendes Sicherheitskonzept der TelematikinfrastrukturAnwendungs_Endnutzer_Sicherheit_01: Die Sicherheit der verwendetenProgramme MUSS gewährleistetsein.A_03507 S Anwendungs_Endnutzer_Sicherheit_02: Genehmigungsprozesses.A_03508 S Anwendungs_Endnutzer_Sicherheit_03: Definieren der Sicherheitsanforderungenfür AnwendungsassetsA_03509 S Anwendungs_Endnutzer_Sicherheit_04: Implementieren der SicherheitsanforderungenfürAnwendungsassets mit Hilfeder Zugriffskontrollsoftware .A_03510 S Anwendungs_Endnutzer_Sicherheit_05: Definieren der Sicher-Die Sicherheit der verwendeten Programme MUSS gewährleistetund die Daten der eingesetzten Anwendungen MÜSSEN gegenden nicht autorisierten Zugriff und die nicht autorisierte Verwendunggeschützt werden. Hierzu MÜSSEN die folgenden Angabender Anwendung bei der gematik erfragt werden:• Informationen zum öffentlichen Zugriff für die Programme undDaten• Liste der Benutzer, die zusätzlich Zugriff auf die Programme undDaten benötigen• Prüfvoraussetzungen für die Programme und DatenOhne Einhaltung des festgelegten Genehmigungsprozesses dergematik DÜRFEN KEINE Änderungen an den Schutzmaßnahmenfür die Programme oder Daten vorgenommen werden.Optionaler Aufgabenbereich(Dienstbetreiber: assistiertgematik: performt ):Definieren der Sicherheitsanforderungen für AnwendungsassetsOptionaler Aufgabenbereich(Dienstbetreiber: performt):Implementieren der Sicherheitsanforderungen für Anwendungsassetsmit Hilfe der ZugriffskontrollsoftwareOptionaler Aufgabenbereich(Dienstbetreiber: performt):Definieren der Sicherheitsanforderungen für EndbenutzerdatenAnhangG 9AnhangG 9AnhangG 9AnhangG 9AnhangG 9gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 765 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelleheitsanforderungen für Endbenutzerdaten.A_03511 S Anwendungs_Endnutzer_Sicherheit_06: Implementieren der SicherheitsanforderungenfürEndbenutzerdaten mit Hilfeder Zugriffskontrollsoftware.A_03512 S Anwendungs_Endnutzer_Sicherheit_07: Verantwortung für denSchutz klassifizierter Daten.A_03513 S Anwendungs_Endnutzer_Sicherheit_08: Ressource mit nicht klassifiziertenDaten.Optionaler Aufgabenbereich(Dienstbetreiber: performt):Implementieren der Sicherheitsanforderungen für Endbenutzerdatenmit Hilfe der ZugriffskontrollsoftwareOptionaler Aufgabenbereich(Dienstbetreiber: performt):Verantwortung für den Schutz klassifizierter DatenRessource mit nicht klassifizierten Daten: Der für die entsprechendeRessource Verantwortliche kann die Standardeinstellungen fürden Zugriffsschutz explizit ändernAnhangG 9AnhangG 9AnhangG 9gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 766 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG10 - NetzwerkkontrollenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 10.6.1 Network Controls (Netzwerk-Maßnahmen) und Ziffer10.6.2 Security of network services (Sicherheit von Netzdiensten).G10.1 - Zugriff auf das DatennetzwerkEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.4.1 Policy on use of network services (Verfahren zur Benutzungvon Netzdiensten).Der Zugriff auf Software zur Überwachung, Bearbeitung oder Änderung von Netzkonfigurationenoder -einheiten MUSS kontrolliert werden, um die Störung des Netzbetriebsdurch unbefugten Zugriff zu verhindern.Die Einzelheiten werden im Dokument Netzwerksicherheit [gemNWSich] beschrieben.Zugriff auf das DatennetzwerkGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Verwalten und Instandhalten aller Einheiten der Netzwerkinfrastruktur,die zur Verbindung des Netzwerks von Dienstbetreiber mit dem Netzwerkdes spezifischen Dienstes zum Zweck der Servicebereitstellungeingesetzt werden könnenDienstbetreiberPZugriff auf das DatennetzwerkZugriff auf NetzwerksoftwareErneute Überprüfung derZugriffsberechtigungVerbindlicher WertAuf Personen beschränkt, deren Aufgabenbereich dieNetzwerkunterstützung umfasstIm Abstand von drei MonatenG10.2 - Unternehmensübergreifende ServicesEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.4.2 Use authentication for external connections (Nutzungsauthentifizierungfür externe Verbindungen).gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 767 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturUnternehmensübergreifende Services (IES = Inter-Enterprise Services) umfassen folgendeBereiche:• Verbindungen zwischen den internen IT-Services des spezifischen Dienstesund den externen IT-Services eines Unternehmens, einschließlich Internet• Fernzugriff auf die internen IT-Services des spezifischen Dienstes durch dessenMitarbeiter und durch externe Personen (beispielsweise Lieferanten, Subunternehmer,Geschäftspartner, Kunden usw.)Ein IES-Gateway ist ein System, eine Anwendung oder eine Hardwareumgebung, das/dieunternehmensübergreifende Services ermöglicht. In der Regel stellt ein IES-Gateway außerdemdie Hauptverbindung für die Datenübertragung zwischen den internen Assets desspezifischen Dienstes und externen oder fernen Assets bereit.IES-Gateways können von Dienstbetreiber, vom spezifischen Dienstes oder einem dritten,vom Auftraggeber autorisierten Unternehmen eingerichtet werden. Zu beachten ist hierbei,dass IES-Gateways sich direkt auf die Fähigkeit von Dienstbetreiber zur Bereitstellunggesicherter Services im Netz des spezifischen Dienstes auswirken können.Unternehmensübergreifende ServicesOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Dienstbetreiber gematikIdentifizieren aller unternehmensübergreifenden Gateway-Services des spezifischen Dienstes und der Benutzer, diezur Verwendung dieser Services berechtigt sindVerwalten und Aufrechterhalten der Sicherheitsmaßnahmenfür die Bereitstellung der unternehmensübergreifenden Gateway-Servicesfür den spezifischen DienstesAPPG10.2.1 - VerbindungsanforderungenIES-Gateways MÜSSEN den nachfolgend aufgeführten IES-spezifischen Kontrollanforderungenfür die Kontrolle von Informationen entsprechen, die für die Bereitstellung desDienstes oder andere durch das Management des Dienstbetreibers freigegebene Zweckeüber ein IES-Gateway übertragen werden.VerbindungsanforderungenOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Dienstbetreiber gematikAutorisieren der Übertragung von Daten- oder Programmdateienzwischen den internen Systemen des spezifischenDienstes und externen Benutzern über ein IES-Gateway imRahmen der Abnahme der entsprechenden Konzepte durchdie gematik.Vor dem Aktivieren des Gateway-Services – Sicherstellender Übereinstimmung des Gateways mit den definiertenAnforderungenAPPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 768 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVerbindungsanforderungenIdentifizieren und Authentifizieren von BenutzernSystematische Einbruchsversuche auf IES-GatewayVerbindungen zwischen Netzen, Systemen oderAnwendungenÜbertragen einer E-Mail über ein IES-GatewayPrüfen der ID von Personen, die E-Mails über dasIES-Gateway sendenÜbertragen von Daten- oder Programmdateien ü-ber ein IES-GatewayPrüfen der ID von Mitarbeitern des spezifischenDienstes, die Dateiübertragungen über das IES-Gateway ausführenAktivitätenprotokollAufbewahren von ProtokollenBestätigung der Einhaltung der definierten AnforderungenAufbewahren der Bestätigung der Einhaltung derdefinierten AnforderungenVerbindlicher WertAlle im Sicherheitskonzept definiertenKontrollenProzess zur Feststellung und BearbeitungPrüfen der externen ID bei jeder„Aktivierung“ der VerbindungNur insoweit erlaubt, wie es diedem Dienst entsprechenden Konzepteexplizit fordern.Gemäß den Vorgaben im SicherheitskonzeptAlle im Sicherheitskonzept definiertenKontrollenGemäß den Vorgaben im SicherheitskonzeptAngeben von Datum und Uhrzeit,Identifikation des Absenders sowieder Zieladresse3 MonateAls Teil des regelmäßigen Reportingszur Einhaltung der SecuritySLAsAktueller plus vorheriger ZeitraumG10.2.2 - Verbindungen zum Netzwerk der gematikZur Unterstützung der Auftraggeberumgebung können ggf. Datenverbindungen zwischenden Netzwerken und Systemen der gematik und den Netzwerken und Systemen vonDienstbetreiber eingerichtet werden. Diese Verbindungen gelten als IES-Verbindungenund MÜSSEN daher über IES-Gateways geführt und von Dienstbetreiber bereitgestelltwerden. Ein IES-Gateway am Verbindungsendpunkt beim spezifischen Dienst ist nurdann erforderlich, wenn er von diesem spezifischen Dienst gefordert wird.Verbindungen zum Netzwerk der gematikGrundlegende AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Verwalten und Instandhalten aller Firewall- und Gateway-Einheiten, mitdenen Verbindungen zwischen dem Netzwerk des DienstbetreibersDienstbetreiberPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 769 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturVerbindungen zum Netzwerk der gematikund dem Netzwerk des spezifischen Dienstes zum Zweck der Bereitstellungvon Services hergestellt werdenAnforderungen für die individuelle Identifikation und Zugriffsautorisierungam IES-GatewayAutorisieren des Zugriffs über ein IES-Gateway durch DienstbetreiberMitarbeiterPPgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 770 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG10.3 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03514Zugriff_Netzwerk_01: KontrollierterZugriff auch Administra-Stions und Überwachungssoftware.A_03515 S Zugriff_Netzwerk_02: Verwaltenund Instandhalten allerEinheiten der Netzwerkinfrastruktur.A_03516 S Zugriff_Netzwerk_03: Zugriffauf Netzwerksoftware.A_03517 S Zugriff_Netzwerk_04: Revalidierungder Zugriffsberechtigung:A_03518 S Netzwerk_Unternehmensübergreifende_Services_01: Identifizierenaller unternehmensübergreifendenGateway-Services.A_03519 S Netzwerk_Unternehmensübergreifende_Services_02: Verwaltenund Aufrechterhalten der Sicherheitsmaßnahmen.Der Zugriff auf Software zur Überwachung, Bearbeitung oder Änderungvon Netzkonfigurationen oder -einheiten MUSS kontrolliertwerden, um die Störung des Netzbetriebs durch unbefugten Zugriffzu verhindernGrundlegender Aufgabenbereich(Dienstbetreiber: performt):Verwalten und Instandhalten aller Einheiten der Netzwerkinfrastruktur,die zur Verbindung des Netzwerks von Dienstbetreiber mitdem Netzwerk des spezifischen Dienstes zum Zweck der Servicebereitstellungeingesetzt werden könnenZugriff auf Netzwerksoftware:Auf Personen beschränkt, deren Aufgabenbereich die NetzwerkunterstützungumfasstRevalidierung der Zugriffsberechtigung:Im Abstand von drei MonatenOptionaler Aufgabenbereich(Dienstbetreiber: assistiert,gematik: performt):Identifizieren aller unternehmensübergreifenden Gateway-Servicesdes spezifischen Dienstes und der Benutzer, die zur Verwendungdieser Services berechtigt sindOptionaler Aufgabenbereich(Dienstbetreiber: performt):Verwalten und Aufrechterhalten der Sicherheitsmaßnahmen für dieBereitstellung der unternehmensübergreifenden Gateway-Servicesfür den spezifischen DienstesAnhangG 10AnhangG 10AnhangG 10AnhangG 10AnhangG 10AnhangG 10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 771 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03520 S Netzwerk_Unternehmensübergreifende_Services_03: IES-GatewaysA_03521 S Netzwerk_Unternehmensübergreifende_Services_04: KontrollanforderungenIES-GatewayA_03522 S Netzwerk_Unternehmensübergreifende_Services_05: Verwaltenund Aufrechterhalten der SicherheitsmaßnahmenA_03523 S Netzwerk_Unternehmensübergreifende_Services_06: Identifizierenund Authentifizieren vonBenutzern.A_03524 S Netzwerk_Unternehmensübergreifende_Services_07: SystematischeEinbruchsversuche aufIES-GatewayIES-Gateways MÜSSEN IES-spezifischen Kontrollanforderungenfür die Kontrolle von Informationen entsprechen, die für die Bereitstellungdes Dienstes oder andere durch das Management desDienstbetreibers freigegebene Zwecke über ein IES-Gateway ü-bertragen werdenOptionaler Aufgabenbereich(Dienstbetreiber: assistiert,gematik: performt):Autorisieren der Übertragung von Daten- oder Programmdateienzwischen den internen Systemen des spezifischen Dienstes undexternen Benutzern über ein IES-Gateway im Rahmen der Abnahmeder entsprechenden Konzepte durch die gematik.Optionaler Aufgabenbereich(Dienstbetreiber: performt):Verwalten und Aufrechterhalten der Sicherheitsmaßnahmen für dieBereitstellung der unternehmensübergreifenden Gateway-Servicesfür den spezifischen Dienstes Vor dem Aktivieren des Gateway-Services – Sicherstellen der Übereinstimmung des Gateways mitden definierten AnforderungenIdentifizieren und Authentifizieren von Benutzern:Alle im Sicherheitskonzept definierten KontrollenSystematische Einbruchsversuche auf IES-Gateway:Prozess zur Feststellung und BearbeitungAnhangG 10AnhangG 10AnhangG 10AnhangG 10AnhangG 10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 772 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03525 S Netzwerk_Unternehmensübergreifende_Services_08: Verbindungenzwischen Netzen,Systemen oder AnwendungenA_03526 S Netzwerk_Unternehmensübergreifende_Services_09: Übertrageneiner E-Mail über ein IES-GatewayA_03527 S Netzwerk_Unternehmensübergreifende_Services_10: Prüfen derID von Personen, die E-Mailsüber das IES-Gateway senden.A_03528 S Netzwerk_Unternehmensübergreifende_Services_11:Übertragenvon Daten- oder Programmdateienüber ein IES-GatewayA_03529 S Netzwerk_Unternehmensübergreifende_Services_12: Prüfen derID von Mitarbeitern des spezifischenDienstes, die Dateiübertragungenüber das IES-Gateway ausführen.A_03530 S Netzwerk_Unternehmensübergreifende_Services_13: Aktivitä-Verbindungen zwischen Netzen, Systemen oder Anwendungen:Prüfen der externen ID bei jeder „Aktivierung“ der VerbindungÜbertragen einer E-Mail über ein IES-Gateway:Nur insoweit erlaubt, wie es die dem Dienst entsprechenden Konzepteexplizit fordern.Prüfen der ID von Personen, die E-Mails über das IES-Gatewaysenden:Gemäß den Vorgaben im SicherheitskonzeptÜbertragen von Daten- oder Programmdateien über ein IES-Gateway:Alle im Sicherheitskonzept definierten KontrollenPrüfen der ID von Mitarbeitern des spezifischen Dienstes, die Dateiübertragungenüber das IES-Gateway ausführen:Gemäß den Vorgaben im SicherheitskonzeptAktivitätenprotokoll:Angeben von Datum und Uhrzeit, Identifikation des Absenderssowie der ZieladresseAnhangG 10AnhangG 10AnhangG 10AnhangG 10AnhangG 10AnhangG 10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 773 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quelletenprotokoll.A_03531 S Netzwerk_Unternehmensübergreifende_Services_14: Aufbewahrenvon Protokollen.A_03532 S Netzwerk_Unternehmensübergreifende_Services_15:Bestätigungder Einhaltung der definiertenAnforderungenA_03533 S Netzwerk_Unternehmensübergreifende_Services_16: Aufbewahrender Bestätigung der Einhaltungder definierten Anforderungen.A_03534 S Netzwerk_Unternehmensübergreifende_Services_17: Datenverbindungenzur Unterstützungder Auftraggeberumgebung.A_03535 S Netzwerk_Unternehmensübergreifende_Services_18: Verwaltenund Instandhalten aller Fire-Aufbewahren von Protokollen:3 Monate AnhangG 10Bestätigung der Einhaltung der definierten Anforderungen:Als Teil des regelmäßigen Reportings zur Einhaltung der SecuritySLAsAufbewahren der Bestätigung der Einhaltung der definierten Anforderungen:Aktueller plus vorheriger ZeitraumZur Unterstützung der Auftraggeberumgebung können ggf. Datenverbindungenzwischen den Netzwerken und Systemen der gematikund den Netzwerken und Systemen von Dienstbetreiber eingerichtetwerden. Diese Verbindungen gelten als IES-Verbindungenund MÜSSEN daher über IES-Gateways geführt und von Dienstbetreiberbereitgestellt werden. Ein IES-Gateway am Verbindungsendpunktbeim spezifischen Dienst ist nur dann erforderlich, wenner von diesem spezifischen Dienst gefordert wirdOptionaler Aufgabenbereich(Dienstbetreiber: performt ):Verwalten und Instandhalten aller Firewall- und Gateway-Einheiten, mit denen Verbindungen zwischen dem Netzwerk desAnhangG 10AnhangG 10AnhangG 10AnhangG 10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 774 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellewall- und Gateway-Einheiten.Dienstbetreibers und dem Netzwerk des spezifischen Diensteszum Zweck der Bereitstellung von Services hergestellt werdenA_03536 S Netzwerk_Unternehmensübergreifende_Services_19: Anforderungenfür die individuelle I-dentifikation und Zugriffsautorisierungam IES-Gateway.A_03537Netzwerk_UnternehmensübergreifSende_Services_20: Autorisierendes Zugriffs über ein IES-Gateway.Optionaler Aufgabenbereich(Dienstbetreiber: performt ):Anforderungen für die individuelle Identifikation und Zugriffsautorisierungam IES-GatewayOptionaler Aufgabenbereich(Dienstbetreiber: performt ):Autorisieren des Zugriffs über ein IES-Gateway durch DienstbetreiberMitarbeiterAnhangG 10AnhangG 10gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 775 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG11 - FirewallsEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 11.4.7 Network routing controls (Kontrollen für Netzwerkrouting).Firewalls sind Systeme, die dazu dienen, den unbefugten Zugriff auf ein privates Netzwerkoder aus einem privaten Netzwerk heraus zu verhindern. Firewalls können alsHardware und/oder Software implementiert werden. Häufig werden Firewalls dazu verwendet,den Zugriff unbefugter Internetbenutzer auf private Netzwerke zu verhindern, diemit dem Internet verbunden sind. Dies gilt insbesondere für Intranets. Alle Nachrichten,die in das Intranet gelangen oder das Intranet verlassen, MÜSSEN die Firewall passieren.Diese prüft jede Nachricht und blockiert Nachrichten, die nicht den festgelegten Sicherheitskriterienentsprechen.FirewallsOptionale AufgabenbereicheVerantwortungen (P = Performt, A = Assistiert)Bereitstellen von Firewall-ServicesDienstbetreiberPDie Firewall-Hosts dürfen ausschließlich der Bereitstellung der Firewallfunktionen dienen.Mit Ausnahme der Services, die in das empfohlene Produkt (und häufig in andere Produkte)integriert sind, dürfen die Firewall-Hosts keine weiteren Services bereitstellen, dienicht Teil des Basisbetriebssystems sind. Dies gilt insbesondere für Routing, DNS,SOCKS, Proxy-Server und Mail-Relay, es sei denn, diese Services stehen in direktemZusammenhang mit der Firewallfunktion (z. B. Benutzerauthentifizierung).FirewallsVerbindlicher WertFirewallsysteme Dienen ausschließlich der Bereitstellung der FirewallfunktionG11.1 - Benutzer-IDsAusgenommen sind Accounts, die für nicht transparente Outbound-Proxys angelegt wurden.Auf die Standards für solche Accounts wird im Abschnitt über Proxy-Server im Detaileingegangen.Benutzer-IDsBenutzeraccounts für das Firewall-Verbindlicher WertNur Administratorengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 776 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastruktursystemBenutzer-IDs• Beziehen sich auf bestimmte Person• Keine gemeinsame BenutzungGast-/Demo-Benutzer-IDsRoot/AdministratorInaktiviertKeine FernanmeldungenG11.2 Host-ServicesG11.2.1 - SystemservicesSystemservicesServices, die nicht mit Firewallfunktionen im ZusammenhangstehenVerbindlicher WertNicht ausführenG11.2.2 - FilterregelnFilterregeln für Firewalls bestimmen, welche Arten von Datenverkehr die Firewallumgebungpassieren können. Im Detail unterscheiden sich diese Filter von Installation zu Installation.Mit Änderungen ist zu rechnen. Die beste Methode zum Umgang mit diesenhäufigen Änderungen ist die separate Dokumentierung der detaillierten Konfiguration.Diese MUSS dann regelmäßig dem Auftraggeber zur Prüfung und zur Genehmigung vorgelegtwerden, ohne dass die grundlegende Sicherheitsvereinbarung geändert werdenmuss.FilterregelnBericht über ursprüngliche Konfiguration derFilterregelnFolgebericht über Konfiguration der FilterregelnWesentliche Änderungen auf Veranlassungvon DienstbetreiberWesentliche Änderungen auf Veranlassungder gematikGeringfügige Änderungen (z. B.: Änderungder IP-Adresse oder Ausdehnung der bestehendenFilterregeln auf neue Server)Änderungen entgegen der Empfehlung derDienstbetreiberVorübergehende Änderungen (z. B.: für Sys-Verbindlicher WertUnmittelbar nach der KonfigurationHalbjährlich und auf AnforderungSchriftliche Mitteilung an die gematikSchriftliche AnforderungFormlose AnforderungSchriftliche AnforderungEs ergeht keine formelle Mitteilung:gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 777 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturFilterregelntemmanagement oder Fehlerbestimmung)Verbindlicher Wert• Die Änderungen bestehenweniger als zwei Stunden• Der gesamte zusätzliche Datenverkehrin dem Zeitraum,in dem diese Änderungen bestehen,wird protokolliertAbwehr von SpoofingangriffenDie Konfiguration der Firewall MUSS Filter zur Abwehr von Spoofingangriffen umfassen,die folgende Mindestanforderung erfüllen: Datenverkehr an einer ungesicherten Schnittstelle,dessen Quellenadresse auf einen gesicherten Ursprung hinweist, MUSS zurückgewiesenwerden.Im Idealfall wird solcher „gespoofter“ Datenverkehr protokolliert. Wenn die Netzwerke jedochMaschinen umfassen, die u. U. in großem Umfang „gespoofte“ Pakete generieren,die die Protokollierung überfluten würden, wird die Protokollierung der Pakete nicht empfohlen,auch wenn diese auf jeden Fall abgeblockt werden müssen.Abwehr von SpoofingangriffenAbwehr von SpoofingangriffenVerbindlicher WertZurückweisen von Datenverkehr an ungesicherter Schnittstellemit gesichertem UrsprungSpoofingversucheProtokollierung (außer bei Eingang einer großer Zahl vonfalschen Alarmen)Global abzublockender und zu akzeptierender DatenverkehrViele Arten von Datenverkehr werden von der Firewall routinemäßig abgeblockt, weil derDatenverkehr falsch adressiert ist, auf Konfigurationsfehler in Maschinen außerhalb derFirewallumgebung zurückgeht. Das Abblocken dieses Datenverkehrs ist in einer Form zuprotokollieren, die nicht durch die Fülle wertloser Informationen in den Protokollen dieÜberwachung auf tatsächlich verdächtigen Datenverkehr erschwert.Ausnahmen regelt das Dokument Netzwerksicherheit [gemNWSich].Global abzublockender und zu akzeptierender DatenverkehrUnerwünschter BroadcastverkehrUnerwünschter MulticastverkehrUnerwünschter NetBios-VerkehrNicht wesentliche Kommunikation zwischen Fire-Verbindlicher WertKeine ProtokollierungKeine ProtokollierungKeine ProtokollierungKeine Protokollierunggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 778 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der Telematikinfrastrukturwallschnittstellen, die in der Firewall selbst erzeugt wird, aberdennoch den TCP/IP-Stack passiertVerkehr, der auf routinemäßige Routerkommunikation zurückgeht,z. B. Routermitteilungen, weitergeleitete Datagramme undHSRPAuflistung von zusätzlichem Datenverkehr in einer Liste „Rauschen“Nachricht „ICMP unreachable“Interne Kommunikation im IP-StackKeine ProtokollierungÄnderung der Listeund Benachrichtigungdes AuftraggebersOhne ProtokollierungakzeptierenOhne ProtokollierungakzeptierenG11.3 - Protokollieren von ZugriffsversuchenDie Firewallmaschine MUSS alle für das jeweilige Betriebssystem und das TCP/IP-Protokollfestgelegten Protokollierungsanforderungen erfüllen. Die Anforderungen in diesemAbschnitt beziehen sich auf die Protokollierung der eigentlichen Firewallfunktion.Diese Protokollierung MUSS auf Sitzungsebene erfolgen; die routinemäßige Protokollierungsämtlicher Pakete ist weder erforderlich noch sinnvoll.G11.3.1 - SystemzugriffsprotokolleDie Firewall SOLL alle Versuche, über eine „Trust“-Beziehung (sofern der Versuch nichtauf die Firewall-Software selbst zurückgeht) eine Verbindung zur Firewall herzustellenprotokollieren, wenn die ausgewählte Software eine solche Protokollierung durchführenkann.Der gesamte Datenverkehr, der von der Firewall abgewiesen und nicht als normales„Rauschen“ ausdrücklich von der Protokollierung ausgenommen ist (siehe oben), MUSSprotokolliert werden.G11.3.2 - AktivitätenprotokolleAlle Administratorzugriffe, bei denen die Firewallkonfiguration geändert wird, MÜSSENprotokolliert werden.Protokollieren von ZugriffsversuchenVerbindungsversuche über eine „Trust“-BeziehungGesamter Datenverkehr mit Ausnahme von „Rauschen“undAdministratorzugriff mit Änderung der FirewallkonfigurationVerbindlicher WertProtokollierenProtokollierenProtokollierengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 779 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG11.4 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03538 S Firewalls_01: Firewall trenntIntranet und Internet.A_03539 S Firewalls_02: Bereitstellen vonFirewall-ServicesFirewalls sind Systeme, die dazu dienen, den unbefugten Zugriffauf ein privates Netzwerk oder aus einem privaten Netzwerk herauszu verhindern. Firewalls können als Hardware und/oder Softwareimplementiert werden. Häufig werden Firewalls dazu verwendet,den Zugriff unbefugter Internetbenutzer auf private Netzwerkezu verhindern, die mit dem Internet verbunden sind. Dies gilt insbesonderefür Intranets. Alle Nachrichten, die in das Intranet gelangenoder das Intranet verlassen, MÜSSEN die Firewall passieren.Diese prüft jede Nachricht und blockiert Nachrichten, die nichtden festgelegten Sicherheitskriterien entsprechenOptionaler Aufgabenbereich(Dienstbetreiber: performt ):Bereitstellen von Firewall-ServicesAnhangG 11AnhangG 11A_03540 S Firewalls_03: Firewallsystemedienen ausschließlich der Bereitstellungder FirewallfunktionA_03541 S Firewalls_Benutzer_IDs_01:Benutzeraccounts für das Firewallsystemnur für AdministratorenA_03542 S Firewalls_Benutzer_IDs_02:Keine Gruppenaccounts.Firewallsysteme dienen ausschließlich der Bereitstellung der Firewallfunktion.Benutzeraccounts für das Firewallsystem: Nur AdministratorenBenutzer-IDs• Beziehen sich auf bestimmte Person• Keine gemeinsame BenutzungAnhangG 11AnhangG 11AnhangG 11gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 780 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03543 S Firewalls_Benutzer_IDs_03:Deaktivierung von Gast-/DemoBenutern.Gast-/Demo-Benutzer-IDs: InaktiviertAnhangG 11A_03544 S Firewalls_System_Services_IDs_0: Servicekonfiguration gemäßMinimalitätsprinzip.A_03545 S Firewalls_Filterregeln_01: Genehmigungund regelmäßigePrüfung des Regelwerkes.A_03546 S Firewalls_Filterregeln_02: Reportingdes initialen Regelwerkes.Services, die nicht mit Firewallfunktionen im Zusammenhang stehen: Nicht ausführenFilterregeln für Firewalls bestimmen, welche Arten von Datenverkehrdie Firewallumgebung passieren können. Im Detail unterscheidensich diese Filter von Installation zu Installation. Mit Änderungenist zu rechnen. Die beste Methode zum Umgang mit diesenhäufigen Änderungen ist die separate Dokumentierung der detailliertenKonfiguration. Diese MUSS dann regelmäßig dem Auftraggeberzur Prüfung und zur Genehmigung vorgelegt werden, ohnedass die grundlegende Sicherheitsvereinbarung geändert werdenmussBericht über ursprüngliche Konfiguration der Filterregeln :Unmittelbar nach der KonfigurationAnhangG 11AnhangG 11AnhangG 11A_03547 S Firewalls_Filterregeln_03: RegelmäßigesReporting der desRegelwerkes.Folgebericht über Konfiguration der Filterregeln:Halbjährlich und auf AnforderungAnhangG 11A_03548 S Firewalls_Filterregeln_04: Reportingwesentlicher Änderungendes Regelwerkes.Wesentliche Änderungen auf Veranlassung von Dienstbetreiber:Schriftliche Mitteilung an die gematikAnhangG 11gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 781 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03549 S Firewalls_Filterregeln_05: Anforderungwesentlicher Änderungendes Regelwerkes.Wesentliche Änderungen auf Veranlassung der gematik :Schriftliche AnforderungAnhangG 11A_03550 S Firewalls_Filterregeln_06: Anforderunggeringfügiger Änderungendes Regelwerkes.Geringfügige Änderungen (z. B.: Änderung der IP-Adresse oderAusdehnung der bestehenden Filterregeln auf neue Server):Formlose AnforderungAnhangG 11A_03551 S Firewalls_Filterregeln_07: Erfordernisder Schriftform beiRegeländerungen entgegenden Empfehlungen derDienstbetreiber.A_03552 S Firewalls_Filterregeln_08: Reportingbei temporären Regelwerksänderungen.A_03553 S Firewalls_Filterregeln_09: Anti-SpoofingMaßnahmen.A_03554 S Firewalls_Filterregeln_10: Implementierungder Anti-Spoofing Maßnahmen.A_03555 S Firewalls_Filterregeln_11: Protokollierungvon Spoofingversuchen.Änderungen entgegen der Empfehlung der Dienstbetreiber:Schriftliche AnforderungVorübergehende Änderungen (z. B.: für Systemmanagement oderFehlerbestimmung):Es ergeht keine formelle Mitteilung:• Die Änderungen bestehen weniger als zwei Stunden• Der gesamte zusätzliche Datenverkehr in dem Zeitraum, in demdiese Änderungen bestehen, wird protokolliertDie Konfiguration der Firewall MUSS Filter zur Abwehr von Spoofingangriffenumfassen.Abwehr von Spoofingangriffen:Zurückweisen von Datenverkehr an ungesicherter Schnittstelle mitgesichertem UrsprungSpoofingversuche:Protokollierung (außer bei Eingang einer großer Zahl von falschenAlarmen )AnhangG 11AnhangG 11AnhangG 11AnhangG 11AnhangG 11gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 782 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. QuelleA_03556 S Firewalls_Filterregeln_12:Konfiguration des Firewall-Logging.A_03557 S Firewalls_Filterregeln_13: Protokollierungvon Broadcastverkehr.A_03558 S Firewalls_Filterregeln_14: Protokollierungvon Multicastverkehr:A_03559 S Firewalls_Filterregeln_15: Protokollierungvon NetBios-Verkehr.A_03560 S Firewalls_Filterregeln_16: Protokollierung"unwesentlicher"Kommunikation.A_03561 S Firewalls_Filterregeln_17: Protokollierungvon Routerkommunikation.A_03562 S Firewalls_Filterregeln_18:Erstellen einer "Rausch-Liste".A_03563 S Firewalls_Filterregeln_19: Protokollierung„ICMP unreachable“A_03564 S Firewalls_Filterregeln_20: Protokollierunginterner Kommu-Viele Arten von Datenverkehr werden von der Firewall routinemäßigabgeblockt, weil der Datenverkehr falsch adressiert ist, aufKonfigurationsfehler in Maschinen außerhalb der Firewallumgebungzurückgeht. Das Abblocken dieses Datenverkehrs ist in einerForm zu protokollieren, die nicht durch die Fülle wertloser Informationenin den Protokollen die Überwachung auf tatsächlich verdächtigenDatenverkehr erschwertUnerwünschter Broadcastverkehr:Keine ProtokollierungUnerwünschter Multicastverkehr:Keine ProtokollierungUnerwünschter NetBios-Verkehr:Keine ProtokollierungNicht wesentliche Kommunikation zwischen Firewallschnittstellen,die in der Firewall selbst erzeugt wird, aber dennoch den TCP/IP-Stack passiert:Keine ProtokollierungVerkehr, der auf routinemäßige Routerkommunikation zurückgeht,z. B. Routermitteilungen, weitergeleitete Datagramme und HSRP:Keine ProtokollierungAuflistung von unerwünschtem und unwesentlichem Datenverkehrin einer Liste „Rauschen“:Änderung der Liste und Benachrichtigung des AuftraggebersNachricht „ICMP unreachable“:Ohne Protokollierung akzeptierenInterne Kommunikation im IP-Stack:Ohne Protokollierung akzeptierenAnhangG 11AnhangG 11AnhangG 11AnhangG 11AnhangG 11AnhangG 11AnhangG 11AnhangG 11Anhanggematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 783 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAfo-ID Anfo ArtTitel Beschreibung Rel. Quellenikation im IP-Stack. G 11A_03565 S Firewalls_Protokollierung_01:Konfiguration der Firewall;Protokollierung auf Sitzungsebene.A_03566 S Firewalls_Protokollierung_02:Protokollierung von Verbindungsversuchenüber trust-Beziehung.A_03567Firewalls_Protokollierung_03:S Vollständige Protokollierung.A_03568SFirewalls_Protokollierung_04:Protokollierung aller administrativenZugriffe, die die Firewallkonfigurationändern.Die Firewallmaschine MUSS alle für das jeweilige Betriebssystemund das TCP/IP-Protokoll festgelegten Protokollierungsanforderungenerfüllen. Die Anforderungen in diesem Abschnitt beziehensich auf die Protokollierung der eigentlichen Firewallfunktion.Diese Protokollierung MUSS auf Sitzungsebene erfolgen; die routinemäßigeProtokollierung sämtlicher Pakete ist weder erforderlichnoch sinnvollVerbindungsversuche über eine „Trust“-Beziehung:ProtokollierenGesamter Datenverkehr mit Ausnahme von „Rauschen“ : ProtokollierenAdministratorzugriff mit Änderung der Firewallkonfiguration: ProtokollierenAnhangG 11AnhangG 11AnhangG 11AnhangG 11gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 784 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG12 - SicherheitsüberprüfungenDie folgenden Leistungen des Dienstbetreibers dienen der Erkennung von TCP/IPSchwachstellen.G12.1 - Überprüfung auf TCP/IP-SchwachstellenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 12.6 Technical Vulnerability Management (Managementtechnischer Schwachstellen) und Ziffer 15.2.2 Technical compliance checking (Prüfungder Einhaltung technischer Normen).Das Ziel der Überprüfung auf TCP/IP-Schwachstellen ist die Feststellung möglicherSchwachstellen und Sicherheitsrisiken auf den Systemen und Servern.Hinweis: Der Einsatz von Tools für die Prüfung auf TCP/IP-Schwachstellen durch Personen,die nicht zum formalen Testteam gehören, ist untersagt. Die einzige Ausnahme bildenhierbei Personen, die ihr eigenes System testen.Überprüfung auf TCP/IP-SchwachstellenAusführen der Überprüfung auf TCP/IP-SchwachstellenVerbindlicher WertdurchzuführenG12.2 - Hostbasierte Erkennung von ManipulationenEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 12.4.1 Control of operational software (Kontrolle von Softwarein laufenden Systemen).Der hostbasierte Intrusion-Detection-Service (HIDS) installiert einen Agenten auf den zuschützenden Servern. Dieser Agent erkennt bekannte Angriffsmuster. Die Arbeit des A-genten nimmt nur einen kleinen Teil der Serverassets in Anspruch. Der große Vorteil vonHIDS besteht darin, dass in Echtzeit verdächtige Aktivitäten erkannt werden können, diemöglicherweise Anzeichen für einen Angriff sind.Hostbasierte Erkennung von ManipulationenDurchführen der hostbasierten Erkennung von ManipulationenVerbindlicher WertdurchzuführenG12.3 - SicherheitstestsDie nachfolgend beschriebenen technischen Tests und Prozessüberprüfungen MÜSSENwie angegeben durchgeführt werden.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 785 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG12.3.1 - Technische SicherheitstestsEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 15.2.2 Technical compliance checking (Prüfung und Einhaltungtechnischer Normen).Im Rahmen der technischen Tests sollen so viele Sicherheitsrisiken wie möglich ermitteltwerden, um die technische Sicherheit der Systeme und Netzwerke zu verbessern. Bei derDurchführung der technischen Überprüfung greift das Team u. U. auch auf Informationenzurück, die für Endbenutzer nicht zugänglich sind.Die folgende Liste enthält Beispiele für Sicherheitsrisiken:• Als Systemeinbruch werden die Umgehung der Zugriffskontrollsysteme sowieder unberechtigte Zugriff auf eine Benutzer-ID mit System- oder Sicherheitsadministratorberechtigungbezeichnet.• Als unbefugten Zugriff bezeichnet man den Zugriff auf eine Endbenutzer-IDoder vertrauliche Daten, für die keine Zugriffsrechte definiert wurden.• Eine Sicherheitslücke, die zur Serviceverweigerung (Denial of Service) führt,liegt dann vor, wenn das System seine eigentliche Funktion nicht mehr ausführenkann oder die normale Funktionsweise des Systems erheblich beeinträchtigtist.Technische SicherheitstestsDurchführen technischer SicherheitstestsVerbindlicher WertdurchzuführenG12.3.2 - Überprüfung der SicherheitsprozesseEntsprechende Anforderung gemäß ISO/IEC 27002:2005Diese Ziffer entspricht Ziffer 15.2.1 Compliance with security policy (Einhaltung der Sicherheitsvorschriften).Im Rahmen der Überprüfung soll festgestellt werden, ob die in diesem Standard definiertenProzesse implementiert, sowie überprüfbare Aufzeichnungen vorhanden sind.gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 786 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturG12.4 – Zusammenfassung der AusgangsanforderungenAfo-ID Anfo Art Titel Beschreibung Rel. QuelleA_03569A_03570A_03571A_03572A_03573SSSSSSicherheits_Prüfungen_01: Ü-berprüfung auf TCP/IP-Schwachstellen.Sicherheits_Prüfungen_02:Hostbasierte Erkennung von ManipulationenSicherheits_Prüfungen_03: Erkennungvon Sicherheitsrisikenim Rahmen technischer TestsSicherheits_Prüfungen_04:Durchführung Technische Sicherheitstests.Sicherheits_Prüfungen_05:Compliance Checks.Überprüfung auf TCP/IP-Schwachstellen ist durchzuführen.Hostbasierte Erkennung von Manipulationen ist durchzuführenIm Rahmen der technischen Tests sollen so viele Sicherheitsrisiken wiemöglich ermittelt werden, um die technische Sicherheit der Systeme undNetzwerke zu verbessern. Bei der Durchführung der technischen Überprüfunggreift das Team u. U. auch auf Informationen zurück, die fürEndbenutzer nicht zugänglich sindTechnische Sicherheitstests sind durchzuführen.Compliance mit der Security Policy:Im Rahmen der Überprüfung soll festgestellt werden, ob die in diesemStandard definierten Prozesse implementiert, sowie überprüfbare Aufzeichnungenvorhanden sindAnhangG 12AnhangG 12AnhangG 12AnhangG 12AnhangG 12gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 787 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAnhang ZZ1 - AbkürzungenKürzel2TDES3TDESACIAdVAESAMDOKAMTSANSIAPIATMAUTAVSBABÄKBDSGBfDIBMGBNetzABrokerSBSIC2CCACBCCCCE RouterCERTCRLCRUDLSErläuterungTriple-DES mit 112 Bit langem SchlüsselTriple-DES mit 168 Bit langem SchlüsselAccess Control InformationAnwendungen des VersichertenAdvanced Encryption StandardArzneimitteldokumentationArzneimitteltherapiesicherheit (-sprüfung)American National Standards InstituteApplication Programming InterfaceAsynchronous Transfer ModeAuthenticationApothekenverwaltungssystemBerufsausweisBundesärztekammerBundesdatenschutzgesetzDer Bundesbeauftragte für den Datenschutz und die InformationsfreiheitBundesministerium für GesundheitBundesnetzagenturBroker ServiceBundesamt für Sicherheit in der InformationstechnikCard to CardCertification AuthorityCipher Block ChainingCommon CriteriaCustomer Edge RouterComputer Emergency Response TeamCertificate Revocation ListCreate/Read/Update/Delete/List/Searchgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 788 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKürzelCVCVCDBDESDHCPDMZDNDNSDoSDSADSLDSSDTBSeGKeHCEVGFTPGAGKVGMGGSHBHBAHMACHPCHTTPHTTPSHWICCSNICMPIDEAIDSIEEEIESIETFErläuterungCard VerifiableCard Verifiable CertificateDatenbankData Encryption StandardDynamic Host Configuration ProtocolDemilitarisierte ZoneDistinguished NameDomain Name SystemDenial of ServiceDigital Signature AlgorithmDigital Subscriber LineDigital Signature StandardData to be signedelektronische Gesundheitskarteelectronic Health CardEvaluierungsgegenstand (Begriff aus CC; engl.: TOE)File Transfer ProtocolGesamtarchitekturGesetzliche KrankenversicherungGesetz zur Modernisierung der gesetzlichen KrankenversicherungGrundschutzhandbuch(elektronischer) Heilberufsausweis(Keyed-)Hash Message Authentication CodeHealth Professional CardHypertext Transfer ProtocolHypertext Transfer Protocol SecureHardwareIntegrated Circuit Card Serial NumberInternet Control Message ProtocolInternational Data Encryption AlgorithmIntrusion Detection SystemInstitute of Electrical and Electronics EngineersInter-Enterprise ServicesInternet Engineering Task Forcegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 789 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKürzelIPIPSIPSecISDNISOITKISKVKLANLDAPMACMBOMPLSMTBFMWNTPOCSPOFBOIDOSIOSRPINPKIPPPSPUKPVSQESRASReq.Res.RFCRSARTCErläuterungInternet ProtocolIntrusion Prevention SystemIP SecurityIntegrated Services Digital NetworkInternational Organization for StandardizationInformationstechnikKrankenhausinformationssystemHerkömmliche KrankenversichertenkarteLocal Area NetworkLightweight Directory Access ProtocolMessage Authentication CodeMusterberufsordnung für die deutschen Ärztinnen und ÄrzteMultiprotocol Label SwitchingMean Time Between FailuresMehrwertdienstNetwork Time Protocol, TheOnline Certificate Status ProtocolOutput FeedbackObject IdentifierOpen Systems InterconnectionOperation System RessourcePersönliche IdentifikationsnummerPublic Key InfrastructureProtection ProfilePrimärsystemPersonal Unblocking KeyPraxisverwaltungssystem (Primärsystem des Arztes)Qualifizierte elektronische SignaturRemote Access ServiceRequestResponseRequest for CommentsRivest Shamir AdlemanReal Time Clockgematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 790 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKürzelSAKSCSSDHSDSSGBSHASICCTSigGSigVSLASMCSM-AKSM-KSM-KTSM-NKSNMPSOAPSSCDSSHSSLSVSSWTCLTCP/IPTDTETITLSTOETRTRTSLTSPTUCErläuterungSignaturanwendungskomponenteSecurity Confirmation ServiceSynchronous Digital HierarchyService Directory ServiceSozialgesetzbuchSecure Hash AlgorithmSecure Interoperable ChipCard TerminalSignaturgesetzSignaturverordnungService Level AgreementSecurity Module CardSecurity Modul AnwendungskonnektorSecurity Modul KonnektorSecurity Modul KartenterminalSecurity Modul NetzkonnektorSimple Network Management ProtocolSimple Object Access ProtocolSecure Signature-Creation DeviceSecure ShellSecure Socket LayerSecurity Validation ServiceSoftwareTrusted Component ListTransmission Control Protocol/Internet ProtocolTamper Detection, Common Criteria AusdruckTamper Evidence, Common Criteria AusdruckTelematikinfrastrukturTransport Layer SecurityTarget of Evaluation (Begriff aus CC)Technische RichtlinieTamper Resistance, Common Criteria AusdruckTrusted-Service ListTrust-service providerTechnischer Use Casegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 791 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturKürzelTZIUDDIUDPUFSURIUSBVLANVODDVODMVPNVSDDVSDMWANWBEMWLANWTXXMLZPOErläuterungTelematikzulassungsinfrastrukturUniversal Description, Discovery and IntegrationUser Datagram ProtocolUpdate Flag ServiceUniform Resource IdentifierUniversal Serial BusVirtual Local Area NetworkVerordnungsdatendienstVerordnungsdatenmanagementVirtual Private NetworkVersichertenstammdatendienstVersichertenstammdatenmanagementWide Area NetworkWeb-Based Enterprise ManagementWireless Local Area Network (Wireless LAN)Waiting time extentionExtensible Markup LanguageZivilprozessordnungZ2 - GlossarDas Projektglossar wird als eigenständiges Dokument zur Verfügung gestellt.Begriff Englisch, (Abk.) Definition (Synonym)BrokerdiensteDatenklasseBroker (i. e. S.) und AuditSEine Datenklasse ist eine Menge von Informationsobjektenmit gleichartigen Eigenschaften.Leistungserbringer (LE) Organisation oder Person, die Leistungen des Gesundheitswesensfür Versicherte erbringen kann. Im Sinnevon HL7 ist ein Leistungserbringer eine Teilnahme einerRolle (z. B. Heilberufler) an einem Prozess (z. B. VerschreibungRezept). Beispiele sind Ärzte, Zahnärzte,Apotheker, psychologische Psychotherapeuten undKinder- und Jugendlichenpsychotherapeuten (Psychotherapeuten),Krankenhäuser und sonstige Leistungserbringer.Der Begriff „Leistungserbringer“ wird im Rahmendes Projekts eGK als Akteur verwendet.MechanismenstärkeBewertung der Wirksamkeit von SicherheitsmechanismenWiderstand gegen einen direkten Angriff zuleisten. Für die Stärke der Mechanismen sind mehreregematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 792 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Begriff Englisch, (Abk.) Definition (Synonym)Stufen definiert, die ein Maß für das Vertrauen sind,inwieweit die beschriebenen Sicherheitsmechanismen inder Lage sind, direkten Angriffen zu widerstehen.Übergreifendes Sicherheitskonzept der TelematikinfrastrukturSchlüssel-ErzeugungSchlüssel-RegistrierungEr wird von einer Registrierungsinstanz angeboten undwird üblicherweise angewandt, wenn symmetrischeKryptographie benutzt wird. Wenn eine Entität einenSchlüssel registrieren lassen will, kontaktiert sie dieRegistrierungsinstanz. Schlüssel-Registrierung beinhalteteine Registrierungsanforderung und eine Bestätigungdieser Registrierung. Eine Registrierungsinstanzpflegt ein Register von Schlüsseln und die dazugehörigenInformationen in hinreichend sicherer Art und Weise.Zertifikats-ErzeugungGenerate-KeyRegister-KeyCreate-Key-CertificateDienst des Schlüsselmanagements (siehe [ISO11770])Schlüssel-Erzeugung: Schlüssel-Erzeugung ist einDienst, der aufgerufen wird um auf sicherem WegeSchlüssel für einen bestimmten kryptographischen Algorithmuszu erzeugen. Dies erfordert, dass die Schlüsselerzeugungnicht manipulierbar sein darf und dass dieSchlüssel nicht vorhersagbar und in der vorgeschriebenenstatistischen Verteilung erzeugt werden müssen.Diese statistischen Verteilungen sind vom verwendetenkryptographischen Schlüssel erzwungen und von gefordertenNiveau des kryptographischen Schutzes.Die Erzeugung mancher Schlüssel, z. B. Master-Keys,erfordert besondere Sorgfalt und besonderen Schutz, dadie Kenntnis dieser Schlüssel Zugriff auf die verbundenenoder abgeleiteten Schlüssel ermöglicht.Dienst des Schlüsselmanagements (siehe [ISO11770])Der Dienst Schlüssel-Registrierung verbindet einenSchlüssel mit einer Entität.Dienst des Schlüsselmanagements (siehe [ISO11770])Erzeugung eines Schlüssel-Zertifikats: Der Dienst Registrierungeines Erzeugung eines Schlüssel-Zertifikatsverbindet einen öffentlichen Schlüssel mit einer Entitätund wird von einer Zertifizierungsinstanz betrieben.Wenn eine Anforderung zur Schlüssel-Zertifizierungakzeptiert wird, erzeugt die Zertifizierungsinstanz einSchlüssel-Zertifikat.Schlüssel-Verteilung Distribute-Key Dienst des Schlüsselmanagements (siehe [ISO11770])Die Schlüssel-Verteilung ist eine Menge von Prozessenum Schlüssel-Management-Information-Objekte (in derRegel Schlüssel) sicher zu autorisierten Entitäten zuverteilen.Schlüssel-InstallationInstall-KeyDienst des Schlüsselmanagements (siehe [ISO11770])Der Dienst Schlüsselinstallation ist immer vor demGebrauch eines Schlüssels notwendig. Bei der Schlüsselinstallationwird der Schlüssel in einer Art und Weisegematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 793 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturBegriff Englisch, (Abk.) Definition (Synonym)eingebracht, die den Schlüssel vor Kompromittierungschützt.Schlüssel-Ableitung Derive-Key Dienst des Schlüsselmanagements (siehe [ISO11770])KMS 7 Schlüssel-Ableitung: Der Dienst Schlüssel-Ableitung erstellt eine potentiell große Anzahl vonSchlüsseln unter Benutzung eines geheimen Originalschlüsselsgenannt Ableitungsschlüssel, nicht geheimenveränderlichen Daten und mit einem Transformationsprozess(der nicht immer geheim sein muss). Das Ergebnisdieses Prozesses ist der abgeleitete Schlüssel.Der Ableitungsschlüssel erfordert besonderen Schutz.Der Ableitungsprozess MUSS unumkehrbar und nichtvorhersehbarsein um sicherzustellen, dass die Kompromittierungeines abgeleiteten Schlüssels nicht denAbleitungsschlüssel oder andere abgeleitete Schlüsselkompromittiert.Schlüssel-SpeicherungDer Dienst Schlüssel-Speicherung bietet sichere Speicherungfür Schlüssel im laufenden oder kurz bevorstehendenGebrauch oder auch für Backup-Schlüssel. Esist üblicherweise von Vorteil physikalisch getrennteSchlüssel-Speicher vorzusehen. Zum Beispiel sichertein Schlüssel-Speicher die Vertraulichkeit und Integritätvon Schlüsselmaterial oder die Integrität von öffentlichenSchlüsseln. Speicherung kann in allen Schlüsselzuständenim Lebenszyklus eines Schlüssels vorkommen.Schlüssel-ArchivierungSchlüssel-SuspendierungStore-KeyArchive-KeyRevoke-KeyDienst des Schlüsselmanagements (siehe [ISO11770])Dienst des Schlüsselmanagements (siehe [ISO11770])Schlüssel-Archivierung: Schlüssel-Archivierung ist derProzess Schlüssel nach Ablauf der Nutzung sicher undlangfristig zu speichern. Für diesen Dienst ist die Anwendungdes Dienstes “Schlüssel-Speicherung” denkbar,es bestehen aber verschiedene Anforderungen, sodass auch verschiedene Implementierungen denkbarsind. So könnte z. B. die Schlüssel-Archivierung offlinerealisiert werden. Archivierte Schlüssel können nochlange nach dem normalen Gebrauch der Schlüssel benötigtwerden, um bestimmte Ansprüche abzuklärenDienst des Schlüsselmanagements (siehe [ISO11770])Wenn die Kompromittierung eines Schlüssels bekanntist oder vermutet wird, stellt der Dienst Schlüssel-Suspendierung die sichere Deaktivierung des Schlüsselssicher. Der Dienst ist auch für Schlüssel, derenGültigkeit abgelaufen ist, notwendig. Schlüssel-Suspendierung wird auch dann angewandt, wenn sichdie Rahmenbedingungen beim Schlüsselinhaber ändern.Nach der Suspendierung kann der Schlüssel nureingeschränkt benutzt werden (In der Regel nicht mehrum zu verschlüsseln oder zu signieren, aber derSchlüssel darf gebraucht werden um zu entschlüsselnoder zu verifizieren). Der Grad der SuspendierungMUSS genau beschrieben werden, wie auch die Um-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 794 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturBegriff Englisch, (Abk.) Definition (Synonym)stände unter denen der Schlüssel wieder aktiviert werdenkann.Der Dienst Schlüssel-Suspendierung wird kaum beizertifikatbasierten Schemata angewandt, wo der Lebenszyklusder Schlüssel durch die Gültigkeit der Zertifikategeregelt wird.Schlüssel-DeregistrierungSchlüssel-ZerstörungDeregister-KeyDestroy-KeyDienst des Schlüsselmanagements (siehe [ISO11770])Der Dienst Aufheben der Registrierung eines Schlüsselswird von einer Registrierungsinstanz angeboten, die dieVerbindung des Schlüssels mit einer Entität aufhebt.Er ist Teil des Schlüssel-Zerstörungsprozesses. Wenneine Entität die Registrierung eines Schlüssels aufhebenlassen will, kontaktiert sie die Registrierungsinstanz.Dienst des Schlüsselmanagements (siehe [ISO11770])Der Dienst Schlüssel-Zerstörung bietet einen Prozessan, für die sichere Zerstörung von Schlüssel die nichtmehr gebraucht werden. Zerstörung eines Schlüsselsheißt, alle Einträge des Schlüsselmanagement-Informationsobjekts zu löschen, so dass nach der Zerstörungkeine Information übrig bleibt um den zerstörtenSchlüssel wiederherzustellen.Dies wird gemacht um die Zerstörung aller archiviertenKopien sicherzustellen. Dennoch, bevor archivierteSchlüssel zerstört werden, sollte eine Prüfung gemachtwerden um sicherzustellen, dass kein Material dasdurch diese Schlüssel geschützt wird jemals wiedergebraucht wird.NOTIZ: Es können Schlüssel außerhalb von elektronischenGeräte oder Systemen gespeichert sein. Daserfordert zusätzliche administrative Maßnahmen.Z3 - AbbildungsverzeichnisAbbildung 1: Einordnung und Abgrenzung dieses Dokumentes...........................................18Abbildung 2: Anforderungen des Datenschutzes und der Sicherheit....................................24Abbildung 3: Strategie zur Begrenzung der Restrisiken........................................................34Abbildung 4: Zwei-Karten-Prinzip.........................................................................................37Abbildung 5: Relevante Komponenten und Dienste in den Verteilungsschichten derTelematikinfrastruktur....................................................................................................45Abbildung 6: Übersicht Gesamtarchitektur...........................................................................47Abbildung 7: Übersicht über Infrastrukturkomponenten und Telematiknetz..........................48Abbildung 8: Roadmap für die Umsetzung der Sicherheitsstrategie.....................................49Abbildung 9: Überblick über die Berechtigungsbehandlung..................................................73Abbildung 10: Datenorte und ihre Systemgrenzen...............................................................75Abbildung 11: Verwendung der Sicherheitsdienste und Sicherheitsfunktionen aufAnwendungsebene.......................................................................................................81Abbildung 12: Architektur-Tiers und Systemgrenzen............................................................87Abbildung 13: Exemplarische Zuordnung von Komponenten zu Zonen................................88Abbildung 14: Zusammenhang von Schichten/Tiers und Zonen...........................................90gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 795 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturAbbildung 15: Zonenkonzept................................................................................................94Abbildung 16: Erlaubte Übergänge zwischen Top-Level Zonen.........................................108Abbildung 17: Zuordnung der Komponenten zu Sicherheitszonen.....................................113Abbildung 18: Erlaubte Informations- und Nachrichtenflüsse für das Request/Response-Interaktionsmuster.......................................................................................................116Abbildung 19: Rechteverwaltung........................................................................................123Abbildung 20: Kryptographische Algorithmen in der Telematikinfrastruktur........................131Abbildung 21: Migrationsplanung der Kartengenerationen und der zugehörigen Algorithmen.....................................................................................................................................132Abbildung 22: Sicherheitspolicy und Risikomanagement....................................................165Abbildung 23: Übersicht Zulassungsverfahren...................................................................182Abbildung 24: Struktur und Aufbau der Zulassung.............................................................183Abbildung 25: Detaillierte Darstellung des Zulassungsverfahrens......................................185Abbildung 26: Übersicht über die Teststufen......................................................................186Abbildung 27: Einordnung und Abgrenzung der Anforderungen des Datenschutzes..........207Abbildung 28: Anforderungen des Datenschutzes und der Sicherheit................................208Abbildung 29: Datenklassen...............................................................................................459Abbildung 30: Rollenhierarchie...........................................................................................459Abbildung 31: Einordnung der Policy für PIN, PUK in das Sicherheitskonzept...................470Abbildung 32: Anforderungen an die Stärke der einzusetzenden Authentifizierungsverfahren(siehe Rahmenarchitektur)..........................................................................................475Abbildung 33: Verwendung der Sicherheitsdienste und Sicherheitsfunktionen aufAnwendungsebene.....................................................................................................524Abbildung 34: Migrationsplanung bei Änderung von Krypto-Algorithmen der eGK.............525Abbildung 35: Nutzung eines Algorithmus für Dokumentensignatur und Authentisierung...533Abbildung 36: Kryptographische Algorithmen in der Telematikinfrastruktur........................535Abbildung 37: Migrationsplanung der Kartengenerationen und der zugehörigen Algorithmen.....................................................................................................................................536Abbildung 38: Sicherheitsdienste und Sicherheitsfunktionen auf Anwendungsebene.........547Abbildung 39: Struktur der PKI mit TSL und beteiligten Akteuren [gemX509_TSP]............548Abbildung 40: Kryptographisch gesicherte Verbindungen auf Netz- und Transportebenezwischen den verschiedenen Sicherheitszonen..........................................................555Abbildung 41: Struktur der PKI mit TCL und beteiligten Akteuren.......................................556Abbildung 42: Lebenszyklus der Schlüssel und die Übergänge zwischen den Zuständeneines Schlüssels.........................................................................................................568Abbildung 43: Betriebsphasen im Schlüssellebenszyklus und Keymanagement-Dienste nachISO 11770l..................................................................................................................571Abbildung 44: Verantwortlichkeiten und Komponenten der Key-Management-Infrastrukturder Telematikinfrastruktur im Gesundheitswesen........................................................573Z4 - TabellenverzeichnisTabelle 1: Normative Festlegungen des Sicherheitskonzepts der gematik...........................22Tabelle 2: Kategorien von Anwendungen.............................................................................62Tabelle 3: Sicherheitsbedingungen der Kategorien..............................................................63Tabelle 4: Schutzbedarf übergreifender fachlicher Datenklassen in der Telematikinfrastruktur......................................................................................................................................66Tabelle 5 - Prinzipien Berechtigungsmodell..........................................................................69Tabelle 6: Schutzbedarf übergreifender technischer Datenklassen in derTelematikinfrastruktur....................................................................................................85Tabelle 7: Bildung von Zonentypen durch Kombination von Topologie-Eigenschaften.........89gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 796 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 8: Topologie-Eigenschaften.....................................................................................91Tabelle 9: Bildung von Zonentypen durch Kombination von Topologie-Eigenschaften.........91Tabelle 10: Anwendertypen..................................................................................................92Tabelle 11: Typen des Datenflusses....................................................................................92Tabelle 12: Schutzstufen für Zonenübergänge.....................................................................92Tabelle 13: Nummerierung und Bezeichnung der Subzonen................................................93Tabelle 14: Zone 1 - Dezentral Extern..................................................................................95Tabelle 15: Zone 2 - Zentral Extern......................................................................................96Tabelle 16: Zone 3 - Zentral Intern.......................................................................................97Tabelle 17: Zone 4 - Zentral Backend Intern........................................................................98Tabelle 18: Zone 5 - Dezentral Backend Extern...................................................................99Tabelle 19: Zone 6 - Mehrwertdienste................................................................................100Tabelle 20: Top-Level Zonenübergänge ohne Sicherheitsanforderungen..........................108Tabelle 21: Anforderungen an die Zonenübergänge..........................................................110Tabelle 22: Normative Zuordnung der Komponenten zu Sicherheitszonen........................113Tabelle 23: Schutzbedarf Service- und ObjektTicket..........................................................119Tabelle 24: Sicherheitsanforderungen an Tickets...............................................................120Tabelle 25: Grundlegende Anforderungen .........................................................................129Tabelle 26: Risikoklassen...................................................................................................176Tabelle 27: Eintrittswahrscheinlichkeiten für Restrisiken....................................................177Tabelle 28: Eckpunkte des Datenschutzes.........................................................................209Tabelle 29: Anforderungen des Datenschutzes an die Prozessgestaltung und dieFachkonzepte.............................................................................................................214Tabelle 30 - Anforderungen und Funktionen für Pflichtanwendungen.................................223Tabelle 31 - Anforderungen und Funktionen für freiwillige Anwendungen..........................224Tabelle 32: Anforderungen des Datenschutzes an die Gesamtarchitektur .........................227Tabelle 33: Schadenskategorieren.....................................................................................332Tabelle 34: Informationsobjekte.........................................................................................442Tabelle 35: Alle Datenklassen und ihre Beschreibung........................................................455Tabelle 36: Fachliche Aktionen..........................................................................................457Tabelle 37: Zuordnung fachlicher Aktionen........................................................................458Tabelle 38: Berechtigungsrichtlinie: geschützte VSD auf der eGK.....................................461Tabelle 39: Berechtigungsrichtlinie: geschützte VSD im Fachdienst...................................462Tabelle 40: Berechtigungsrichtlinie: VOD auf eGK.............................................................463Tabelle 41: Berechtigungsrichtlinie: VOD im Fachdienst....................................................463Tabelle 42: Berechtigungsrichtlinie: Auditdaten..................................................................465Tabelle 43: Berechtigungsrichtlinie: Notfalldaten auf eGK..................................................465Tabelle 44: Berechtigungsrichtlinie: Notfalldaten im Fachdienst (Back-up).........................466Tabelle 45: Berechtigungsrichtlinie: AMTS im Fachdienst..................................................467Tabelle 46: Schutzbedarf und Verantwortliche für PIN, PUKs ...........................................471Tabelle 47: Schutzbedarf und Verantwortliche der Schlüssel für die PIN, PUKs ................471Tabelle 48: Abgeleitete Anforderungen aus BSI TR-03116 für die Migrationkryptographischer Verfahren in der Telematikinfrastruktur..........................................526Tabelle 49: Anforderungen an die Migrationsfähigkeit der Krypto-Komponenten undSicherheitsdienste.......................................................................................................527Tabelle 50: Diffie Hellman Gruppen für den Schlüsseltausch.............................................530Tabelle 51: Kryptographische Identitäten Webservice Security..........................................552Tabelle 52: Zulässige Verwendung Kryptographischer Identitäten.....................................553Tabelle 53:Typen von Einsatzumgebungen........................................................................561Tabelle 54: Sicherheitsstufen physikalische Sicherheit der Geräte.....................................562Tabelle 55: Arten des Transports von Schlüsselmaterial....................................................562Tabelle 56: Übergänge zwischen den Zuständen eines Schlüssels realisiert durchSchlüsselmanagementdienste (siehe [ISO11770])......................................................571Tabelle 57: Wegweiser durch prototypische Lebenszyklen ................................................617gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 797 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturTabelle 58: Lebenszyklus Objektschlüssel zur Verschlüsselung medizinischer Daten.......618Tabelle 59: Umsetzung Schutzbedarf Objektschlüssel zur Verschl. medizinischer Daten..620Tabelle 60 Lebenszyklus des Kartenindividuellen CAMS-Schlüssels.................................622Tabelle 61: Umsetzung Schutzbedarf Kartenindividueller CAMS-Schlüssel.......................626Tabelle 62: Lebenszyklus des Privaten Schlüssel der eGK zur Authentifikation.................629Tabelle 63: Umsetzung Schutzbedarf Privater Schlüssel der eGK zur Authentikation........631Tabelle 64: Lebenszyklus des Privaten CVC Schlüssel der eGK zur Authentifikation.........634Tabelle 65: Umsetzung Schutzbedarf Privater CVC Schlüssel der eGK.............................636Tabelle 66: Lebenszyklus des Privaten Schlüssel der HBA zur QES .................................638Tabelle 67: Umsetzung des Schutzbedarfs Privater Schlüssel der HBA zur QES..............641Tabelle 68: Lebenszyklus der Passwörter für User und Admin Kartenterminal...................644Tabelle 69: Hinweis auf Umsetzung des Schutzbedarfs Passwörter für User und AdminKartenterminal.............................................................................................................645Tabelle 70: Lebenszyklus der Passwörter für Admin-Passwort Konnektor.........................645Tabelle 71: Hinweis Umsetzung Schutzbedarf Admin-Passwort Konnektor .......................646Tabelle 72: Lebenszyklus des Privaten Schlüssel zur Authentisierung im TLS-ProtokollKonnektor ...................................................................................................................647Tabelle 73: Umsetzung Schutzbedarf Privater Schlüssel zur TLS Authentisierung Konnektor....................................................................................................................................648Z5 - Referenzierte DokumenteQuelleANSI INCITS359-2004ApBetrOb4h_SiArchBDSGBNetzABNetzA_ESESHerausgeber (Erscheinungsdatum): TitelR. Sandhu, D. Ferraiolo, R. Kuhn (2004): American NationalStandard for Information Technology-Role Based Access Control(RBAC), INCITS 359-2004Bundesgesetzblatt I (1987), 547: Verordnung über den Betriebvon ApothekenProjektgruppe bIT4health: Rahmenarchitektur der Telematik-Plattform im Gesundheitswesen (2004),http://www.dimdi.de/dynamic/de/ehealth/karte/downloadcenter/technik/rahmenarchitektur/telematik_rahmenaktuell/Der Bundesbeauftragte für Datenschutz und Informationsfreiheit(20.12.1990 (neugefasst durch Bek. 14.01.2003, geändert durch§13 Abs.1 vom 05.09.2005):BundesdatenschutzgesetzBundesnetzagentur für Elektrizität, Gas, Telekommunikation,Post und Eisenbahnen (02.02.2006), Bekanntmachung zur e-lektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung(Übersicht über geeignete Algorithmen), vom 2.Januar 2006, veröffentlicht am 23. März 2006 im BundesanzeigerNr. 58, S. 1913-1915, viahttp://www.bundesnetzagentur.de/media/archive/5951.pdfBundesnetzagentur für Elektrizität, Gas, Telekommunikation,Post und Eisenbahnen (19.07.2005), Einheitliche Spezifizierungder Einsatzbedingungen für Signaturanwendungskomponenten -Arbeitsgrundlage für Entwickler/Hersteller und Prüf- / Bestäti-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 798 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturQuelleHerausgeber (Erscheinungsdatum): Titelgungsstellen, Version 1.4, Stand: 19.07.2005Brainpool ECC Brainpool Standard Curves and Curve Generation v. 1.019.10.2005http://www.teletrust.de/fileadmin/files/oid/oid_ECC-Brainpool-Standardcurves-V1.pdfBSI BSI (12.2005):BSI-Standard 100-2, IT-Grundschutz-Vorgehensweise (Version1.0)BSILFBSI TR-03116BSI TR-03111BSI, IT Sicherheit auf Basis der Common Criteria - ein Leitfaden(31.10.2007)http://www.bsi.bund.de/cc/cc_leitf.pdfBSI TR-03116, Technische Richtlinie für die eCard-Projekte derBundesregierung, Version: 1.0, Datum: 23.03.2007, Fassung:2007BSI TR-03111, Technical Guideline TR-03111, Elliptic CurveCryptography, Based on ISO 15946, Version 1.00, 14.02.2007,Initial public version.BSI_GK BSI (2005):IT-Grundschutz-Kataloge;http://www.bsi.bund.de/gshb/deutsch/index.htm (zuletzt geprüftam 14.12.2006)BSI-PP-0008BWB02DINSIG-4Commom Criteria Schutzprofil Benutzerbestimmbare Informationsflusskontrolle2002): Zertifizierungs-ID BSI-PP-0008, Identifikator01345-BISS-MU, Version 2.01M. Bultmann, R. Wellbrock, H. Biermann, J. Engels, W. Ernestus,U. Höhn, R. Wehrmann, A. Schurig. (2002) Datenschutz undTelemedizin – Anforderungen an Medizinnetze, Konferenz derDatenschutzbeauftragten des Bundes und der Länder[DINSIG-4] Chipcards with digital signature application/functionaccording to SigG and SigV, Part 4: Basic Security Services,September 14th 2001gemFK_ADV gematik (09.01.2008): Einführung der Gesundheitskarte -Fachkonzept Anwendungen des Versicherten (ADV)Version 2.0.1, www.gematik.degemFK_AMTS gematik (Draft 2007): Einführung der Gesundheitskarte -Fachkonzept Arzneimitteltherapiesicherheitsprüfung(in Vorbereitung)gemFK_NFDM gematik (02.10.2007): Einführung der Gesundheitskarte -Fachkonzept Daten für die NotfallversorgungVersion 1.3.0gemFK_VFA gematik (04.04.2007): Einführung der Gesundheitskarte -Fachkonzept Verwaltung freiwilliger AnwendungenVersion 1.0.0gemFK_VODM gematik (27.02.2008): Einführung der Gesundheitskarte -Fachkonzept Verordnungsdatenmanagement,gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 799 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturQuelleHerausgeber (Erscheinungsdatum): TitelVersion 2.5.0, www.gematik.degemFK_VSDM gematik (28.02.2008): Einführung der Gesundheitskarte -Fachkonzept Versichertenstammdatenmanagement,Version 2.7.0, www.gematik.degemGesArch gematik (18.03.2008): Einführung der Gesundheitskarte -Gesamtarchitektur,Version 1.3.0gemNTP gematik (04.05.2007): Einführung der Gesundheitskarte -Spezifikation Infrastrukturkomponenten: ZeitdienstVersion 1.2.0, www.gematik.degemNWSich gematik (04.05.2007): Einführung der Gesundheitskarte -Spezifikation NetzwerksicherheitVersion 1.1.0, www.gematik.degemSiKo_offlinegemSpec_eGK_P1gemSpec_eGK_P2gematik (2006): Sicherheitskonzept-Release-1-OFFLINE, V1.0.9(nicht öffentlich)gematik (20.03.2008): Einführung der Gesundheitskarte –Die Spezifikation elektronische Gesundheitskarte;Teil 1 – Spezifikation der elektrischen SchnittstelleVersion 2.2.0, www.gematik.degematik (25.03.2008): Einführung der Gesundheitskarte –Die Spezifikation elektronische Gesundheitskarte ;Teil 2 – Grundlegende ApplikationenVersion 2.2.0, www.gematik.degemSpec_FM gematik (18.12.2007): Einführung der Gesundheitskarte -Spezifikation FehlerbehandlungVersion 1.3.0gemSpec_Kon gematik (26.03.2008): Einführung der Gesundheitskarte -Konnektorspezifikation,Version 2.6.0gemSpecKrypt gematik (26.03.2008): Einführung der Gesundheitskarte -Spezifikation Kryptographischer Algorithmen,Version 1.3.0gemSpec_KT gematik (26.03.2008): Einführung der Gesundheitskarte –eHealth-Kartenterminal,Version 2.6.0, www.gematik.degemSpec_Ticket gematik (12.12.2007): Einführung der Gesundheitskarte -Spezifikation TicketserviceVersion 1.2.0gemSProf_ID gematik (24.08.2007): Einführung der Gesundheitskarte -Sicherheitsprofil für die TelematikinfrastrukturdiensteVersion 1.0.0gemX.509_TCL gematik (19.03.2008): Einführung der Gesundheitskarte –PKI für X.509-Zertifikate, Konzept und Registrierungsanforderungenfür die Trusted Component List (TCL), Versi-gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 800 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

QuelleHerausgeber (Erscheinungsdatum): Titelon:1.2.0gemX.509_TSL gematik (15.12.2005): Einführung der Gesundheitskarte -Festlegung einer einheitlichen X.509-Zertifikatsinfrastruktur(TSL), Version 1.0.0Übergreifendes Sicherheitskonzept der TelematikinfrastrukturGrundsatzentscheidungISO10181-3Grundsatzpositionen und –entscheidungen zu Telematikanwendungender Gesundheitskarte,Version 0.5.5 vom 18.07.2005ISO/IEC 10181-3 (1996): Security Frameworks for Open Systems:Access control frameworkISO11770 ISO/IEC 11770: 1996Information technology - Security techniques - Key managementPart 3: Mechanisms using asymmetric techniquesISO13335 ISO/IEC TR 13335;Umfassende Sammlung von 5 Normdokumenten zum Managementvon InformationssicherheitISO27002 ISO/IEC 27002:2005Information technology - Security techniques - Code of practicefor information security managementISO18014 ISO/IEC 18014-1: Information technology - Security techniques -Time stamping services - Part 1: Framework, 2002ISO27001 ISO/IEC 27001:2005Information technology - Security techniques - Information securitymanagement systems – RequirementsprEN14890-1EUROPEAN STANDARD, DRAFT, prEN 14890-1, February2007, Application prEN14890-Interface for smart cards used assecure signature, creation devices – Part 1: Basic servicesRFC2119 RFC 2119 (März 1997):Key words for use in RFCs to Indicate Requirement LevelsS. Bradner, http://www.ietf.org/rfc/rfc2119.txt (zuletzt geprüft am14.12.2006)RFC2246 RFC 2246: Jan. 1999The TLS Protocol, Version 1.0http://www.ietf.org/rfc/rfc2246.txt (zuletzt geprüft am 14.12.2006)SICCTSigG01TeleTrusT (19.12.2006): SICCT Secure Interoperable ChipCardTerminal, Version 1.10http://www.teletrust.de/fileadmin/files/publikationen/Spezifikationen/SICCT_Spezifikation_1.10.pdf(zuletzt geprüft am14.12.2006)Bundesgesetzblatt I (2001), S.876:Gesetz über Rahmenbedingungen für elektronische Signaturenund zur Änderung weiterer Vorschriften (Signaturgesetz - SigG)SigV01 Bundesgesetzblatt I (2001), S. 3074:Verordnung zur elektronischen Signatur – SigVSP800-57NIST, August 2005, Recommendation on Key Management,gematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 801 von 802Version: 2.2.0 © gematik Stand: 10.03.2008

Übergreifendes Sicherheitskonzept der TelematikinfrastrukturQuelleBMG_PatRechteBDSGBWB02Dat07GMK99GrundsatzentscheidungRichtlinie95/46/EGRPGATG Pseudo2004gemX.509PolVersHerausgeber (Erscheinungsdatum): TitelPart 1: GeneralPart 2: Best Practices for Key Management Organizationhttp://csrc.nist.gov/publications/nistpubs/index.htmlBMG. Patientenrechte in DeutschlandBundesdatenschutzgesetzM. Bultmann, R. Wellbrock, H. Biermann, J. Engels, W. Ernestus,U. Höhn, R. Wehrmann, A. Schurig. Datenschutz und Telemedizin- Anforderungen an Medizinnetze. 2002Artikel 29-Datenschutzgruppe. WP 131, Arbeitspapier Verarbeitungvon Patientendaten in elektronischen Patientenakten (EPA).200772. Gesundheitsministerkonferenz. Patientenrechte in Deutschlandheute. 1999Grundsatzpositionen und –entscheidungen zu Telematikanwendungender Gesundheitskarte, Version 0.5.5 vom 18.07.2005Richtlinie 95/46/EG des Europäischen Parlaments und des Ratesvom 24. Oktober 1995 zum Schutz natürlicher Personen beider Verarbeitung personenbezogener Daten und zum freien DatenverkehrA. Roßnagel, A. Pfitzmann, H. Garstka. Modernisierung des Datenschutzes.Gutachten im Auftrag des Bundesministeriums desInnern.ATG-Managementpapier Pseudonymisierung / Anonymisierung,Köln, den 16.03.2004,http://ehealth.gvgkoeln.de/xpage/objects/pseudonymisierung/docs/5/files/MP040316.pdfFestlegungen zu den X.509 Zertifikaten der Versicherten, Version:1.2.0, Stand: 02.10.2006, Status: freigegebengematik_DS_Sicherheitskonzept_V2_2_0.doc Seite 802 von 802Version: 2.2.0 © gematik Stand: 10.03.2008