A while back Germany decided it would be a good idea to regulate the IT infrastructure in doctor’s practices. While obviously a smart move, it resulted in strange interpretations and even stranger architectures being implemented. This post shows the actual setup. But, er ist auf deutsch (it’s in German).

Hinweis

Dieser Post im Vergleich zu Teil 1 etwas technischer und direkter geschrieben. Teil 1 ist hier zu finden . Abweichend von Teil 1 gibt es in der realen Praxis ein paar mehr Anforderungen, diese wurden nach den selben Methoden adressiert und behandelt.

Überblick

Anforderungen

• Netz für private Geräte
• Netz für Praxis PC und Kartenleser
• WLAN für ein Praxis Tablet mit Praxisverwaltungssoftware
• Getrenntes Netz für Konnektor, volle Kontrolle über was in den Konntektor sprechen kann / darf und den Kartenleser, der nur mit Konnektor redet
• Geteilter Drucker
• Praxisverwaltungssoftware nutzt ein Backend auf einem lokalen Server
• Telefonie wird über eine FritzBox in getrenntem Netz betrieben

Rahmenbedingungen

• Kleines 19" Rack ist vorhanden
• Die Praxis hat bereits Netzwerkdosen liegen, Patchpanel ist vorhanden
  • Es sollen / brauchen nicht alle verwendet werden
• Internet via DSL

Ansatz

• Segmentierung der Praxis in unterschiedliche VLANs
  • Privat
  • Praxis
  • Konnektor
  • Drucker
  • Server
  • WLAN
  • Management
  • Telefonie
• Zentrale Firewall zur Regelung der Übergänge
• Managed Switch mit ein paar Ports mehr, damit zukünftig weitere Dosen in der Praxis verwendet werden können

Ziel

• Angemessene Security
• Stabiles Netz
• Wenig Wartungsaufwand
• Dokumentation, die der Ärztin die Pflege der meisten Komponenten selbst ermöglicht
• Inklusion einer Backup & Restore Strategie
• Angemessene Kosten

Das Netz

Firewall: Fortigate 40F

Die Fortigate fungiert als zentrales Drehkreuz des Netzwerks. Port 1 wird dabei dediziert für die Konfiguration der Firewall und als Zugang zum Management VLAN verwendet. Die Konfiguration ist somit nur bei Zugang zum Rack möglich. Port 2 der Fortigate geht als Trunk Port zum Switch und nimmt dort die unterschiedlichen VLANs entgegen.

Was auf dem Papier nach vielen Firewalls klingt, also zwischen Drucker und dem Privaten und dem Praxis Netz klingt, ist faktisch die Fortigate alleine, welche dann unterschiedliche Regelsätze hat.

Gefühlt

Sauber

Switch (Zyxel GS1915-24E)

Der Switch ist als kostengünstiger Kompromiss ausgewählt worden. Er lässt sich managen, unterstützt entsprechend viele VLANs und hat ausreichend Ports um im Zweifel auch die heute nicht verwendeten Netzwerkports in der Praxis zu versorgen.

Access Point (Zyxel NWA 1123v3)

Der Access Point ist ebenfalls nach Kosten/Nutzen Abwägung ausgewählt worden. Er unterstützt WPA3 und wird mit Updates versorgt.

Umsetzung

Physischer Aufbau

Patchpanel, Switch, Firewall, Modem und Konnektor sind in einem kleinen 19" Rack untergebracht. Patchpanel und Switch sind im 19" Format, Modem, Konnektor und Firewall liegen jeweils auf Einlegeböden.

VLANs

Die Praxis ist nun in 7 VLANs aufgeteilt.

Zusätzlich gibt es ein physisches Netz, bzw. einen Port an der Firewall, der für das Management verwendet wird. Dies ist die einzige Stelle von der aus die Oberfläche der Firewall erreichbar ist, gleichzeitig kann von hier aus das Management VLAN und RDP auf dem Server erreicht werden. Auch kann die Managementoberfläche vom Konnektor von hier aus erreicht werden.

Konnektor und Einschränkungen

Da im Parallelbetriebmodus des Konnektors der WAN Port deaktiviert wird und nur der LAN Port für interne und externe Kommunikation verwendet wird, sollte eigentlich der Reihenbetriebsmodus verwendet werden. Dies hätte dafür gesorgt, dass es ein VLAN (Konnektor WAN) mit Internet Zugang und ein VLAN (Konnektor LAN) ohne Internetzugang gegeben hätte. Leider scheint der Konnektor im Reihenmodus das default Gateway auf der LAN Seite zu ignorieren. Außerdem wurden die gesetzten Routen meist ignoriert. Am Ende wurde dann doch der Modus für den Parallelbetrieb verwendet und mit nur einem VLAN (Konnektor) gearbeitet. Da der Kartenleser lediglich mit dem Konnektor kommuniziert und über diesen zur PVS exponiert wird, ist dieser im selben VLAN. Die Lösung ist nicht perfekt, da ein Client im Konnektor Netz sich per Spoofing durch die Firewall schummeln könnte, da hier jedoch nur der Kartenleser und der Konnektor selbst sind, wird das Risiko als gering betrachtet.

Switch

Der Switch ist der Praxis entsprechend konfiguriert:

• 1 Access Port Praxis, für den Praxis PC
• 1 Access Port Drucker
• 1 Trunk mit Management, WLAN Praxis und Privat für den Access Point
• 1 Access Port für den Server
• 1 Access Port für die FritzBox
• 2 Access Ports für Konnektor, Konnektor und Kartenleser
• 1 Trunk mit allen VLANs für die Firewall

Firewall Regeln

Firewall Regeln greifen immer an der Stelle, an der ein Paket zuerst die Firewall erreicht. Das heißt wenn z.B. ein Druckauftrag von Privat an den Drucker geht, wird dieser durch eine Regel am Netzwerkinterface “Privat” geprüft und dann durchgelassen. Die Weiterleitung Richtung Drucker übernimmt dann das Routing. Entsprechend arbeiten wir immer mit eingehenden Regeln.

Windows Update

Sowohl der Windows Server als auch der Praxis PC müssen Updates von Microsoft laden können. Als Referenz habe ich diese Liste aus der Microsoft Community übernommen . Die Regel wird entsprechend von Server Richtung WAN und Praxis Netz, mit Beschränkung auf die statische IP des Praxis PCs, in Richtung WAN eingestellt. Im Anschluss habe ich gesehen, dass die Fortigate bereits ein Template für Windows Updates hat. Schlussendlich habe ich dieses dann auch genommen.

Konnektor

Der Dienstleister hinter dem Konnektordienst hat, wie bereits im ersten Post anonymisiert erläutert, eine Liste mit IP Adressen zur Verfügung gestellt. Diese sind entsprechend vom Netz Konnektor Richtung Internet/WAN freigeschaltet. Zusätzlich musste der Google DNS Server 8.8.8.8 freigeschaltet werden, da diese aktiv verwendet wird. Die Firewall Regeln für den Konnektor haben sich gut umsetzen lassen.

Kartenleser

Der Kartenleser hat keine Freigabe für Kommunikation ins Internet, da er lediglich durch den Konnektor kommunizieren brauch. Hier kommen auch seine Updates her.

Server / PVS

Die Praxisverwaltungssoftware bringt leider keine Liste an Domains/DNS Namen oder ähnliches mit sich. Das Backend des Herstellers scheint bei Azure zu liegen, darüber hinaus spricht es recht bunt mit unterschiedlichen Systemen. Daher kann der Server Stand heute leider ins gesamte Internet (HTTP/HTTPS) kommunizieren. Die Einschränkung steht weiter auf der Todoliste. Vermutlich lässt sich diese Baustelle nicht ohne Unterstützung des Herstellers lösen. :( Zusätzlich muss das PVS den Konnektor erreichen können, sowohl per direkter Verbindung als auch per Route. Die Route ist notwendig, damit die PVS in das vom Konnektor geöffnet VPN kommunzieren kann.

Praxis PC

Der Praxis PC benötigt auf den Konnektor die gleichen Zugriffe, wie auch der Server. Darüber hinaus darf rudimentär (Web, Mail) ins Internet kommuniziert werden. Hierbei wird sich auf die Filter in der Fortigate verlassen.

Drucker

Der Drucker darf nirgends hinsprechen, jedoch vom Praxis Netz, dem Privaten Netz und dem Server Netz aus erreicht werden. Spannenderweise benötigt der Drucker diverse TCP High Ports für eine funktionierende Kommunikation.

Passwortverwaltung

Die Passwortverwaltung ist einfach und analog gelöst. Während natürlich Passwortsafes wie KeePassx eine gute Lösung darstellen, müssen auch diese irgendwo sicher abgelegt werden. Da bspw. der Praxis PC nicht auf die Infrastruktur zugreifen können soll, wäre er die falsche Stelle für die Ablage. Analog ist auch der zentrale Server, weitestgehend isoliert. Praktisch wäre ein dediziertes System für die Verwaltung notwendig, der jedoch an sich nicht als fester Bestandteil der Infrastruktur gedacht ist. Anders gesagt wäre dies vermutlich mein Laptop, aber da möchte ich persönlich sie auch nicht speichern. Praktisch sind Passwörter auf einem Zettel notiert, von dem es eine begrenzte Anzahl an Kopien gibt. Die Passwörter liegen dabei jeweils als Text und als QR Code vor und sind nummeriert. Bestandteil der Dokumentation ist dann die Zuordnung von Passwort Nummer, Benutzername und System. Zum einlesen der Passwörter wird ein Kabelgebundener QR Code Reader verwendet.

Risikobetrachtung

Die am stärksten schützenswerten Informationen in der Praxis sind die Patienteninformationen in der Form von Notizen zu den Gesprächen. Klassisch würden diese Notizen in einem Schrank weggeschlossen abelegt sein. In der “digitalisierten Praxis” liegen diese Notizen verschlüsselt auf einem weggeschlossenen Server, theoretisch wäre der Schutz also sogar noch höher/besser als bei den Papier Unterlagen. Vor diesem Hintergrund reduzieren die auf Papier abgelegten Zugangsdaten nicht das Schutzniveau der eigentlichen Daten. Da ein einzelner Zettel zusätzlich kleiner/leichter ist, lässt er sich auch problemlos außerhalb der Praxis aufbewahren und hält damit das Schutzniveau weiterhin hoch. Wichtig ist dabei die Anforderung, dass die Zugangsdaten physisch sicher geschützt abgelegt sein müssen.

Kosten

Einmalig

Laufend

Diverses

• USV für 130€, Schutz des Servers
• Server für 500€, nur für die OnPrem Lösung notwendig
• Einlegeböden für das Rack, 35€
• Netzwerkkabel für 50€
• DSL Modem für 25€

Dazu kommt eine Windows Professional Lizenz, wegen BitLocker und eine Windows Server Lizenz.

Zu Teuer? Nun, rückblickend auf die ersten 5 Jahre Arbeit in der eigenen Praxis, wird der Mediziner vermutlich über die über 2000€ lediglich schmunzeln. Mit Blick auf den ersten Tag in der eigenen Praxis, mit ggf. den ersten großen Schulden (Wusstet ihr, dass die Menge von Ärzten bzw. Arztsitzen regional reguliert ist? Und das Ärzte auf dem Weg in den Ruhestand tatsächlich Geld für ihren Sitz verlangen dürfen und diesen weiterverkaufen?) fühlt es sich wie eine große Summe. Besonders da der Praxis PC und ein Tablet und die Kaution und der Internetanschluss und die erste Miete und die ersten Möbel und die Sorge vor der ersten eigenen Abrechnung, die dann auch erstmal nur als Abschlag bezahlt wird und das eigentliche Geld nachkommt… Der Schritt in die Selbstständigkeit ist natürlich immer etwas gruselig, aber gewisse Sachen gehören einfach dazu.

Fazit

Aus technischen Gründen ist das Praxisnetz nicht so aufgebaut, wie ich es gerne gehabt hätte. Durch den Mangel an dokumentierten Firewall Freigaben für das Praxisverwaltungssystem, muss der Server wild ins Internet kommunzieren können. Gerade dieser Kommunikationsweg müsste in einem sicheren Netz jedoch stark beschränkt werden. Es ist einfach schade, dass die Hersteller keinen größeren Fokus auf dieses Thema haben. Das der Konnektor sich nicht so betreiben lässt wie eigentlich angedacht, sollte das Risiko in der Praxis nicht stark reduziert haben. Der Kundensupport, zumindest in diesem Fall, war sehr freundlich und hilfreich, es zeigt sich jedoch, dass die Leute es dort gewohnt sind sich einfach auf die PCs der Ärzte aufzuschalten “und zu tun”. Hier scheint ein ggf. unangemessenes, blindes Vertrauen zu den Dienstleistern zu herrschen.

Notizen

• Die Fortigate setzt bei Firwallregeln per Default das Häkchen für NAT, sollte im lokalen Netz weg
• Die Settings der Fortigate treten teilweise erst mit undefinierter Latenz in Kraft
  • Das Deaktivieren von SSL Inspection dauert meist länger als 5 Minuten
  • Das Aktivieren von Firewallregeln dauert teilweise 10 Minuten
  • Es gibt keinen Button zum übernehmen
• Der Konnektor benötigt jenseits der 6 Minuten zum starten
• Der Konnektor ist so konzipiert, dass er im Parallelbetrieb flach im Netz liegt und das WAN Interface deaktiviert sein soll. Außerdem nutzt er nur bei deaktiviertem WAN Interface das Default Gateway auf LAN * Ohne den Einsatz von NAC könnte also ein Gerät im selben Netz den Konnektor spoofen und dessen Firewallfreischaltungen Missbrauchen, die LAN Seite muss also alleine in einem VLAN sein
  • Was leider nicht funktioniert
• Zusätzlich zum Default Gateway werden statische Routen benötigt, da das Gateway scheinbar nicht immer verwendet wird
  • Nicht genauer untersucht, aber fühlte sich buggy an
• RDP aktivieren nicht vergessen!
• Die Routen und Freigaben für das PVS müssen für den Praxis PC und den Server gemacht werden
• Wenn der Kartenleser nicht korrekt mit SMC-B und SMC-KT bestückt ist, antwortet er im Netzwerk einfach nicht auf dem entsprechenden Port. Einen Fehler meldet er jedoch auch nicht