TI-Installation – erster Versuch *Update 2*

Wer es eilig hat – am Ende gibt’s die technischen Details!

Es begab sich im November, als ich das erste Mal über die Telematikinfrastruktur schrieb. Ursache damals war eine Infoveranstaltung der Kassenärztlichen Vereinigung in Dortmund. Die durchaus informativen Inhalte waren aber letztlich nur eine mangelhafte Vorbereitung auf die erste TI-Installation.

Der Wahnsinn nimmt seinen Lauf

Am vergangenen Freitag war es dann so weit. Im dritten Anlauf tauchten ohne weitere Bestätigung, gleich zwei Techniker in der Praxis auf. Vollgepackt mit diversen Kartons, haben die Herren sich im Büro ausgebreitet. Als ich wenige Minuten später dazugestoßen bin, machte ich nach der obligatorischen Begrüßung direkt klar, dass ich in der Thematik relativ unwissend bin. Bis auf die bereits erwähnte Infoveranstaltung und meiner Menge, frei verfügbaren Infomaterials, entspricht das auch den Tatsachen. Immerhin war das meine erste Installation die ich begleiten durfte. Wie sich herausstellte, waren mir die Herren, gemessen an der Anzahl der Installationen, aber nicht sehr weit voraus.

 … ich bin auch erst 14 Tage dabei…

Es ging also schnell an den temporären Aufbau der mitgebrachten Geräte. Namentlich waren dass: Eine KoCoBox und ein Orga 6141online. Was schon mal schade war, denn die Praxis hatte zwei eGK-Lesegeräte an der Anmeldung. Nun… hatte. Aber auf Einzelschicksale konnte keine Rücksicht genommen werden. Kurz irritiert von dem Umstand, dass die Kollegen kein Notebook dabei hatten (Vermutung), haben wir also geklärt, wie man denn nun an die KoCoBox kommt. DHCP war der Wunsch, dem ich gerne nachgekommen bin. War leicht, denn in der selbstverständlich vorhandenen Firewall, kann ich nicht nur den Range leicht bestimmen, sondern auch recht komfortabel sehen, wer welche IP bekommen hat. Spannend ist dieser Umstand, da trotz kostenpflichtiger Vorabbesichtigung der Praxis, niemand mit mir als Systembetreuer, Kontakt aufgenommen hat. Ohne Notebook und ohne Kenntnis der Infrastruktur, hätten die Herren also ziemlich hilflos aus der Wäsche geguckt. Aber auf meinen eindringlichen Wunsch, war ich nun mal anwesend, und konnte die Herren mit den notwendigen Infos versorgen.

Papier ist ganz wesentlich… nicht alles.

Am Praxisrechner machten sich die beiden Herren also über die gerade eingebundene KoCoBox her. Nachdem man die URL (https://IPADRESSE-KoCoBox:9443/administration/start.htm) der Box schön behutsam aus der umfangreichen Dokumentation abgetippt hatte, stellte ich die erste unangenehme Frage.

…welche Ports braucht die Box denn ausgehend?

Hätte ich gewusst, dass ich mit dieser Frage ein zehnminütiges (vergebliches) Blättern in der umfangreichen Dokumentation auslöse, hätte ich damit gewartet. Wusste ich aber nicht, und sah mich plötzlich mit zwei ziemlich ratlosen, zertifizierten Technikern konfrontiert. Aber nach dem ersten Schock erklärte man mir dann, dass die Box keine Ports bräuchte. Das ginge alles von alleine. Da ich an dieser Stelle das erste Mal das Lachen kaum zurückhalten konnte, sah ich mich genötigt, dringend meine Kaffeetasse wegzustellen. In einen anderen Raum. Am liebsten in einer anderen Praxis.
Für die technisch nicht ganz so bewanderten Leser – das ich eine Firewall benutze – was ja bereits Bestandteil der Unterhaltung war – sollte dem gemeinen Techniker suggerieren, dass eben nicht alle Ports pauschal offen sind, wie das beispielsweise bei dem NAT in einer Fritz!Box oder einem Telekom Speedport der Fall ist.
Ich erklärte dann, dass ich bereits die üblichen Standardports plus IPSec freigegeben hätte. Damit war das Thema bis auf weiteres abgeschlossen, und die Kollegen widmeten sich erneut dem alles andere als übersichtlichen Webinterface.

Bürokratie wohin man schaut

Das eher kleine Büro war voll mit Papier. Und damit meine ich nicht die ausladenden Papierberge, die naturgemäß in einer Arztpraxis anfallen. Nein, ich meine damit den mittelgroßen Wald in verarbeiteter Form, den die Kollegen in Gestalt von Verträgen, Berichten, Dokumentation und diversen Hilfezetteln mitgebracht hatten. Und jedes Blatt wollte genutzt werden. Man muss den zuständigen Stellen zu dem erdachten Sicherheitskonzept der TI-Anbindung, vollumfänglich gratulieren. Derart viel Dokumentation, Abgleich von Nummern und vollkommen bekloppten Sicherungsmaßnahmen – das Kartenlesegerät macht Geräusche, wenn jemand die Einstellungen bearbeitet – habe ich noch nie gesehen. Dazu passt auch mein gescheiterter Versuch, ein weiteres Kartenlesegerät (wenigstens theoretisch) zu beschaffen. So ergab eine Recherche bei Firma Ingenico, dass man derzeit mit einer großen Anzahl von Partnern zusammenarbeitet… Okay, die umfangreiche Liste beschränkt sich aktuell ausschließlich auf die CGM… aber das wird bestimmt noch. Interessanter ist da, dass es die “sichere Lieferkette” unmöglich macht, dass man mir als Kunden von Ingenico, ein solches Kartenlesegerät zuschickt. Ich bin ja kein zertifizierter Partner. Wer aber den Text aufmerksam liest, wird bemerken, dass ein Versand direkt an die Praxis durchaus möglich wäre. Also ließ ich das telefonisch abklären… Der Hotliner begann das Gespräch quasi mit “Wir haben keine 6141online auf Lager…”. Und ja, er kenne die Regelung. Aber der Versand in die Praxis müsse erst einmal zertifiziert werden. Und wann damit zu rechnen sei, wüsste er nicht. Wir haben – Stand heute – also ein staatlich gefördertes Duopol. Und wer ein entsprechendes Kartenlesegerät erwerben möchte, kann ausschließlich bei der CGM kaufen. Zu den entsprechenden Preisen.
Aber selbst wenn man ein entsprechendes Gerät bekommt, muss man nicht glauben, dass die Einrichtung irgendwie auf dem gewohnten technischen Weg machbar ist. Ohne die TI Hotline scheint da nichts zu gehen. Das wenigstens legen die entsprechenden Schritte bei der Einrichtung nahe. Ich habe die Frage gestellt, aber der “Ich bin seit 14 Tagen dabei” Kollege, war noch nicht in der Verlegenheit, ein solches Kartenlesegerät tauschen zu müssen.
Es bleibt also abzuwarten, wie umständlich der Austausch eines Kartenlesers wird. Aber ich ahne nichts gutes.

Sind denn alle wahnsinnig?

Nach dem was ich gesehen habe, würde ich mal unterstellen, dass die unnötig komplexe Wartung der Gerätschaften in erster Linie den gesetzlichen Vorgaben geschuldet ist. Der Gesetzgeber hat versprochen, ein sicheres Netz aufzubauen… Auf jeden Fall dürfte er ein unbedienbares Netz geschaffen haben. Bleibt abzuwarten, ob andere Hersteller das eleganter hinkriegen. Und natürlich, ob der Anspruch an die Sicherheit auch nur entfernt erfüllt wird. Erfahrungsgemäß sind komplexe Systeme eher anfällig für menschliche Fehler, als einfache. Aber man muss auch sagen, dass die Umsetzung der vorgegebenen Maßnahmen, alles andere als einfach ist.
Für die Arztpraxen allerdings, ist es ein gewaltiger Schritt in die falsche Richtung. Über die Auswirkungen auf entfernte Standorte und ähnliche Konstrukte, muss ich erst nochmal nachdenken. Festhalten kann man aber schon mal, dass die Ausfallzeiten sich deutlich erhöhen dürften wenn denn mal ein Gerät den Geist aufgibt.
Aber kommen wir nochmal auf die Installation zurück. Nachdem dann die umfangreichen Abschreibearbeiten abgeschlossen waren, ging es an den ersten Verbindungsversuch. Und auch die Frage nach einem Anschluss an das KV-Safenet, wurde mittlerweile von der Hotline beantwortet. Denn auch das wusste der Kollege leider nicht. Das ist wichtig, denn ein zusätzlicher KV-Safenet-Router ist mit Anbindung an die TI, nicht mehr zwingend notwendig. Und angesichts der komplexen technischen Einrichtung, auch nicht empfehlenswert. Aber, und das muss man wissen (als ausführender Techniker), braucht es dafür weitere Arbeitsschritte. Das Netz der KVen muss nämlich “manuell” in der KoCoBox eingerichtet werden. Aber auch das haben wir gemeistert… Natürlich – ich hatte das kommen sehen – war die KoCoBox nicht in der Lage, eine Verbindung zur TI aufzubauen. Anstatt aber im Interface deutlich darauf hinzuweisen, dass es ein Verbindungsproblem gibt, dessen Ursache vermutlich irgendwo im Netzwerk zu suchen ist, gibt es kryptische Java-Fehlermeldungen. Ähhh… ja. Okay. Kann man so machen… Anfangs hatten die Kollegen, die erst kurz zuvor freigeschaltete SMC-B-Karte (“Karte” ist hier redundant, aber ansonsten versteht es keiner) in Verdacht. Denn auch dieser Vorgang ist eher kompliziert und wohl gegebenenfalls eher langwierig. Das war es aber nicht, wie ein kurzes Monitoring an der Firewall zeigte. Die KoCoBox sehnt sich nämlich neben den IPsec Standardports, noch nach TCP 8443. Was einem ja niemand sagen konnte, weil es ja “von alleine funktioniert”. Während ich also amüsiert Port 8443 der entsprechenden Firewallregel hinzugefügt habe, sah ich in den aktuellen Verbindungen etwas, dass mich wieder die Kaffeetasse wegbringen lassen wollte. Wie so ziemlich jedes andere Gerät auch, benötigt die KoCoBox ein funktionierendes DNS. Das bezieht die Kiste aber nicht von den vielen, vielen offenen DNS-Servern (9.9.9.10 z.B.), sondern von den Google Public DNS-Servern. Ja richtig, in dieser super sicheren Infrastruktur, bezieht man die Namensauflösung von Google. Ich habe nichts gegen Google! Im Gegenteil. Aber ich muss mich schon wundern, dass bei der Größe des Projektes keine eigenen DNS-Server mit entsprechender Absicherung (DNSSEC / DANE) mehr drin waren. Aber sei es drum.

Tatsächlich hat sich der Router irgendwann verbunden. Und auch den Zugriff aufs KV-SafeNet konnte ich noch erfolgreich testen. Wie genau die Nummer nun im Produktivbetrieb läuft, lässt sich noch nicht abschätzen. Prinzipiell gehe ich davon aus, dass es einigermaßen rund laufen wird. Abgesehen von dem Wegfall eines eGK-Lesers. Da selbst ein Ausfall der KoCoBox nicht dazu führt, dass die Praxis keine Karten mehr einlesen könnte, bleibe ich entspannt. Trotzdem habe ich Zweifel daran, wie praxistauglich dieses System abseits des Regelbetriebs ist. Aber das wird sich zeigen.

***Update 1a***
URL zur Box im Fließtext korrigiert. Da fehlte was.

Ich hatte technische Details versprochen was Ports und ähnliches angeht. Weil ich es gerade für jemanden zusammengeschrieben habe, hier nun eine Zusammenfassung:

  • TCP/UDP 53 (DNS)
  • TCP 80
  • TCP 443
  • UDP 123 (NTP wenn man intern keine Zeitquelle hat)
  • UDP 500 (IPSec)
  • UDP 4500 (IPSec)
  • AH / ESP (IPSec nix Ports)
  • TCP 8443 (TI / KV-SafeNet Provisionierung)
  • TCP 9443 (Zugriff von intern auf’s Webinterface bei der CGM – NICHT ausgehend!!!)
  • TCP 8500 (Zugriff von intern auf’s Webinterface bei secunet – NICHT ausgehend!!!)
  • https://IPADRESSE-KoCoBox:9443/administration/start.htm (muss bei der KoCoBox anscheinend genau so sein, sonst wird man vom Webserver (Jetty) lediglich beschimpft)
  • https://IPADRESSE-KONNEKTORvonSECUNET:8500/management

Alle Ports sind ausschließlich ausgehend konfiguriert. Kein Portforwarding, keine DMZ oder sonstige Unanständigkeiten! Wofür auch? Ist das VPN aufgebaut, kann darüber alles in beide Richtungen getunnelt werden.

*** Ende Update 1a***

*** Update 2 ***

Ich musste gerade wieder recherchieren, und habe mal alles was von Interesse sein könnte, wild zusammengeschrieben. Vielleicht findet jemand was hilfreiches. Außerdem habe ich Infos zum Secunet Konnektor zum Update 1 hinzugefügt

DNS Server TI:

100.97.139.47

100.97.139.48

100.97.148.71

100.97.148.73

===============

DNS Server KV Safennet:

188.144.7.140

188.144.15.4

===============

NTP Server TI:

100.97.139.46

100.97.139.45

===============

VPN Konzentratoren TI:

185.188.2.16 (CGM)
83.137.38.5 (DGN)

================

URL unter der ein CGM Konnektor seine Provisonierung abholt. Erfordert gültiges Konnektor-Zertifikat zum abholen!

https://register.f-vpnzugd.telemed-ti.net:8443/RegistrationServer/services/provisioningPort

================

Netzbereiche:

TI Primär:
–> 100.96.0.0/14
TI Sekundär:
— > 100.80.0.0/12
Fachdienste:
–> 100.102.0.0/16 (offen / unsicher)
–> 100.100.0.0/16 (sicher)

===============

Port Konnektor -> Kartenterminal (Orga 6141): 4742

==============


Beitrag veröffentlicht

in

,