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 a secure reference architecture with explanations. But, er ist auf deutsch (it’s in German).

Hinweis

Wer meint ich habe Abkürzungen genommen und vereinfacht, hat vermutlich recht! Auch wenn es sich beim Inhalt dieses Post um Grundlagen für einen Netzwerk oder ITler handelt, heißt es nicht, dass sie trivial für einen Mediziner sind, genau wie wir Security Leute keine Medizinexperten sind.

Vorgaben

Als Abkürzung um große Ansätze wie IT-Grundschutz nach BSI und Common Criteria herum, gibt es von der Kassenärztlichen Bundesvereinigung eine eigene IT-Sicherheitsrichtliche. Um das Leben von Arztpraxen zu verinfachen, ist die Richtline auf recht konkrete Szenarien und Schutzmaßnahmen beschränkt, welche auch wirklich umgesetzt werden sollten bzw. praktisch umgesetzt werden müssen. Die Details gibt es hier.
Die Richtline ist dabei in Anforderungen an kleine, mittlere und große Praxen aufgeteilt und enthält extra Anforderungen für Praxen mit medizinischen Großgeräten. Generell gesehen soll bspw. die Authentifikation (Login) über einen zentralen Server (Active Directory) laufen und nicht mit lokalen Benutzerkonten. Eine solche Benutzerverwaltung wäre natürlich auch bei kleinen Praxen cool, jedoch würden Aufwand und Komplexität nicht den Vorteilen gerecht werden. Dennoch, wie üblich, gibt es in den Vorgaben ein paar Zeilen, die Security Experten zum Schmunzeln bringen können.
Darüber hinaus gibt es Anforderungen, die schlicht aus der verwendeten Infrastruktur, also der Praxis TI, Telematikinfrastrzuktur resultieren. Hierfür gibt es diverse Referenzen bei der Gematik hier und hier.

Praxis TI

Die Praxis TI besteht generell aus 2 1/2 Komponenten. Die ersten ist der sogenannte “Konnektor”, der praktisch gesehen ein VPN Router / Access Node ist. Als Secret für die VPN Verbindung wird eine eingelegte, Praxis/Arzt spezifische SmartCard verwendet. Der Konnektor funktioniert also erstmal für sich alleine. Hier liegt such sein großer Vorteil: Er ist unabhängig vom Praxis PC, wodurch gerade bei Updates, Softwareinstallationen etc. weniger schief laufen kann. Die zweite Komponente ist das Kartenterminal, also der Kartenleser, wo die Gesundheitskarte vom Patienten eingesteckt wird. Der Kartenleser muss durch den Konnektor und zum Praxis PC kommunizieren können, hängt also “hinter” dem Konnektor. Die halbe Komponente ist dann der Praxis PC auf dem eine beliebige Verwaltungssoftware läuft, welche sowohl mit Karenterminal als auch durch den Konnektor kommunizieren muss. Entsprechend hängt auch der Praxis PC “hinter” dem Konnektor. Damit ist auch die einfachste Architektur.

Reihenbetrieb

Der “Reihenbetrieb” für einfache Praxisinfrastrukturen empfohlen. Hierbei sind der Praxis PC und das Terminal direkt hinter dem Konnektor und somit vom übrigen Netz isoliert. Leider sind die Konnektoren sehr sparsam designed und haben lediglich einen LAN und einen WAN Port, entsprechend wird zumindest ein einfacher Switch als Ergänzung benötigt. Die Vorteile in diesem Modus sind offensichtlich:

• Alle Praxis-/Patientendaten hängen hinter dem Konnektor
• Eine direkte Internetverbindung besteht nicht
• Zugriff vom Internet auf den Praxis PC ist erstmal ausgeschlossen
• Die Kommunikation zwischen Konnektor, Kartenleser und Praxis PC sind isoliert

Die Nachteile folgen auf dem Fuß:

• Der Praxis PC kommt nicht ins Internet, kann also auch keine Updates ziehen
• Die Anbieter der Konnektoren verkaufen “Datenvolumen” für den Praxis PC um im Internet Updates ziehen zu können

Praktisch, wenn man das Kleingedruckte liest, sollen bei den Konnektordienstbetreibern Firewalls laufen, die den Praxis PC beim Zugriff ins Internet schützen, realistisch gesehen sind solche Maßnahmen ohne Inline Proxy, der wiederum allen Traffic an den Dienstleister exponieren würde, nur wenig Erfolg versprechend.

Parallelbetrieb

Der “Parallelbetrieb” ist für “komplexere Umgebungen” gedacht. Praktisch gesehen hängen Praxis PC, Konnektor und Kartenterminal flach (parallel) im selben Netz.

Der Praxis PC kann auf einem Wege, direkt über den vorhandenen Router ins Internet, oder die Route durch den Konnektor, ins VPN zu den entsprechenden Systemen verwenden. Problematisch dabei, offensichtlich, ist das der LAN Port vom Konnektor in einem Netz ist, dass auch direkt Richtung Internet kommunizieren kann. Während nun also Updates trivial werden, ist die Angriffsoberfläche im Vergleich zum Reihenbetrieb wesentlich größer. Als Lösungsansatz muss dann eine Hardwarefirewall verwendet werden. Diese soll dann das Netz hinter dem Konnektor isolieren.

Der Systematische Ansatz

Kleine Praxis, keine extra Wünsche

Kleine Praxis, ein Rechner, Konnektor, Kartenterminal, der Switch für 10€ und fertig! Hierbei muss darauf geachtet werden, dass der Tarif zur TI ausreichend Traffic beinhaltet, dass die Updates vom Praxis PC gut, sicher und stabil laufen. Selbst der Drucker kann dann entweder per USB an den Praxis PC oder per Ethernet hinter den Konnektor. Er versucht zwar manchmal nach Hause zu telefonieren, sollte aber scheitern.
Selbst der nicht-dienstliche PC kann an dieser Stelle verwendet werden. Er wird genau wie der Konnektor, direkt an den Router angeschlossen. Der dienstliche und nicht-dienstliche Teil werden weiterhin hart durch den Konnektor getrennt.

“Sonderwünsche”

Der Drucker im Reihenbetrieb sorgt für Probleme, wenn auch vom nicht-dienstlichen PC aus gedruckt werden soll, denn dieser gehört definitiv nicht hinter den Konnektor. Gleichzeitig bietet der Konnektor keine lokalen Breakouts bzw. kein lokales Routing an, entsprechend muss eine andere Architektur her.
Beim Entwurf hilft eine simple Kommunikationsmatrix. Die erste Spalte ist jeweils die Quelle der Kommunikation, danach kommen Ziele. Beispielsweise darf der Nicht-dienstliche PC nicht mit dem Praxis PC sprechen, aber zum Drucker.
Kommunikationsmatrix

Korrekterweise ist die Matrix etwas komplexer

Kommunikationsmatrix

Praktischerweise findet sich in der Publikation den Kassenärztlichenvereinigungen und der Gematik direkt ein Hinweis auf eine “Hardware Firewall” die im Parallelbetrieb eingesetzt werden soll. Spannenderweise findet sich bei der Kassenärztlichenvereinigung Sachsen direkt ein Hinweis dazu:

Für eine Einzelpraxis genügt eventuell die Hardware-Firewall des Internet-Routers als Schutz. Ein Produktvertreter ist hier die Fritz!Box. Bitte lassen Sie sich von Ihrem IT-Diensteister beraten.Für größere Praxen, welche mehr IT-Technik und Anschlüsse nutzen, muss ggf. eine leistungsstärkere Hardware-Firewall installiert werden.

und

Praxen, die ihre Telematikinfrastruktur nicht parallel zum Internet (Parallelbetrieb), sondern seriell angeschlossen haben (Reihenbetrieb), genügt die Firewall im TI-Konnektor als Schutz.

Hardware-Firewall
Für eine Einzelpraxis genügt eventuell die Hardware-Firewall des Internet-Routers als Schutz. Ein Produktvertreter ist hier die Fritz!Box. Bitte lassen Sie sich von Ihrem IT-Dienstleister berraten. Für größere Praxen, welche mehr IT-Technik und Anschlüsse nutzen, muss ggf. eine leistungsstärkere Hardware-Firewall installiert werden. Hierzu hat die KBV ein hilfreiches Paper veröffentlicht, das auch auf der Internetpräsenz der KV Sachsen zum Download bereitsteht.

Praxen, die ihre Telematikinfrastruktur nicht parallel zum Internet (Parallelbetrieb), sondern seriell angeschlossen haben (Reihenbetrieb), genügt die Firewall im TI-Konnektor als Schutz. Zu den Begrifflichkeiten Parallel- und Reihenbetrieb finden Sie auf der Internetpräsenz der KV Sachsen unter Telematikinfrastruktur das Dokument "TI Installationsvarianten" zum Download.

Kurze Kritik

Der zweite Auszug ordnet ein, dass wir im ersten Auszug definitiv über einen Parallelbetrieb sprechen. Da PC, TI (Kartenterminal und Konnektor) und Drucker problemlos im Reihenbetrieb abbildbar sind, sogar mit privaten Geräten dabei, ist der geteilte Drucker das vermutlich einfachste Szenario, in dem der Parallelbetrieb zum Einsatz kommt. Der versierte Netzwerker sieht die Lösung des Problems direkt: Wir bauen drei Netze auf. Eins für den nicht-dienstlichen PC, eins für die Praxis Systeme und eins für den Drucker. Über eine Firewall erlauben wir dann, genau wie in der Tabelle aufgelistet, nur bestimmte Kommunikation. Leider ist die von der KVS vorgeschlagene Fritz!Box, genau wie ein typischer Speedport Router der Telekom oder die Digitalisierungsbox Basic der Telekom oder die klassischen kleinen Router von O2, Vodafone oder anderen Anbietern nicht in der Lage eine derartige Architektur umzusetzen.
Fast alle kleinen Router für den Home oder auch für den Office Einsatz sind wie auf dem folgenden Bild gezeigt aufgebaut:

Der Router beinhaltet, wie angenommen, eine Firewall, diese liegt jedoch flapsig gesagt lediglich zwischen dem Internet und dem internen Netzwerk. Die Kommunikation zwischen den beiden eingezeichneten Laptops läuft direkt über den integrierten Switch, der meist wirklich eine dedizierte Komponente (Chip) innerhalb des Routers ist. Kauft man im Internet einen einfachen Switch, ist typischerweise die kleinste Anzahl an Anschlüssen die man finden kann 5, bei Routern sind es meist 4. Grund dafür ist, dass der 5. Anschluss intern Richtung Firewall und dann dem Modem verbunden ist. Ein typischer, einfacher, billiger Switch hat dabei keine Filtermechanismen sondern leitet einfach Pakete von Anschluss zu Anschluss weiter, dass alle Systeme miteinander reden können. Genau so wie er es soll.
Auf Grund eben dieses gezeigten Aufbaus lässt sich unsere gewünschte Architektur mit derartigen Routern leider nicht umsetzen. Das einzige Szenario in dem ein solcher Router ausreichen würde, ist wenn man akzeptiert das der private PC auch einfach mit dem Konnektor und dem Praxis PC sprechen darf.

Sofern es, bei der obigen Architektur, ein Problem mit dem nicht-dienstlichen PC gibt, kann dieses sich auf den Praxis PC ausweiten, zusätzlich ist der nichtdienstliche PC in der Lage mit der internen Schnittstelle des Konnektors zu kommunizieren.

Zurück zum Lösungsansatz

Wir benötigen drei Blasen und Regeln, welche die Kommunikation zwischen den drei Blasen steuern.

Blasen

In der Netzwerktechnik spricht man dabei von virtuellen Netzwerken oder VLANs. Diese sind technische als eigenes Protokoll spezifiziert und werden von typischer Netzwerkausstattung unterstützt. Benötigt wird dafür allerdings ein “Managed Switch” bzw. ein verwaltbarer/konfigurierbarer Switch, dieser bringt die Option mit für jeden seiner Anschlüsse ein individuelles virtuelles Netzwerk konfigurieren zu können. Praktisch und technisch gesehen wird dann jedes Datenpaket mit einer Nummer versehen. Jedem Anschluss am Switch wird ebenfalls eine Nummer zugewiesen und jene mit der selben Nummer sind dann verbunden und die anderen eben nicht.
In unserem Beispiel nehmen wir nun die Nummer 111 für die Praxis-Blase, die 222 für die Drucker und die 333 für das persönliche.

Switch Anschlüsse

Managed Switches haben zwei Arten von Anschlüssen: tagged und untagged. Bei untaggt Anschlüssen schickt der Switch die Nummer des virtuellen Netzwerkes nicht mit, dies sind entsprechend Anschlüsse an die normale Geräte angeschlossen werden. Bei Paketen, welche an diesem Anschluss ankommen, fügt der Switch die Nummer dann hinzu. Bei tagged Anschlüssen schickt er die Nummer mit. Ein solcher Anschluss ist für die Verbindung mit anderen Netzwerkgeräten wie weiteren Switches oder Routern oder Firewalls gedacht. Die Anschlüsse können auch so konfiguriert werden, dass mehrere virtuelle Netze über einen einzelnen Anschluss gehen können. Genau so ist es in unserem Fall auf Anschluss 8. Hier gehen die Pakete aller drei Netze zur Firewall. Diese Anschlüsse werden auch als trunk bezeichnet, vom englischen Baumstamm, während die anderen Anschlüsse als Blätter betrachtet werden.
Mit der beschriebenen Konfiguration können Beispielsweise Computer auf Anschluss 2 und Anschluss 3 frei miteinander kommunizieren und werden direkt vom Switch weitergeleitet. Versucht allerdings der PC an Anschluss 2 Richtung Drucker, Anschluss 1, zu kommunizieren, würde die Kommunikation zuerst Richtung Firewall geleitet werden, welche dann entscheidet ob die Pakete weiter dürfen oder nicht.

Firewall

Die Firewall ist am Ende lediglich eine Liste an Regeln, oder eher eine Tabelle, die grob wie folgt aussieht:

In der Realität haben derartige Regeln natürlich wesentlich mehr Felder, welche dann konkrete Geräte Adressen, Protokolle, Zeiten etc. beinhalten können. Mehr dazu später.
Der Aufbau ist dann grob so:

bzw. mit Internetzugang

Um ins Internet zu gelangen wird entweder ein vorhandener Router benutzt, der dann die Einwahl übernimmt und alle Daten von der Firewall weiterleitet oder ein Modem. Im Falle eines Modems übernimmt die Firewall die Einwahl ins Internet und wir stoßen auf eine bisher verwendete Vereinfachung. Das Gerät, was bisher als Firewall bzw. Kasten mit Regeltabelle betrachtet wurde, ist eigentlich wesentlich komplexer und bringt die meisten Funktionen von einem typischen Router mit sich. Mit dem großen Unterschied, dass sie virtuelle Netze beherrscht und tiefergehende Security Funktionen mit bringt.

Internet Zugang

Die letzte verbleibende Frage aus Architektursicht ist: Wer darf ins Internet. Während im Reihenbetrieb nur der Konnektor direkt ins Internet kann und der Praxis PC dann durch den Konnektor, gegen extra Geld Updates laden kann, liegt im Parallelbetrieb mehr Verantwortung in der Praxis. Wie bereits beschrieben, sollte der Anbieter vom Konnektor auf seiner Seite Filtern wo der Praxis PC durch den Konnektor hindurch sprechen darf, im Parallelbetrieb erfolgt dieses Filtern auf der Firewall in der Praxis. Gleiches gilt für die Internetfreigaben für bspw. das Kartenterminal und den Konnektor selbst.
Praktischerweise beinhalten die Anleitungen von Praxis Software (das was hinterher auf den Praxis PC läuft), Kartenterminal und Konnektor entsprechende Listen.
Kurz zur Erinnerung: Eine Firewallregel besteht immer aus einer Quelle, einem Ziel und einer Aktion. Das Ziel kann dabei auf “ANY” gestellt werden, dies würde dann bedeuten, dass ein System überall hinsprechen darf wo es mag. Entsprechend keine sonderliche sichere Wahl.

Zusätzlich kommen wir wieder zu einer bisher genutzten Vereinfachung

Jedes System in einem Netzwerk hat eine Adresse. Auf Systemen läuft aber meist mehr als ein Programm, welche alle gleichzeitig kommunizieren möchten. Um dies zu ermöglichen, lauscht jede Software auf einem eigenen “Port”, quasi wie bei einem Haus mit mehrere, nummerierten Briefkästen. Die Datenpakete werden dann immer an Adresse:Briefkasten/Port geschickt. Zusätzlich spricht jede Software ihre eigene Sprache bzw. ein eigenes “Protokoll”, bzw. bietet einen eigenen Dienst an, welcher dann ein festes Protokoll nutzt. Das allgemein verwendete http:// vor einer Internetadresse gibt dabei eben das HyperTextTransferProtokoll vor und somit auch den Port mit der Nummer 80. Zusätzlich, noch komplizierter, gibt es unterschiedliche Arten wie die Daten des Protokolls übertragen werden können. Zwei davon sind TCP und UDP, welche wir hier einfach als Begriffe mit nehmen. All dies sind Parameter die Bestandteil einer Firewallregel sein können. Dabei gilt: Je mehr Parameter verwendet werden, desto strikter der Filter. Wird ein Parameter nicht verwendet, wird er ignoriert.

Konnektor

Die Anleitung des exemplarisch betrachteten Konnektors von secunet, dem “SECUNET KONNEKTOR” in der Einboxx Variante ist hier sehr eindeutig.

Was initial gruselig klingt, liegt natürlich daran, dass der Hersteller des Konnektors nichts mit der individuellen Konfiguration des Betreibers zutun hat. Dennoch wäre an dieser Stelle der Hinweis auf entsprechende Anpassungen sehr gut gewesen.
“Aber der Konnektor ist doch sicher, warum soll ich ihn beschränken?” - Erfahrung, Security ist nie perfekt, Sachen gehen schief und genau dafür ist die Firewall da: nur notwendige Kommunikation erlauben.

Link zur Anleitung, Version 6.7, 13.10.2023

Konnektor, Anleitung vom Betreiber

Die Anleitung vom Betreiber beginnt erstmal ähnlich gruselig, wie die des Herstellers, dann wird es jedoch besser. Die detaillierte Konfiguration entspricht dem Erwartetem.

Die Freischaltung von Port 80 erscheint zwar unschön, bei der Übertragung von bspw. (großen) signierten Updates wird jedoch häufig auf eine verschlüsselte Verbindung verzichtet, denn die Datei an sich ist geschützt.

Leider habe ich für das vorliegende Dokument keine öffentliche Quelle gefunden, daher anonymisiert und keine Quelle.

Praxissoftware

Die vorliegende Praxissoftware ist hinsichtlich ihrer Dokumentation wieder vergleichsweise ernüchternd. Obgleich Ports (Briefkästen) angegeben sind, liegen keine Zieladressen vor. Somit muss die Praxissoftware ins gesamte Internet kommunizieren können. Dies erschwert die Sicherung des Praxis PCs extrem.

Leider wieder ohne Quelle.

Warum wollen wir überhaupt eine Firewall?

Zwischen den Blasen / VLANs/ Netzwerken

Die Firewall zwischen unseren internen Netzwerken bzw. Blasen soll tatsächlich dafür sorgen, dass niemand rein kommt. Konkret gesagt soll niemand aus dem nicht-dienstlichen Netzwerk in das Praxisnetzwerk kommen können. Sollte man sich also beim Weg durch das Internet mit dem privaten PC etwas eingefangen haben, darf dies keinen Einfluss auf die Patientendaten haben.

Zum Internet

Entgegen vieler Annahmen sorgt die Firewall in Richtung Internet jedoch dafür, dass man nicht raus kommt aus dem Netz. Klingt komisch, ergibt aber mit etwas Technik Einblick wieder Sinn. In unserem obigen Beispiel haben wir Dienste und Kommunikation mit Briefkästen und Häusern verglichen. Der Briefkasten stellt einen Dienst dar, praktisch ist er nicht nur dafür da um Briefe zu empfangen, sondern gibt auch jeweils Antworten zurück. In einem üblichen Praxisnetz, genau wie privat Zuhause, gibt es keinen Grund eben solche Dienste/Briefkästen anzubieten. Schaut man also von außen, aus dem Internet, ist dort in der Regel nichts zu finden, wie eine Hauswand ohne Briefkästen. Surft man nun im Internet und ruft eine Webseite auf, öffnet sich ein temporärer Briefkasten, der nur Briefe von der Website akzeptiert. Praktisch wird dadurch eine Konversation zwischen zwei Seiten etabliert und der Router lässt nur Pakete durch, die explizit Bestandteil dieser Kommunikation sind. Hierbei werden wieder Adressen, Ports und weitere Details verwendet, z.B. eine ID für die Konversation. Somit funktioniert unser Zugriff ins Internet, inkl. Antworten obwohl niemand fremdes uns ungewollt etwas schicken kann.
Der einzige Weg, den ein Angreifer dann in ein Netzwerk hat, ist “eine Bitte von innerhalb des Netzes”, dies sind dann z.B. Downloads, Klicks auf Links oder etwas, dass eine böse Website mit sich bringt. In der Situation baut sich eine Verbindung vom Rechner im Netzwerk zu einem System im Internet auf und damit besteht ein Tunnel, der von einem Angreifer oder einem Virus verwendet werden kann.
Die Firewall Richtung Internet sorgt nun dafür, dass vom Rechner oder anderen System aus nur eine feste Liste von Webseiten/Servern/Dienste erreicht werden kann. Für unseren Praxis PC muss dieser z.B. nur auf die Microsoft Server für Updates und auf die Server vom Hersteller der Praxisverwaltungssoftware zugreifen können. Es gibt keinen Grund für YouTube, es gibt keinen Grund für Google. Abgesehen davon, dass die Wahrscheinlichkeit, dass etwas böses auf den Rechner kommt nun gegen 0 geht, könnte nichts nach Hause telefonieren. Ein Virus könnte bspw. keine Patientendaten ins Internet schieben, weil er nur zu Microsoft oder zum Hersteller der Praxisverwaltungssoftware kommunizieren kann, genau wie der Rechner auf dem er läuft.

Schwarz/Weiß -> Grau

In realen Netzen, nicht nur auf dem Papier, macht man hier klassischerweise eine Risiko Betrachtung. Anstatt das gesamte Internet zu sperren und nur wenige Ziele zu erlauben (Whitelisting), erlaubt man gewisse Ziele, denen man wirklich vertrauen kann oder vertrauen muss und verwendet in Ergänzung dazu Blacklists aus dem Internet. Diese Listen werden entweder von gemeinnützigen Gruppen oder kommerziellen Anbietern gepflegt und beinhalten bekannte Adressen von Systemen, die für Schadhaftes verhalten bekannt sind. Dazu gehören neben Viren auch bspw. Anbieter von Werbung.

Ende von Teil 1

So viel zur Theorie, in Teil 2 folgt dann die Praxis aus der realen Praxis :)