VonDoczuDoc.de

Hallo zusammen,

habe gerade die (nicht ganz) neuen IT Sicherheitsrichtlinie der KBV durchgearbeitet. Die meisten Anforderungen treffen frühestens ab 1.4.2021 zu. Die einzige Regel, die für unsere Praxis bereits jetzt (seit 1.1.2021) zutrifft ist folgende:

ANLAGE 5: ANFORDERUNGEN FÜR DEZENTRALE KOMPONENTEN DER TELEMATIK INFRASTRUKTUR Punkt 5
Dies ist bei uns nicht so konfiguriert! Der Zugriff von Turbomed auf den Konnektor erfolgt derzeit ohne Authentifizierung. Hat jemand das bereits eingestellt? Wenn ja - wie?

Grüße

lcer

Ich bin froh, wenn das Ding überhaupt läuft!

Ich muß zur Zeit jeden Tag die Box neu starten, da die Scheißkiste zickt! Ich werde nichts unternehmen. Wenn das jemand prüfen sollte, werde ich an Turbomed verweisen.

Es fängt ja schon damit an, dass der Internetexplorer beim Zugriff auf das Webinterface des Konnektors meckert. Das ist ja auch kein Wunder, da sich der Konnektor mit "DNS: konnektor.konlan" identifiziert. Mein lokales Praxisnetz hat aber einen anderen Namen. Wie bringt man das in Ordnung? Nein, das Praxisnetz benenne ich nicht um.

Der Versuch, den öffentlichen Konnektorschlüssel selbst zu signieren (mit eigener CA) und dort den richtigen CN ("konnektor.praxislan") einzutragen hat zwar geklappt, der IE ist aber immer noch unglücklich. Vermutlich habe ich das Zertifikat an den falschen Ort (in Windows) importiert. Hat jemand einen Lösungsvorschlag bzw. weiss, wie man es "richtig" macht?

Im zweiten Schritt kann man darüber nachdenken, wie sich die Praxisrechner gegenüber dem Konnektor identifizieren. Selbst signierte Zertifikate mit public-key (pc1.crt) sowie die dazugehörigen private-keys (pc1.pfx) wären schon vorhanden.


Wer sich mit Schlüsseln und Zertifikaten auseinandersetzen will, kann sich openssl ansehen. Das ist eigentlich recht verständlich dokumentiert.
Beispiele findet man z.B. dort http://www.eclectica.ca/howto/ssl-cert-howto.php

Im Konnektor-Adminhandbuch stehen auf den Seiten 86 bis 91 ein paar dürftige Infos. Wie auf der Windows-Seite (Client) zu verfahren ist bleibt unklar.

Falls TLS aktiviert wird, müssen entsprechende Konfigurationen am Clientsystem vorgenommen werden. 88

88 Diese sind dem jeweiligen Handbuch zu entnehmen.

Zur Abbildung 53: Wozu brauche ich einen Benutzernamen, wenn nur ein Clientsystem authentifiziert werden soll? Ein Userpasswort für Clientaccounts hat im Konnektor nichts verloren. Genausowenig sollte der Konnektor über die zugehörigen privaten Schlüssel der Clientzertifikate verfügen - das ist aber unvermeidbar, wenn man die Zertifikate im Konnektor erzeugen lässt.

Wer authentifiziert den Konnektor? Oder ist der über jeden Zweifel erhaben? Ein Export des Konnektor-Zertifkats ist nicht beschrieben (oder ich habe es überlesen). Das kann man sich aber aus der HTTPS Verbindung (bei der Zertifikatswarnung) abspeichern.

Wichtig ist, dass Clientsystem-ID und Clientsystem-Bezeichnung im Infomodell identisch sind.

Also soll der CN des Zertifikats nur auf den Clientnamen lauten, genauso wie im Infomodell angegeben. Dort heisst mein Rechner "PC1" (alles Großbuchstaben). Eigentlich hätte ich erwartet, dass ich das Zertifikat auf CN = "pc1.praxislan" erstelle. Das ist vermutlich doppelt falsch.

Mal wieder mehr Fragen als Antworten. Insbesondere die Windowsseite... oder ist gar Turbomed auch noch beteiligt?
Wie veranlasse ich Windows dazu, meine Zertifikate für TLS (mit dem Konnektor) zu verwenden?

Hallo,

die handbuchseiten habe ich auch gefunden. Irgendwo anders war noch zu finden, dass die Kocobox Zertifikat um privaten Schlüssel als PKCS#12 speichert.

Im Turbomed findet sich in den Einstellungen des Konnektors die Möglichkeit von HTTP auf HTTPS oder HTTPS mit Clientzertifikat umzustellen. Dort kann dan ein Zertifikatsverzeichnis angegeben werden. In welcher Form die Zertifikate dort liegen müssen, ist leider nicht angegeben. Benötigt wird ja der Private Schlüssel, das Clientzertifikat und ggf noch das CA-Zertifikat. Rumprobieren wird da nicht helfen...

Grüße

lcer

Da steht doch "Zertifikate oder Username und Passwort" - müsste es mir nochmal ansehen, aber die Clients kommunizieren m.E. nicht ohne Authentifizierung.
Allerdings wird die Kommunikation nicht TLS-verschlüsselt - aber das sind zwei getrennte Dinge (ja ok, bei TLS kann ich mich auch in gewisser Weise autorisieren, wenn ich eben nur ein bestimmtes akzeptiere).
Anmeldung über Zertifikat ist auch möglich - so macht es ja das Konfig-Tool, wenn man es für die Ersteinrichtung verwendet. Aber ob das von TM überhaupt unterstützt...? Die eigentliche Autorisierung der Clients erfolgt ja dadurch, dass man sie im System anlegt, den Kartenleser pairt und den Stationen zuweist ... so ähnlich.

Lange Rede ... ich erinnere mich noch gut, dass im CGM-TI-Kurs einer der esten Schritte bei der Einrichtung war, TLS (bzw verschlüsselt) auf "nein" zu setzen

Vielleicht werfe ich mal nacher einen Blick rein ...

@bofh: wäre mir neu, dass man das Zertifikat der Box ändern kann. Sie meinen das, für die Admin-Oberfläche? m.E. nach ist es DAS Zertifikat der Box, das bei der Herstellung draufgepackt wurde (und die Lebenszeit beschränkt - nämlich mit Ablauf des Zertifikats). Ja, ist aber traurig dass es nicht vertrauenswürdig ist und wenn ich mich recht entsinne nicht nur, weil es auf den falschen Namen lautet.

Ja, ich meine das von der Admin-Oberfläche. Das Zertifikat der Box kann man natürlich nicht ändern **. Genau genommen ist das Zertifikat der öffentliche Schlüssel eines Schlüsselpaares, der von einer CA (hier GEM.KOMP-CA1) signiert wurde. Wenn man das Zertifikat der GEM.KOMP-CA1 aktiv zu den vertrauenswürdigen Root-Zertifkaten auf dem Windows-PC hinzufügt, dann wird das Konnektor-Zertifikat als gültig signiert angesehen. Allerdings meckert der Internetexplorer dann immer noch, da der Name (CN) des Konnektors mit "konnektor.konlan" nicht mit der Erwartung des Internetexplorers ("konnektor.praxislan") übereinstimmt.

Was man jedoch tun kann, ist den öffentlichen Schlüssel aus dem Konnektor-Zertifikat zu extrahieren und diesen dann neu zu signieren (mit eigener CA). Dabei kann man dann auch den CN passend abändern. Nur ist mir nicht gelungen, dies dem Internetexplorer wieder unterzuschieben. Das kann vermutlich auch nicht funktionieren, da dieser vermutlich das Zertifikat direkt vom Konnektor abholt und nicht nach passendem Zertifikat (mit gleichem Hashwert und Schlüssel) in den PC-Zertifikaten sucht. Das ganze war eher Spielerei um OpenSSL besser kennenzulernen.

nmndoc hat geschrieben:Die eigentliche Autorisierung der Clients erfolgt ja dadurch, dass man sie im System anlegt,

Das kann ja nur bei der Anbindung des Konnektors an TurboMed implizit erfolgt sein. Ich kann mich aber an die einzelnen Schritte in TurboMed nicht mehr genau erinnern. Sie meinen jetzt hoffentlich nicht das Info-Modell?

Das Konfig-Tool hatte ich noch nie am Laufen. CGM-TI-Kurs, welch Luxus...

lcer hat geschrieben:Im Turbomed findet sich in den Einstellungen des Konnektors

Danke für den Hinweis. Dann muss ich mal wieder das Programm selbst bemühen. Ich darf das nur administrieren und muss zum Glück nicht täglich damit arbeiten - wobei die Tage ohne sehr akute Probleme auch immer weniger werden. Vollständige Offline-Doku sollte zwingend vorgeschrieben werden. Gibt es nicht inzwischen eine DIN oder ISO, die das verlangt?

lcer hat geschrieben:Benötigt wird ja der Private Schlüssel, das Clientzertifikat und ggf noch das CA-Zertifikat. Rumprobieren wird da nicht helfen...

Rumprobieren nicht unbedingt, aber das bringt mich auf eine Idee. Ich lasse mir vom Konnektor einen Zertifikatssatz für einen Client erzeugen. Den kann man sich dann genau ansehen bzw. erst mal verwenden, bis das System läuft. Dann kann man immer noch abändern (wenn man DANN noch Lust hat).

** Gegebenenfalls hat CGM ein Tool dafür. Sonst geht in 2 Jahren der Tausch los. 4 Jahre und 5 Monate nach Übergabe läuft es ab. Durchschnittliche 4 Jahre und 10 Monate hätten es wohl sein sollen. Darf ich dann mit dem neuen Konnektor den Durchschnitt bilden?

Hallo,

Vorsicht - die Dinge hier nicht durcheinanderschmeißen. Der Konnektor benutzt verschiedene Zertifikate:

1) Das "TI-Zertifikat" mit dem er sich gegenüber der TI authentifiziert. Dieses kann man nicht ändern, meins läuft 2022 aus
2) Das "HTTPS-Zertifikat". Das ist das, was man im Internetbrowser sieht. Es dient nur für den HTTPS-Server für die Benutzeroberfläche des Konnektors. Dieses kann man im Konnektor ändern.
3) Die Zertifikate für den Clientzugriff - hier durch Turbomed. Um die geht es hier. Diese kann man vom Konnektor generieren lassen oder auf ihn hochladen. Wenn man sie auf dem Konnektor generiert, kommt man aber über die Benutzeroberfläche nicht ran. Die müssen anders heruntergeladen werden. Aber wie?

Wenn man die Zertifikate nicht herunterladen kann, bleibt nur der weg über selber-generieren und hochladen. Doch dann muss man die passenden Zertifikate auf den Turbomed-Server bringen. Aber wohin und wo in welcher Form? Diese Zertifikate haben übrigends nicht mit irgendwelchen anderen Zertifikaten des Turbomed-Servers zu tun.

Grüße

lcer

kurzer Nachtrag,

ich habe folgende Anleitung gefunden https://www.solutio.de/fileadmin/datens ... _9_8_6.pdf

dort werden einige TSL-Anbindungsfragen erhellt. Im Gegensatz zu Turbomed ist dort offen auch ein Passwort für den Zertifikatscontainer vorgesehen.

Grüße

lcer

lcer hat geschrieben:2) Das "HTTPS-Zertifikat". Das ist das, was man im Internetbrowser sieht. Es dient nur für den HTTPS-Server für die Benutzeroberfläche des Konnektors. Dieses kann man im Konnektor ändern.

Danke für die klare Unterscheidung. Wie kann man das im Konnektor ändern?

lcer hat geschrieben:3) Die Zertifikate für den Clientzugriff - hier durch Turbomed. Um die geht es hier. Diese kann man vom Konnektor generieren lassen oder auf ihn hochladen. Wenn man sie auf dem Konnektor generiert, kommt man aber über die Benutzeroberfläche nicht ran. Die müssen anders heruntergeladen werden. Aber wie?

Gleich nachdem man ein Clientzertifkat im Konnektor erzeugen lässt (Verwaltung -> Clientsysteme -> Zugangszertifikat hinzufügen) kommt bei mir automatisch ein Downloadfenster, mit dem ich ein Clientname.zip herunterladen kann. Das funktioniert wohl nur einmalig. Im Zip ist ein Clientname.p12 und ein passwort.txt (für das p12). Das Zertifikat ist nur auf den reinen Clientnamen (ohne Domäne) ausgestellt. Der Konnektor nennt sich darin "KoCoBox". Das caClient Zertifikat ist mit im p12 enthalten (KoCoBox ist darin CA).

Hallo,

Gleich nachdem man ein Clientzertifkat im Konnektor erzeugen lässt (Verwaltung -> Clientsysteme -> Zugangszertifikat hinzufügen) kommt bei mir automatisch ein Downloadfenster,

War ein Browser-Problem, mit Firefox gehts bei mir auch.

Wegen des HTTPS-Zerifkates: Fa habe ich mich geirrt, man kann es nicht einstellen. Das verwendete Zertifikat ist enthält Angaben:

Inhaber: KoCo Connector AG
Zertifizierungsstelle: gematik GmbH/Komponenten-CA der Telematikinfrastruktur
Alternativer Antragsstellername: konnektor.konlan

Hier stimmen einige dinge nicht:
Der Konnektor ist nicht als unter der Adresse konnektor.konlan zu finden, die ist halt anders. Die führt zu einem TLS-Fehler im Browser. Der ist nicht behebbar, da man im Zertifikat nicht nachträglich den Alternative Antragsstellernamen ändern kann. Wieso man den Hostnamen des Konnektors (LAN/WAN->Hostname) und dessen Domäne anpassen kann (DNS->DNS Domain lokales Netz) und das Zertifikat nicht, erschließt sich mir nicht.

Die CA, bzw. die CAs der Zertifikatskette sind nicht in der Liste der vertrauenswürdigen Stamm-CAs des Browsers enthalten. Dies führt zum nächsten Fehler im Browser. Der wäre behebbar, wenn man der ausstellenden CA (gematik GmbH/Komponenten-CA) vertrauen würde - tue ich aber nicht.

Grüße

lcer

Heilberger hat geschrieben:Ich werde nichts unternehmen. Wenn das jemand prüfen sollte, werde ich an Turbomed verweisen.

Das ist in der Tat die richtige Einstellung

Denn ich weiß nicht, wie es den anderen Vorrednern beim "Ausprobieren" dieser "sicheren" Verbindungseinstellung zur Koco-Box ging - falls das überhaupt jemand getestet hat.

Aber nach den Erfahrungen der letzten zwei Stunden kann ich nur davor warnen, sich von den Vorgaben dieser neuen IT-Sicherheitsrichtlinie verrückt machen zu lassen und zu versuchen, die Verbindungsart zur Koco-Box in Turbomed von der Grundeinstellung HTTP auf irgendwas anderes dort zu ändern.

Denn: Bei Auswahl von "HTTPS mit Client-Zertifikat" (und sonst keine Angaben bezüglich Zertifikatsverzeichnis etc.) hängt gleich danach das Fenster und es geht nichts mehr (TM-Abstürze sind bei uns seit dem letzten Update wirklich Mangelware, das sollte man auch mal erwähnen).

Doch damit nicht genug: TM ließ sich bei uns auf keinem Rechner mehr starten, weder auf den Arbeitsplätzen noch am Server. Man denkt zwar anfangs erst, TM startet normal, aber nach der versuchten Verbindung zum Konnektor gibt's überall einen Absturz (Tricks wie das Ausstecken etwa des Netzwerkkabels des Konnektor bringen hier nichts).

Da die TM-Logdatei keinen Aufschluss über den Fehler bot (und die crashdump-Datei wohl nur für Debug-Experten bei TM gedacht ist), blieb nichts anderes übrig, als die diversen TM-Dienste auf dem Server zu beenden und die Praxisdatenbank, die heute Nachmittag Gott sei Dank wie üblich bei Praxisende auf einem Rechner gespielt wurde, zurückzukopieren (denn außer der Praxis-DB hatten sich auf dem Server offenbar keine anderen Dateien beim Umstellungsversuch der Verbindungsart geändert).

Da das Rückkopieren der Praxisdatenbank so schön geklappt hatte versuchte ich auch gleich mal die andere Einstellung "HTTPS ohne Authentifizierung". Diese Einstellung hat zwar nicht ganz so drastische Folgen, bewirkt aber immerhin, dass man bei Aufruf von Sonstiges -> Praxisdaten das Menü "eGK" auf der linken Seite plötzlich nicht mehr anwählen kann, um diese Einstellung wieder auf "einfaches HTTP" zurückzusetzen.

Und auch der Menüpunkt Sonstiges -> eGK -> eGK-Konfiguration ist dann plötzlich ausgegraut und nicht mehr anwählbar (obwohl bei uns alle Rechner im Infomodell eingetragen sind, um für spätere TI-Anwendungen vorbereitet zu sein).

Auch hier musste die Praxis-DB zurückkopiert werden. Danach klappt alles wieder wie zuvor. Doch der Schreck sitzt.

Also erst mal Finger weg von diesen Einstellungen - die eigentlich kennwortgeschützt sein sollten, da man dadurch das ganze System mit ein paar Mausklicks lahmlegen kann, wenn das während des Praxisbetriebs passiert und wirklich nur das Rücksichern der tags zuvor gesicherten Praxis-DB bleibt, die dann ja veraltet wäre...

Hallo,

hatten Sie die Zertifikatsdateien in den Zertifikatsordner auf dem Turbomed-Server kopiert? HTTPS zum Konnektor benötigt ein ServerZertifikat und HTTPS mit Clientauthentifizierung zusätzlich ein Clientzertifikat.

Grüße

lcer

Vielen Dank für die Warnung!

lcer hat geschrieben:hatten Sie die Zertifikatsdateien in den Zertifikatsordner auf dem Turbomed-Server kopiert?
lcer

Soweit bin ich nicht mehr gekommen, weil ich nach der Umstellung bereits auf "OK" drückte: Und da hing der Rechner schon. Konsequent wäre es gewesen, von TM aus eine Meldung anzuzeigen, dass die Zertifikatsdatei fehlt. Aber selbst die andere HTTPS-Einstellung hat ja letzten Endes (ohne Absturz) dazu geführt, dass es ohne Rückspielen der Praxis-DB praktisch keine Chance mehr gegeben hätte, diese Einstellung wieder rückgängig zu machen, weil das eGK-Menü unter Sonstiges nicht mehr erreichbar war (und für die alternative HTTPS-Einstellung ist ja eigentlich nicht die Angabe einer Zertifikatsdatei erforderlich, oder etwa doch?)

Überhaupt sind einige dieser KV-IT-Sicherheitsrichtilinen wirklich realitätsfern (auch wenn die meisten Praxen nur Anlage 1 und 5 betreffen wg. bis zu fünf Mitarbeitern, die andauernd mit DV beschäftigt sind).

Zum Beispiel:

Anlage 1

Punkt 6: Wenn man Word- oder Office-Dateien weiterversendet (oder daraus PDF-Dateien bastelt), soll man den Autorennamen löschen (bei uns "Praxis"), weil das zu den vertraulichen Informationen gehört. Der eigentliche Inhalt des Word-Dokumentes, der ja sowieso weitergegeben wird, zählt dann konsequenterweise also zu den nicht-vertraulichen Infos

Punkt 8: "Stellen Sie ihren Internet-Browser gemäß Hersteller-Anleitung so ein, dass keine vertraulichen Daten im Browser gespeichert werden" oder eben mit CTRL-Shift-Del die Browserdaten löschen. Das betrifft ja vor allem Cookies - was aber bedeutet, dass man beim späteren Aufruf einer Website den "Bitte-Cookies-annehmen-Wahnsinn" immer wieder durchlaufen muss. Zwar plant das Justizministerium, das zu vereinfachen, also Annahmen und Ablehnen in einem Fenster (damit man beim Annehmen der nur notwendigen Cookies nicht zig Menüs aufrufen muss). Aber trotzdem wird ja normalerweise auch beim Ablehnen irgendein Cookie gespeichert.

Punkt 32: In der Hardfirewall, also z. B. der Fritzbox, sollten die erlaubten Kommunikationsziele mit IP-Adressen definiert werden. Das heißt im Umkehrschluss, dass alle anderen Ziele nicht erlaubt sind. Und das soll wohl heißen, dass man nur die erlaubten IPs dort hinterlegt, die man erst mal mit ping- oder tracert-Kommandos herausfinden und in die Fritzbox eintragen muss. Das scheint mir ein bisschen praxisfremd

Allerdings kann man auch sagen: Vieles gerade für kleine Praxen aus dieser Richtlinie fällt komplett weg, wenn man keine mobilen Zugänge wie WLAN oder Smartphones hat.

Hab mir mal Anlage 1 und 5 dieser Richtlinie in eine Wordtabelle kopiert und nur die Zeilen markiert, die uns betreffen.

Was bleibt (von oben genannten Punkten abgesehen), sind halt die typischen Dinge: "Hinreichend komplexe" Passwörter (Punkt 7) dürften erfahrungsgemäß die wenigsten Praxen haben (auch kein Password-Manager mit generiertem Passwort, weil sich das keiner merken kann).

Und nach jeder Videosprechstunde explizit (bei Windows unter Einstellungen Datenschutz) Mikrofon- und Kamerazugriff abschalten (Punkt 12) dürfte wohl niemand machen. Genauso wenig wie sofort "nach Ende der Nutzung" eines Rechners die Windows-Taste + L drücken, um sich abzumelden. Es kommt halt immer drauf an, wo das Gerät steht oder was man unter "Ende der Nutzung" versteht (bei uns meldet sich der Sperrbildschirm nach fünf Minuten Inaktivität sowieso schon).

Die Punkte 28 bis 31 (Wechseldatenträger, zumindest bezüglich Austausch mit anderen Ärzten) dürfte durch KIM-Versand über TI auch hoffentlich bald wegfallen. Das war's dann auch schon.

Und nun ja, bezüglich Punkt 5 der Anlage 5 ("Aktivieren Sie die TLS-Verbindung vom PVS-System zum Konnektor") warten wir einfach mal auf das nächste und hoffentlich absturzsichere Update von TM

h-o hat geschrieben: Punkt 32: In der Hardfirewall, also z. B. der Fritzbox, sollten die erlaubten Kommunikationsziele mit IP-Adressen definiert werden. Das heißt im Umkehrschluss, dass alle anderen Ziele nicht erlaubt sind. Und das soll wohl heißen, dass man nur die erlaubten IPs dort hinterlegt, die man erst mal mit ping- oder tracert-Kommandos herausfinden und in die Fritzbox eintragen muss. Das scheint mir ein bisschen praxisfremd

Die Schlussfolgerung ist falsch. Es sollte in der Dokumentation des AIS-Programms stehen welche IP-Adressen (bzw. Domains - obwohl Domains aus Sicherheitsgründen eigentlich schon nicht mehr erlaubt sind) freizugeben sind. Diese Information muss auch für den Endbenutzer zugänglich sein. viewtopic.php?p=46876#p46876
Jetzt habe ich endlich Daumenschrauben bekommen (und die Daumen von CGM stecken drinnen)

Ich glaube nicht, dass man das mit der Fritz-Box gut realisiert bekommt. Die Architektur sollte eher ein sicheres Sub-Netz im Praxis-LAN sein. Man will/muss ja noch im I-Net surfen können.
Denkanstöße hatte ich mal verbreitet... viewtopic.php?p=47803#p47803
wurde dann aber etwas von den professionellen Kollegen "eingebremst". Für mich funktioniert die Lösung.

Genug off-topic. Eigentlich ging es hier um etwas anderes.

Heilberger hat geschrieben:Ich muß zur Zeit jeden Tag die Box neu starten, da die Scheißkiste zickt! Ich werde nichts unternehmen. Wenn das jemand prüfen sollte, werde ich an Turbomed verweisen.

Darf ich fragen, ob Sie dafür schon eine Lösung gefunden haben? Wir müssen morgens auch einmal durchstarten, damit die Clients überhaupt die Verbindung aufbauen und das nervt den Ablauf extrem.

Wir haben die Kocobox hinter einer Hardwarefirewall für die Kontrolle nach außen, aber im internen Netz selbst ist nichts geblockt. Und wenn die Box einmal läuft, dann gehts auch. Die Clients zicken seit dem letzten Update auch gerne mal bei der Sicherung, die Praxis DB sei noch geöffnet - aber es gibt keine Verbindungen zum Sever in dem Fall.