Das kann ich zurück geben: Rechnen Sie doch mal vor, wie sie mit einem Individualgehäuse, Individual-Mainboard (es sind 3 SIM-Steckplätze vorhanden, die es auf Massenware so nicht gibt), Versiegelung und auditierter Fertigungsstrecke mit sicherer Lieferkette bei vergleichsweise geringer Stückzahl auf weniger kommen?
1 Mitglied findet das Top!
1 Mitglied hat sich bedankt!
Ich gebe gerne zu, dass Sicherheit Geld kostet wenn man dazu für jedes kleinste Detail Zertifizierung benötigt. Es gibt aber schon etliche Standards ins Sachen Sicherheit und man muss das Rad nicht immer neu erfinden. Das System ist so lange und langsam und groß gewachsen, dass ich mir sicher bin, dass die Sicherheit hier ein gutes Stück leidet. Je komplexer Systeme desto anfälliger. Jetzt mit der TI 2.0 zu versuchen das einigermaßen zu modernisieren halte ich für den falschen Weg. Man müsste eigentlich bei 0 anfangen. Für E-Mails brauche ich keine Zertifizierung von Software, wenn das nicht durchweg bis zum Endsystem geht. Wo ist der Sinn eines zertifizierten KIM Client Moduls? Das dazu noch in Java von IBM entwickelt ist und sich komplett disassemblieren lässt. Wow, es nützt das Zertifikat der smc-b. Dafür bedarf es keiner Zertifizierung das zu erkennen, denn dafür sind Signatur und Verschlüsselungsverfahren schließlich da.
Es zeichnet sich doch gerade ab, dass jeder versucht, die eingebaute Sicherheit so gut es geht auszuhebeln,damit man das System überhaupt nutzen kann. Wie sicher ist denn ein nicht Zertifizierungspflichtiger TIaaS Anbieter? Da bleibt eben ich nur vertrauen. Vor allem wenn dann noch KIM as a service angeboten wird und somit alle Daten erstmal unverschlüsselt auf einem Server des Anbieters gelangen. Dann hätte man auch gleich das ganze wie eidas Fernsignatur machen können und hatte sich viel Overhead gespart. Ich habe jedenfalls kein gutes Gefühl angesichts der Zahl der Personen, die als Administrator in den Rechenzentren Zugriff auf Konnektoren im Namen der Ärzte etc haben. Denn für den Endanwender oder auch den PVS Hersteller gibt es keine Möglichkeit zu prüfen, ob für die smc-b und den hba noch weitere Zugangsdaten angelegt wurden. Und ist die Karte erstmal freigeschaltet, sind ja schon viele Dinge möglich.
Das das Symptom der verkorksten Spezifikation jetzt mit Drittsoftware und Beratern kompensiert wird, kann man doch nicht ernst nehmen. Ich habe auf jeden Fall nicht das beste Gefühl bei dem riesen undurchsichtigen System und warte eigentlich täglich auf weitere Sicherheitsprobleme die z.B. dann auch Mal Kernsysteme betreffen. Ich hoffe nicht dass das passiert, aber ich würde nicht drauf wetten wollen.
Aber sie wie es ist. Man wird als PVS Anbieter damit leben müssen und für die Konvenience der Kunden eben workarounds für die Sicherheit schaffen müssen, um am Markt bestehen zu können. Spätestens bei den kleinen PVS, die sich die Expertise in Sachen Sicherheit nicht leisten können, wird es früher oder Sicherheitsvorfälle geben. Und bei jedem wird auf die TI als allgemeines Konstrukt auch ansehen verlieren.
Und noch eine Ergänzung zur Gelddruckmaschine: wer kam denn auf die glorreiche Idee, dass auf den Konnektoren Software laufen muss, für die der Versicherte indirekt regelmäßig teure Updates zahlen muss? Warum kann das Ding nicht nur ein von Gateway sein und die eigentlichen Endpunkte auf einem Server im TI Netz laufen? Das reduziert die Komplexität und Anfälligkeit der Konnektoren um ein Vielfaches und ist deutlich wartungsärmer. Und ja, das hätte man auch vor dem TI 2.0 Konzept wissen können!
Ich verstehe Ihren Frust und es gibt sicher viel zu verbessern. Auch ist es sicherheitstechnisch nicht nachvollziehbar, warum der KIM-Client keine Sicherheitsprüfung erfährt. Allerdings sind in Ihren Ausführungen doch viele Fehlannahmen und -aussagen enthalten... da komme ich kaum hinterher und ich weiß auch nicht, ob Sie diese (derzeit) überhaupt hören wollen? 😉 Dennoch ein paar Stichworte:
Es gibt Standard in Sicherheit. Diese werden angewandt, deswegen ist es ja so aufwändig & teuer
Softwarekonnektoren wurden schon vor 15 Jahren diskutiert - und immer wieder aus Sicherheitsgründen (vorrangig durch das BSI) verworfen
Nicht die Hardware macht den Konnektor so teuer, sondern die CC-zertifizierte Software. Daher ist ein SW-Konnektor kaum billiger (kann sogar teurer werden)
Konnektorfunktionen auf zentrale Dienste auszulagern wird mittlerweile wohl auch durch das BSI akzeptiert. Lösung kommt.
Sie können aber nicht alles auf zentral auslagern. Die Ver- und Entschlüsselung z.B. über einen zentralen Dienst laufen zu lassen ist offensichtlich keine gute Idee.
Konnektor-Administratoren können weder Daten abgreifen noch den Sicherheitszustand der Karten nachnutzen. Auch nicht, wenn der Konnektor beim Hoster steht. (technisch verhindert).
Das TI-Gesamtsystem mit den Anwendungen liefert Betriebsmodi, die sicher sind. Natürlich kann man als Nutzer Systeme auch trotzdem unsicher einsetzen. Das liegt dann aber nicht am System sondern am Nutzer - und dieser haftet dann auch, wenn was passiert (wenn Sie den PIN der Alarmanlage neben das Eingabefeld der Anlage heften, ist nicht die Anlage unsicher).
Generell ist es so, dass viele komplexen Systeme aus der Ferne einfach wirken. "Das kann doch nicht so schwer sein". oder "Das geht doch viel einfacher" ist dann schnell gesagt. Kommt man näher ran zeigt sich aber wie immer: "Der Teufel steckt im Detail". Wir hatten bereits 2008 ein Moratorium der TI, bei dem einige Externe meinten, das Konstrukt der TI sei viel zu komplex, es ginge viel einfacher. Das Konzeptpapier dieser Truppe zur "Neuausrichtung" hatte 20 Seiten. Super. Alles ganz einfach. Dann gingen sie damit zum BSI und BfDI. Danach hatte das Papier 200 Seiten und sah - oh Wunder - genauso aus, wie die TI zuvor. Und das waren keine Dummköpfe, die sich mit der Neuausrichtung beschäftigt hatten.
Ja, heute würde und könnte man einige Dinge anders und einfacher machen. REST als Schnittstelle ganz vor mit dabei. Aber um einige grundlegende Dinge käme man auch bei einem heutigen Neuanfang nicht drum herum - angefangen mit den eGKs als Basis-Authentisierungsmittel für Versicherte... was natürlich zu Kartenterminals führt... und diese dann verwaltet werden müssen...
Und glauben Sie mir: Ich bin einer der ersten, wenn es darum geht das Sicherheitsniveau der TI und ihrer Anwendungen endlich auf ein vernünftiges Maß zu reduzieren, was a) hinreichend ist b) zu guter Usability führt und c) bezahlbar bleibt. Dazu sind aber grundlegende gesetzliche Änderungen nötig. Es gibt einige, die das seit Jahren versuchen. Raten Sie mal wer da dabei ist. Nur hat es bislang nicht geklappt. Mal schauen, was mit der neuen Regierung möglich sein wird...
ZitatKonnektor-Administratoren können weder Daten abgreifen noch den Sicherheitszustand der Karten nachnutzen. Auch nicht, wenn der Konnektor beim Hoster steht. (technisch verhindert).
Das bitte einmal ausführen! Ich kann im Konnektor das Infomodell anpassen und neue Zugangsdaten hinterlegen, ohne dass die SMC-B gesperrt wird. Für das sperren der SMC-B aus dem Konnektor heraus besteht meiner Kenntnis nach keine Schnittstelle. Ich kann auch die Authentifizierung des Konnektors vollständig abschalten und dann anfragen machen. Die Identifikation findet ja nur über die 3 Parameter des Infomodells in der SOAP Anfrage statt! Da die SMC-B für mehere Stunden/Tage entsperrt bleibt, sehe ich hier also ein Sicherheitsproblem!
Zusätzlich dazu soll KIM as a Service angeboten werden. Dass das ein Sicherheitsproblem ist, brauch ich hoffentlich nicht erklären! Es gibt keine Möglichkeit zu prüfen, welches KIM Clientmodul auf der Gegenseite läuft. Ein Admin kann hier also auch Daten ausleiten oder KIM Nachrichten im Namen der Leistungserbringer verschicken.
Oder liege ich so daneben?!
Zitat angefangen mit den eGKs als Basis-Authentisierungsmittel für Versicherte
Wie kommt es, dass ich als Versicherter meine ePA einfach über mein Smartphone aufrufen kann, ohne mein eGK zu benötigen oder ein VPN aufbauen zu müssen. Der Leistungserbringer aber muss 1 Konnektor, 1 KT, 5 Karten und ein "sicheren" VPN Zugang haben?! Ja ich weiß dass die Smartphoneanbindung auf drängen von Herrn Spahn schnell gehen musste, aber wenn man da die Sicherheit einhalten kann, ist es dann beim Leistungserbringer nicht etwas "too much"?
P.S.: Vielen Dank übrigens Ihnen, dass Sie sich der Fragen und "Kritik" (die ja nicht an Sie gestellt ist) annehmen und antworten!
Zitat von dhpvs im Beitrag #38Ich kann im Konnektor das Infomodell anpassen und neue Zugangsdaten hinterlegen, ohne dass die SMC-B gesperrt wird. Für das sperren der SMC-B aus dem Konnektor heraus besteht meiner Kenntnis nach keine Schnittstelle.
Stimmt, da haben Sie Recht, ich muss meine vorherige Aussage korrigieren: Die SMC-B ist beim Konnektor bewusst offen für alle Primärsysteme, die in dem als vertrauenswürdig definierten LAN der Praxis laufen (kann auf bekannte PVS im LAN innerhalb des Konnektors eingeschränkt werden). Aber zwischen diese PVS sollte der Sicherheitszustand der SMC-B bewusst geshared werden. Für den HBA gilt das nicht, der ist an den individuellen Aufrufkontext gebunden, den das PVS festlegt (auf Ebene der UserID). Aber die SMC-B ist offen. Sperren kann man eine SMC-B, in dem man sie z.B. ejected - aber das hilft gegen dieses Admin-Problem nicht weiter.
Zitat von dhpvs im Beitrag #38Zusätzlich dazu soll KIM as a Service angeboten werden. Dass das ein Sicherheitsproblem ist, brauch ich hoffentlich nicht erklären! Es gibt keine Möglichkeit zu prüfen, welches KIM Clientmodul auf der Gegenseite läuft. Ein Admin kann hier also auch Daten ausleiten oder KIM Nachrichten im Namen der Leistungserbringer verschicken.
Da haben Sie natürlich grundsätzlich Recht.
Beide Punkte sind ein gutes Beispiel, warum der Konnektor und das KIM-Clientmodul konzeptionell in der Praxis verortet sind. Aber natürlich darf ich Datenverarbeitung zu einem Dienstleister auslagern (entsprechende Verträge vorausgesetzt). Ich sollte dann dem Betreiber entsprechend vertrauen. Diese Risikoentscheidung dazu trifft der Praxisinhaber. Das Risiko entsteht also erst durch die Delegation, die der verantwortliche Praxisinhaber vornehmen kann - aber eben nicht muss.
Zitat von dhpvs im Beitrag #38Wie kommt es, dass ich als Versicherter meine ePA einfach über mein Smartphone aufrufen kann, ohne mein eGK zu benötigen oder ein VPN aufbauen zu müssen. Der Leistungserbringer aber muss 1 Konnektor, 1 KT, 5 Karten und ein "sicheren" VPN Zugang haben?!
Noch besteht dieser Unterschied, weil der Arzt sich "frei" innerhalb der TI bewegen darf und dort innerhalb des sicheren Netzes (welches er über VPN erreicht) jede Anwendung aufrufen kann (eRezept, ePA, KIM, ...). Der Versicherte kann dies nicht: Über die ePA-App erreicht er genau nur das Zugangsgateway seines ePA-Providers, keine anderen TI-Dienste. Diese Verbindung ist TLS gesichert. Um sich gegenüber dem ePA-Provider sicher zu authentisieren, benötigt der Versicherte entweder seine eGK oder eine sogenannte "alternative Versichertenidentität" (al.vi), die im Rahmen der ePA-Kontoeröffnung für ihn angelegt werden kann. Al.vi verwendet für die Authentisierung gegenüber dem ePA-Provider die gleiche Zertifikatstechnik wie die eGK, nur der private Schlüssel liegt bei einem Dienstleister der Kassen (im Signaturdienst) im dortigen HSM. Erreichen / nutzen kann man die dortigen Schlüssel nur über ePA-App nach erfolgreicher Authentisierung gegenüber dem Dienst (also kein Zugriff auf diese Schlüssel durch den dortigen Admin). Dazu verwendet die ePA-App, bzw. der Versicherte, eine 2-Faktor-Authentisierung, die im Rahmen der Registrierung aufgebaut wird. Daher ist es auch unerlässlich, dass der Versicherte im Rahmen der Kontoeröffnung sicher identifiziert wird - daher persönliche Vorstellung in der Geschäftsstelle oder Video-Ident (plus Eingabe der eGK-Kartennummer).
Zitat von FS007 im Beitrag #39Interessant ist aber die Frage, ob der Zugang des Versicherten zu "seiner" ePA wirklich so sicher ist, oder ob es nicht doch möglich ist, sich auch andere ePA's anzusehen ???
Ja es ist sicher und nein ich kann nicht auf unberechtigte ePAs zugreifen. Das das Gesamtverfahren technisch abgesichert ist, haben diverse Stellen konzeptionell geprüft und im Rahmen der Umsetzung wird bis auf Codeebene geprüft, dass die Vorgaben eingehalten werden. Das alles wie immer im Leben: 100% Sicherheit gibt es nirgends. Aber wir reden hier von einem erreichten Sicherheitsniveau, welches Sie sonst bei keiner anderen Software erleben werden, mit der Sie beruflich oder privat arbeiten.
Zitat von FS007 im Beitrag #41Die Titanic war auch unsinkbar .... bis zum Untergang.
Die Aussage "unsinkbar" kam damals von der Presse, nicht vom Hersteller! 😉
Zitat von FS007 im Beitrag #41Wie sieht es aus, wenn das Handy bei Ebay verhöckert wird ?
Kein Problem, da zum Öffnen der ePA-App bzw. zum Öffnen des dahinterliegenden Kontos ja noch der AppCode / Fingerprint eingegeben werden muss, mit dem die alternative Versichertenidentität (al.vi) abgesichert ist - oder eben die eGK zu nutzen ist, wenn der ePA-Anwender nicht al.vi, sondern die eGK zur Authentisierung verwendet. Keins von beidem (AppCode / Fingerprint oder eGK) wird der Verkäufer dem Käufer mitgeben 😉
Mal ganz abgesehen davon, dass man heutzutage wissen sollte, dass man ein Handy zurücksetzt, bevor man es weiterverkauft...
Zitat von MLangguth im Beitrag #42Zitat von FS007 im Beitrag #41Wie sieht es aus, wenn das Handy bei Ebay verhöckert wird ?
Man braucht das Handy ja gar nicht aktiv verkaufen- "ungewollter Verlust/Diebstahl" kommt ja noch als weiteres RIsiko dazu - und da wäre ggf. die KVK ja gleich "drive by download" (aus der Handtasche des Betroffenen;-) mit an Bord und somit ggf. schon hierüber problemlos Feuer frei für einen Ausflug auf die ePA des Bestohlenen...
=)=) bei ungewolltem Verlust sollte somit meine ich schon eigentlich dann ein Verfahren greifen, dass der Zugang zur ePA umgehend gesperrt werden kann , so wie ich ja auch bei der Bank sperren kann, wenn ich die EC Karte verliere- ..Frage wäre: ist dieser Prozess eigentlich von der Theorie her irgendwo festgelegt und beschrieben und wenn ja wo? Und gibt es hier für den Patienten auch einen guten lesbaren Flyer ohne allzuviel Bleiwüste? Kennt jemand einen Link dazu?
TI-Community
»
Hersteller- und Zulassungsthemen
»
Konzepte, Spezifikationen, Richtlinie
»
Primärsystem Verbindung Konnektor
Thema drucken
18.11.2021 21:57 (zuletzt bearbeitet: 16.05.2022 11:42)
Antworten
aus der Handtasche des Betroffenen;-) mit an Bord und somit ggf. schon hierüber problemlos Feuer frei für einen Ausflug auf die ePA des Bestohlenen... 