Geeignete Firewall für Telematik Infrastruktur in Kleinpraxen?

Moin,

Für eine 1 Personen Praxis halte ich die RC100 doch für übertrieben.

Da würde es auch der angesprochene Black Dwarf (Pro) tun.

Gruß,
Avoton

Ich kann hier nur die Securepoint Firewalls empfehlen, zum einen sind es wirklich gute Firewalls, zum anderen haben sie einen eingebauten TI Proxy, in den man die Einstellungen für das TK Gateway importieren kann.
Läuft super stabil, egal in welcher Praxisgröße.
Und ja bei einer kleinen Praxis reicht eine BlackDrwaf oder BlackDrwaf pro aus.

Also jedem Tierchen sein Pläsierchen.

Ich habe vor einiger Zeit eine Securepoint Black Dwarf verwaltet und es war damals und bis heute für mich das mieseste Gerät, was ich als Firewall in der Hand hatte. Terra vertreibt sie halt und deshalb haben sie hohen Zuspruch von Händlern, aber ich habe im Netzwerk gern Geräte, mit denen man vernünftig arbeiten kann - nicht solche, die man nur reinhängt, um Verantwortung von sich weisen zu können.

Im Vergleich dazu fand ich eine Sophos vom Handling um ein Vielfaches angenehmer, obgleich ich diese auch nicht wirklich mag. Bei Sophos und Securepoint finde ich die Dokus und Forenunterstützung mehr als dürftig.

Ich betreue überwiegend (allerdings etwas größere) Arztpraxen und keine bekommt von mir eine UTM.
Diese vermeintliche Anforderung gibt es nicht und sie wäre auch kontraproduktiv.
Diskussion seinerzeit zur IT-Sicherheitsrichtlinie der KBV: Was ist nach Paragraph 75B SGB V eine Firewall?

UTMs verbessern IMO nicht die Sicherheit der Netzwerke von Arztpraxen, sondern gefährden sie. Die Problematik und Diskussion zum Thema "Schlangenöl" ist ja hinlänglich bekannt und wer fleißig heise security oder die CVE News verfolgt, sieht auch, dass die UTMs fast im Wochentakt mit Angriffsmöglichkeiten glänzen. So ein Gerät gehört nicht ans Perimeter bzw., wenn schon, wie ich es aus der Industrie kenne, dann kaskadiert mit der UTM eines anderen Herstellers.
Jede Firewall braucht Kenntnisse und regelmäßige Wartung/Einrichtung/Überprüfung/Monitoring. Für Kleinkunden wie Arztpraxen ist das kaum zu leisten, jedenfalls sind UTMs nicht die Tools, die das wirtschaftlich vertretbar gewährleisten. Ein Beispiel dafür, wie das dann in der realen Welt aussieht, findet sich hier.

Die Sicherheit des Netzwerkes (nicht nur) jeder Arztpraxis ist, gleich welches Gerät Verwendung findet, nur so gut wie die Networking-Kompetenzen ihres Dienstleisters. Daher meine Empfehlung: Setze Geräte ein, auf denen Du Dich wohl fühlst und dessen wesentlichen Funktionen Du beherrschen kannst.

OpenSource-Firewalls wie OPNsense oder PfSense sind vom Handling IMO besser, haben (soweit Englisch kein Hindernis ist - OPNsense hat sogar auch ein gutes deutsches Forum) gute Dokus und Foren und auch eine größere Verbreitung. OPNsense ist die Hausempfehlung von Thomas Krenn - für mich eine anderes Niveau als Terra Außerdem haben OpenSource-Firewalls keine Hersteller, die ihren Code verstecken müssen.

Ich selbst setze am Perimeter von Arztpraxen ausschließlich Mikrotik-Router ein. Das Firewalling ist sowohl rechtlich wie praktisch weit mehr als ausreichend, die Netzwerkfeatures und damit die Möglichkeiten, sein Netzwerk abzusichern und/oder transparent zu überwachen mehr als vielfältig. Wenn ich dann mal wieder auf das träge Webinterface einer UTM muss, freue ich mich immer, dass das nur noch selten der Fall ist.

Alle UTM-Fans dürfen solche bleiben

Viele Grüße, commodity

'+1 OPNsense
TI ist bei mir auch Thema, ich kenne im Gesundheitsbereich jemanden, dessen IT Audit abgehakt wurde, mit aktiver OPNsense (sogar ohne ZenArmor). Dienstleister zu finden ist auch kein Problem.

Verrückt machten uns zuvor Aussagen, man bräuchte eine "speziell zertifizierte" Firewall, dürfte also gar keine OPNsense in dem Bereich nutzen.

Sophos kann ich nicht mehr empfehlen, hab es viele Jahre genutzt.
Sophos UTM EOL - Ersatz für Mailgateway (mandantenfähig)

Ja, da geistert einiges an Fehlinfos rum. Und nichts vom vermeintlichen UTM-Nutzen ist wissenschaftlich belegt. Die Gefahren jedoch immer wieder anschaulich veröffentlicht. Am Ende ist Sophos ja gar selbst in die Netze seiner Kunden eingedrungen. Bodenlos.

Hier kann man auch nochmals nachlesen, dass die KBV-Richtlinie keine UTM- oder NGFW-Firewall fordert - Nr. 12 (die Antwort dort lautet "Hardware-Firewall").

Viele Grüße, commodity

Ist ja auch so nen Unsinn. Da projeziert jeder rein, was er will. Je nach Sichtweise genügt es schon, dass die HW noch mit Sicherheitsupdates versorgt wird. 😉

Keine Ahnung, wie das die Kollegen sehen. Aber bei einigen Punkten der BSI-Liste sag ich: Das bringt jede Fritzbox mit. Bei anderen, „gehört zum guten Ton, wenn ich schon ne OPNsense konfiguriere, und bei manchem „ist halt Kanonen auf Spatzen“.

Es bleibt halt eine 1-Personen-Praxis. Klar kannste da ne dicke Kladde anlegen und hinter jede Admin-Ebene und Aufgabe Deinen Namen „dokumentieren“ und Dir ein beweissicheres Dokumentationstool für alle Änderungen anschaffen. Und Du kannst auch mehrere unterschiedliche Firewalls in Reihe&Serie schalten. Du kannst auch ausgehend mit allow-Lists arbeiten. Ich vermute nur, Dein Kunde wird Dir da irgendwann aufs Dach steigen.

Du kannst die Firewall übrigens auch einfach als DL einkaufen – speziell für diese Kundengruppe. Da kommt dann am Ende übrigens so nen „Terra-Döschen“ raus und wird als 100% Aufwand verbucht.

nein. Zumal der "Stand der Technik" so gar nicht bestimmt werden kann. Das ist ja von hunderten Parametern abhängig. Wäre ja auch noch schöner, wenn die Marketingheinis von Sophos & Co. jetzt schon den "Stand der Technik" definieren. Das ist sicher ihr feuchter Traum.
Darf ich dann nur noch MS365 einsetzen? Oder Amazon S3? Welche KI? Windows, Microsoft überhaupt? Ist das Stand der Technik? Von den Russen gehackt, ein - von der CISA belegtes - Chaos an Defiziten in Organisation und Sicherheit? Und Linux geht ja gar nicht. Das benutzt ja keiner (?), das kann ja nicht Stand der Technik sein - oder? Na, dann fang mal an auf Apple umzurüsten.

"Stand der Technik" braucht schon einen gewissen fachwissenschaftlichen Unterbau, um Bestand vor den (allerdings technisch nicht ganz auf dem Stand befindlichen) Augen der Justiz zu haben. Germany ist ohnehin so rückständig in Sachen IT - da ist sowieso kaum etwas "Stand der Technik". Selbst LANCOM wird ja hier auch immer noch als Edelmarke gepriesen. Und oben las ich von Securepoint. Ein Witz, wie ich finde. Aber das ist nur meine unbescheidene Meinung.

Hier sind die Admins im Land versammelt, die sich über technische Fragen austauschen - auch wenn wenige schreiben, lesen einige mehr mit. Und die, die sich äußern, diskutieren hier immer wieder über die OPNsense, PfSense, Mikrotik und meinetwegen, es kommt mir schwer über die Tasten, auch Unifi u.a. . Wenn das so wider den Stand der Technik wäre, würde das schon durchscheinen, meinst Du nicht?

Würde der immer gern zitierte und fraglos höchst kompetente Kollege @aqui Netgear-Switche z.B. als "Stand der Technik" durchgehen lassen? Wo ist die Grenze? TP-Link? Oder ist alles unter Cisco-Niveau nicht DSGVO-Konform? Ist ein heute noch heißes Teil morgen nicht mehr "Stand der Technik", weil jemand ein noch heißeres neues Feature am Markt anpreist? Real setzt sich ein "Stand der Technik" eben erst nach Jahren als solcher durch, weil er erst dann eine Akzeptanz und Verbreitung gefunden hat, dass es als "Stand" angesehen werden kann. Zu diesem Zeitpunkt gibt es aber schon wieder viel moderneres Zeugs. Ob das besser ist und vielleicht mal zum "Stand der Technik" wird - oder es ein Rohrkrepierer war, zeigt sich dann erst deutlich später.

In vielen Teilen der Welt wird Mikrotik auch in Rechenzentren eingesetzt, sogar im Mutterland von Cisco . Der großartige Network Berg hat nach seinem Umzug von Südafrika nach GB beschrieben, dass er als RZ-Admin für Mikrotik erstmal Schwierigkeiten hatte, weil das in Europa so wenige Businesses nutzen. Ja, die alten Giganten haben eben ein gutes Marketing, dort wo Geld keine Rolle spielt. Woanders zählen andere Werte. Vielleicht sogar mehr technische? Wer weiß das schon.

Du siehst, mit dem Stand der Technik ist es nicht so einfach. Und jetzt brechen wir das mal auf die Branche "Niedergelassene ÄrztIn" runter. Die technisch ja unterste Anforderungen hat und wo die Fritzbox regiert. Wie schon zuvor beschrieben: Die KBV-Sicherheitsrichtlinie verlangt nicht einmal zwingend eine HW-Firewall.
Ich wage zu behaupten: Mehr als 90 % der Praxisbetreuer - inkl. der PVS-Betreuer sind nicht auf dem Stand der Technik. Und viele würden es zugeben. Ein DSGVO-Verstoß? Schon, dass Du Dir Gedanken machst, hebt Dich zugunsten der Sicherheit Deiner Kunden aus der Masse der Betreuer heraus.

In kleinen Praxen (bis 3 Ärzte) tut es ein hAP ac2 (ist leistungsfähiger als der alte hEX und kann WLAN) oder (heute) ax2, wenn es günstig sein soll, sonst würde ich ein RB5009 einsetzen - den wollte aber bislang keiner explizit und die hAPs tun es seit Jahren. In größeren Praxen kam es dann auf die 200 EUR auch nicht mehr an und es gab einen CCR2004-12G - was IMO eine gute Wahl ist, wenn auch für den Usecase völlig overpowered. Aber kostet eben auch nicht nennenswert mehr als eine neue Fritzbox - bei völlig anderem Niveau.
Aber Vorsicht: Steile Lernkurve. Mikrotik muss man wollen. Danach aber fühlt man bei allem anderen das Korsett

Viele Grüße, commodity

Moin,

wieso nimmst nicht gleich einen Mikrotik Router (z.B. den RB5009UG+S+IN) und je nach Anschluss ein passendes Modem davor, der kann doch alles was du benötigst und seitens des BSI gefordert wird.
Und wenn du nicht ganz parat kommst mit der einstellung, einmalig was hilfe buchen und wenn alles fertig ist die config exportieren als skript und du brauchst es dann nur noch für andere Praxen anpassen.

Grüße

Du kannst das ja für Dich interpretieren, wie Du magst.

Tatsächlich wird in beiden Normen der "Stand der Technik" zwar in Bezug genommen, aber in keiner Weise definiert. Kurz gesagt, der Aussagewert ist Null. An dieser Stelle geht der Interessierte z.B. in die Bibliothek seines örtlichen Jura-Fachbereiches und liest den Kommentar zu DSGVO bzw. BDSG dazu oder, wenn er Geld anfassen möchte, befragt er vier Anwälte und bekommt fünf Meinungen

Die Anforderung "dem Risiko angemessenes Schutzniveau" ist doch gleichermaßen selbstverständlich wie wachsweich wie selbstverständlich, jedenfalls sagt sie nichts über den "Stand der Technik" aus. Und dass war ja die Frage.

Die Anforderung des § 64 BDSG: "Der Verantwortliche hat hierbei die einschlägigen Technischen Richtlinien und Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik zu berücksichtigen..." wäre zwar ebenfalls unproblematisch, weil das BSI ja jedenfalls nicht mehr als eine "Firewall" (= kein UTM, kein NGFW) fordert, sie ist aber vor allem nicht maßgeblich, denn Du hast wahrscheinlich überlesen, dass Teil 3 (§§ 45-84) des BDSG gem. § 45 BDSG nur für "die Verarbeitung personenbezogener Daten durch die für die Verhütung, Ermittlung, Aufdeckung, Verfolgung oder Ahndung von Straftaten oder Ordnungswidrigkeiten zuständigen öffentlichen Stellen" gilt. Das hat mit Artzpraxen nichts zu tun.


Die Sorge ist IMO unbegründet, obgleich natürlich die Tendenz besteht, den Kunden ausschließlich an sich zu binden. Dennoch kenne ich nicht einen PVS-Anbieter, der dem Kunden netzwerkbezogene Vorgaben machen würde. Die Anbieter sind im Allgemeinen netzwerktechnisch äußerst schlecht aufgestellt und wissen das auch. Natürlich besteht immer das Problem, dass der PVS-Anbieter bei einem Problem behauptet, es liege außerhalb seiner Sphäre - dann musst Du natürlich nachvollziehbar darlegen, warum es nicht an Dir liegt - oder besser: wo es liegt. Auch deshalb liebe ich die Mikrotiks, weil man nämlich jedes Paket sehr einfach verfolgen und loggen kann. Aber die Senses können das auch (wenn auch nicht so komfortabel) und ein Wireshark tut es am Ende auch.

Aber klar, man muss selbst natürlich einigermaßen fit sein, wenn man gegen etwaige Zuständigkeitskonflikte bestehen möchte. Ich habe dass aber noch nie als problematisch erlebt. Es gab vielmehr früher öfter problematische Situationen, weil der PVS-Supporter am Netzwerk rumfummelte und dabei mal eben z.B. Eingangs- und Ausgangsports verwechselte. Die Kollegen beim PVS sind ja keine Unmenschen, die erkennen auch, dass sie da nicht so viel Ahnung haben - und wenn Du ihnen dann erklären kannst, warum dass Problem nicht bei Deinem Netzwerk liegt, wird natürlich weiter supportet.

Was die Praxisinhaber angeht, war das bei mir nie eine Frage. Neben dem Kompetenzthema, mach mal einen Preisvergleich: Eine von z.B. CGM gestellte Firewall kostet m.E. nach ca. 80 EUR netto monatlich. Ein hAP ax2 kostet einmalig ungefähr das gleiche.
Hinzu aber kommt (und dass wiegt viel mehr): Eine Firewall, wenn sie streng konfiguriert ist, braucht (zumindest Gelegentlich) Wartung/Support, Updates, Feinschliff. Wenn nicht sowieso gemonitort, sollte man auch von Zeit zu Zeit mal die Logs untersuchen. Jedes Mal muss dann der PVS-Support für viel Geld ran, das ist im Allgemeinen teurer und viel unflexibler, als wenn das der DVO macht. Hinzu kommt, dass eine individuelle Konfiguration von denen nicht gemacht wird. Die PVS-Anbieter spielen Template ein und das war es dann. Ab dann wird kassiert.

Wenn Dir bei alledem aber Dein Bauchgefühl sagt, das ist nichts für Dich, dann ist es doch auch völlig ok, wenn Du das dem PVS überlässt und die All-in-one-Lösung kaufst. Wie ich oben schon schrieb, Du musst Dich (mit dem, was Du einsetzt) wohl fühlen.

Viele Grüße, commodity

@knurrhahn

Von mir auch noch ein paar Gedanken, die mir zu Deinem Beitrag durch den Kopf schossen:

Grundsätzlich:
Bzgl. einer Firewall reden wir immer von einer stateful firewall. D.h. konkret, von außen sind alle Ports "grundsätzlich" geschlossen. Nur wenn vom lokalen Netz ein Anfrage nach außen durchgereicht wird, darf die Antwort von außen durch den jeweiligen Port auch zurück. Insofern sind auch alle "stateful" Firewall erstmal "gleich sicher" – auch ne Fritze.

Router: Soll routen. D.h. im "plain-mode", default, usw. ist da keine Firewall aktiv und zwischen den verschiedenen Netzwerken wird erstmal transparent hin/her-geroutet. Du musst hier also eine (ggfs. stateful) Firewall erstmal aktivieren/konfigurieren.

Firewall (PF-, OPNsense, Sophos, ...): Hier ist im default erstmal überhaupt kein Verkehr zwischen unterschiedlichen Netzwerken/IP-Adressbereichen möglich – außer Du erlaubst es. Das Konzept ist sozusagen spiegelverkehrt zum Router und entspricht eher dem BSI-Ansatz des "whitelistings".

Beides kannst Du sicher konfigurieren, beides kannst Du unsicher konfigurieren, mit beidem könntest Du "whitelisting" betreiben. Nur bei der Firewall hast Du üblicher Weise mehr Einflussmöglichkeiten (geoblocking, autom. blocken von Angreifern, Proxis, Virenscanner, Pishingfilter, DNS-Filter, ... ). Dafür hast Du beim Router häufig eine - für Kleinstunternehmen - praxisgerechtere HW (mehr Ports, ggfs. PoE, Wifi, ...) die Dir weitere Zusatzgeräte (Switche, Kabel, Netzteile, ...) einspart. Im Fall von Mikrotik gibt es über Docker evtl. auch Möglichkeiten weitere Zusatzfunktionen hinzuzufügen – wenn man das ausgerechnet auf ner Firewall denn wollte.

BSI: Das von Dir oben verlinkte Papier richtet sich an alle Firmen(-größen). Klar kann man jetzt sagen, dass sensible Arztdokumente den höchsten Schutz genießen sollten. Aber seien wir ehrlich: Die Angriffsvektoren eines Mittelständlers, Behörde, internationalen Consultingunternehmens, sind andere, als die Beziehungsprobleme Lieschen Müllers.

Zudem skaliert die Firewall-Lösung für nen Mittelständler (mit eigener, geschulter IT) einfach anders, als für nen 1-Mann-Klitsche wo die mickrigste Sophos inkl. LIzenz 1.000 EUR +x kostet – ohne Konfiguration! Und Du bist dann ja immer noch nicht auf der gewählten Firewall geschult bzw. erfahren ... oder?

Und das alles nur um nen Windows-PC mit Psyprax und nen Drucker zu sichern – wobei Psyprax für die Abrechnung doch sowieso ne VPN aufbaut, so ich das recht entsinne.

Habe ich das BSI-Papier richtig in Erinnerung, gibt es Forderungen a la
a) Mehrstufigkeit: dafür könntest Du den lokalen PC "nachrüsten" bzw. -härten.
b) Getrennte Userkonten – macht ja nur Sinn, wenn es mehrere Bediener gibt.
c) getrennte vLANs: kannste im Prinzip auch mit dem GästeLAN der Fritze aufbauen. Praxisgerecht macht das aber natürlich jeder Business-Router und jede Business-Firewall
d) "Härten" in dem man Funktionen deaktiviert, die einfache Geräte gar nicht haben
e) ...

Häufig Dinge, die nach innen wirken und den Zugriff unbefugter Akteure aus dem lokalen Netzwerk limitieren sollen. Wenn bei Dir nur ein PC und ein Nutzer arbeitet, ist Potenzial hier aber überschaubarer als bei nem Mittelständler.

Vieles der BSI-Liste habe ich hier (unwissentlich) schon realisiert. Aber das ist hier eher "Hobby" – das rechne ich nicht "richtig" ab. Willst Du das als Kundendienstleistung abrechnen wird Dir Deine 1-Mann-Klitsche aufs Dach steigen. Und Du würdest (und könntest auch nicht) ja immer noch keine Haftung dafür übernehmen - oder?

Deswegen ja die Unternehmen (übrigens GmbHs 😉 ) die das als Template-DL zentral einmal anlegen und dann an alle Kunden ausrollen für - gerade geschaut - aktuell 50 EUR/Monat. Ich dachte eigentlich meine Kundin hatte dafür sogar nur um die 20 EUR/Monat gezahlt. Und wenns Probleme mit Psyprax gibt – klärt das Psyprax und der Anbieter unter sich.

Hallo zusammen,

@knurrhahn
du schreibst:


Ich gehe davon aus, dass der Sinn hier die Trennung des "Internet-Alltags" vom "Praxis-Alltag" ist, korrekt?
Wie realisieren diese Praxen dann Anfragen von Patienten via Email mit ggf. Anhängen?
Wird dies dann über nen USB Stick übertragen?

Grundsätzlich sitze ich im gleichen Boot und möchte schon längst von der "Fritte" weg und OPNSense im Einsatz sehen, doch habe Bedenken bezüglich:
.Verbindungsproblemen, auf die sofort reagiert werden muss und
.dem Zusammenspiel mit dem Support des PVS-Anbieters und Laboren.

@commodity
wie handhabst du Verbindungsprobleme? ich kenne die eingesetzte Konfiguration nicht, kann mir jedoch vorstellen, dass du Ports, Protokolle und Adressen einschränkst.
Wie oft wirst du mit Problemen nach einem PVS Update konfrontiert, aktuell z.B. bezüglich ePA,
bei denen du dann sofort
1. rausfinden musst, welche ports/Protokolle gebraucht werden
2. diese entsprechend im Regelwerk anlegen musst
je nach Absprache mit dem Auftraggeber, bist du nach einer bestimmten Reaktionszeit im Einsatz, im besten Fall exklusiv, sprich niemand außer dir darf die Konfig anfassen.

@all Praxis-EDV-Admins
wie handhabt ihr den Zugriff auf kritische Komponenten wie z.B. Router?

Gern öffne ich hierzu auch einen separaten Thread, da es hier ja eigentlich um Hardware-Empfehlungen gehen soll und nicht
wie die Hardware und der Zugriff auf diese im Zusammenspiel mit weiteren Dienstleistern gehandhabt wird.

Cheers

@improver
gute Gedanken, finde ich. Deine Sorge ist IMO unbegründet.
Das ist bislang gar kein Problem. Ich schränke Ports und Protokolle ein, dies aber nicht für das TI-VPN. Das VPN wird vom Konnektor aufgebaut. Der Konnektor routet dann ins VPN. Ich sehe bislang nicht, warum ich da etwas filtern sollte.

Für das SNK-Routing (ehem. KV-SafeNet) brauchst Du IMO nur 443. Es gibt aber erstaunlich wirre Infos zu freizugebenden Ports. Ganz gut ist dieser Link: ti-community.de/wiki:benoetigte-offene-ports-zur-ti

Der Rest des WWW nach Bedarf. Für Adressen gibt's (nicht überall) ein DNS-Filtering mit allgemein verfügbaren Listen.

Alles, was in der TI abläuft, kann sich also verändern, hauptsache das TI-VPN steht. Für die ePA habe ich nichts umgestellt (bislang nur bei CGM-Software am Laufen). Nach Updates gab es noch nie ein Verbindungsproblem, die Konfigs laufen seit mehreren Jahren.

Vereinzelt waren im Übrigen in den vergangenen Jahren dennoch Portanpassungen nötig, z.B. wenn ein medizinisches Gerät angeschlossen wurde, was Ports zum Anbieter brauchte oder ein Labor. Meist ist das aber alles 443, zumindest, soweit es mir begegnet ist.
Viel häufiger habe ich das Thema zuhause weil auch das Kindernetz beschränkt ist und die Games immer mal wieder neue Freigaben brauchen.

Wie auch immer, im Mikrotik (wie sonst auch) siehst Du im Log sofort, wenn ein Port geblockt wird (wenn Du es einstellst natürlich nur - ist ja Mikrotik ). Also wenn eine Praxis anruft und sagt es geht was nicht, guckst Du nach, gibst nach Prüfung den Port frei und dann geht es. Das sind 30 Sekunden (wie gesagt, RouterOS ist im Handling hervorragend).
Bei neuen med. Geräten erwarte ich prinzipiell, dass ich vorher eingebunden werde und nehme Rücksprache mit dem Anbieter. Da muss ich ja ohnehin wissen, was die installieren und wo sie ihre Datenbanken lagern (und ob sie Sonderbehandlung brauchen). Wenn ich dann etwas von Freigaben erfahre, setze ich die natürlich gleich.

Ich halte mich für sehr offen und flexibel in der interkollegialen Kommunikation, aber an den Router darf dennoch niemand außer mir. Ich programmiere ja auch nicht das PVS um Auch hier sind die Mikrotiks ein Vorteil, die können so wenige Bedienen, dass Konflikte praktisch ausgeschlossen sind. Die PVS-Kollegen klicken ohnehin immer weg, wenn sie sehen, dass da keine Fritzbox werkelt und sonst will da eh keiner ran.

Viele Grüße, commodity

Der URL oben ist leider falsch und führt zu einem Fehler! Korrekt ist:
ti-community.de/wiki:benoetigte-offene-ports-zur-ti

Danke Ist korrigiert. War das c von community verloren gegangen.

Viele Grüße, commodity

@commodity und @aqui
Dankeschön!
Anscheinend habe ich vergessen, mich benachrichtigen zu lassen zu dem Thema und sehe nun zum Feierabend die Antworten, somit ein kurzes:
morgen habe ich noch ne Frage zu Reaktionszeiten und "interkollegialer" wie auch interdisziplinärer Arbeitsweise.
Doch für heute :"ich abe fertich".
Cheers

PS.:
im "administrator.de Konto-Bereich" sind alle Häckchen gesetzt bei "Benachrichtige mich bei folgenden Aktivitäten"
Thread ist in der Leseliste abgelegt.
Warum habe ich keine Nachricht erhalten?

Daran wird es nicht liegen, aber
Häckchen !=Häkchen

Ich habe i.Ü. keine Ahnung, ob Email-Benachrichtigungen funktionieren, ich habe Website-only aktiviert und das funktioniert.

Viele Grüße, commodity

@commodity
Danke für deinen Beitrag Geeignete Firewall für Telematik Infrastruktur in Kleinpraxen?

Der Link ist sehr hilfreich, doch scheint veraltet.
Hier wird zumindest der RISE Konnektor noch nicht genannt:
Managementschnittstellen der Konnektoren

Betreibst du Konnektoren generell im gleichen Subnetz oder in einem separaten VLAN?
Falls VLAN, wie reagiert der PVS Support auf diese Konfig?

gute n8

ps.: der Haken mit dem Hacken ist mein Lieblingsrechtschreibfehler

Danke. Der Link mag alt sein, aber

1. ist das ein Wiki, feel free, daran mitzuwirken und
2. besteht zumindest bei dem Cloud-Konnektor, den ich kenne gar kein Zugriff auf die Management-Schnittstelle. Ist das beim Rise-Konnektor anders?

Letzteres ist auch der Grund, warum ich von Cloud-Konnektoren nicht viel halte. Zum einen sind sie mindestens doppelt so teuer, zum anderen muss man für jede Anpassung an den Dienst herantreten. Das bedeutet, das Änderungsanliegen, das man in 2 Min. am Konnektor selbst gemacht hätte, nun als "eindeutige" Konfigurationsanweisung zu formulieren, niederzuschreiben und an den Dienst zu senden. Dort bekommt das dann ein mehr oder weniger lustloser Kollege, setzt (Erfahrung) die Hälfte davon um und schließt das Ticket. Dann Da Capo, man erklärt in einem weiteren Ticket nochmals, ggf. mit anderen Worten, was man wollte und hofft. Ein bis zwei Wochen später ist die Änderung dann eingearbeitet.
Das nenne ich mal Produktivität. Und auch die Kosten vor Ort sind deutlich höher, weil man statt einer Änderung mehr und aufwändigere Arbeitsschritte hat.

Richtig übel wird es, wenn man selbst keine Ahnung vom Konnektor hat und dann den PVS-Support braucht - der aber niemals direkt den "Fremdkonnektor"-Betreiber kontaktieren würde, so dass man dann zwischen beiden dolmetschen muss. In solchen Fällen: Wenn schon Cloud, dann besser auch die Cloud des PVS-Herstellers.

Der Cloud-Konnektor wird über VPN-erreicht, dorthin wird einfach geroutet. Die lokalen Konnektoren betreibe ich im selben LAN, ansonsten (bei ausreichend Paranoia) kann man auch in ein spezifisches Konnektor-LAN routen. Nur die Kartenleser müssen im selben Netz sein, wie der PVS-Server.

Dem PVS-Support ist das prinzipiell wurscht, der braucht ja nur die Adresse des Konnektors.
Selbst das (zumindest) bei den CGM-PVS notorisch untergeschobene lokale Routing kommt damit klar.

Viele Grüße, commodity

Alles klar. Ist mir zunächst nicht aufgefallen, dass es ein open-Source-wiki ist.
Es ist durch einen "Ex-Gematik-Mitarbeiter" gegründet und wird von ihm wohl gehostet.
Dies kann sich zu einer wertvollen Resource entwickeln.

Ist schon verrückt, wie das ganze Thema implementiert wurde und wird, so dass ein Ex-AN sich dazu bewegt fühlt, know-how zu sammeln. Meines Achtens sollte dies von den "Wartungspauschale-Kassierern".. naja.

@commodity
Danke für deine Ausführungen zum Setup.
Danke auch für die Ausführungen zum Cloud-Konnektor.
Den RISE Konnektor gibt es auch als Blech:
rise-konnektor
Ich war zunächst ganz angetan vom "ersten Cloud-Konnektor" von REDmedical:
Konnektor-Hardware raus aus der Praxis, VPN zum Konnektor im Rechenzentrum und nie wieder mit dem Mist beschäftigen (PTV Updates, etc)
doch deine hands-on Erfahrungen sprechen für sich.
Ist natürlich vorteilhaft Konnektoren managen zu können, doch ohne entsprechendes Wissen geht das nicht. Dieses Wissen wird ja auch nicht offen kommuniziert. In 2018/2019 war ich beim "Rollout" der ersten Konnektoren dabei. Wir als DVO und Partner eines PVS durften die Dinger samt Kartenterminals installieren, jedoch anschließend nicht mehr supporten. Dies sollte ursprünglich nur noch durch den "TI-Support" erfolgen.
Irgendwann (3-4 Jahre danach) wurde Schritt-für-Schritt die Strenge gelockert, ich konnte einigen Installationen beiwohnen und somit Wissen aneignen, welches nun im Alltag Anwendung findet, sprich Anbindung von Kartenterminals und Arbeitsplätzen.
Meines Achtens ist dies rechtlich jedoch ein Grau-Zone da es offiziell nie die Freigabe für den DVO gab die vor-Ort-Konnektoren zu managen.

Gibt es dies bei CGM?

Schönes Wochenende!
Cheers

Das ist interessant.

IMO ist das Thema schmerzfrei geklärt und Deine Erfahrungen sind eher auf die Fehlinformations-Strategie der PVS zurückzuführen. Ich bin sei 2017 an der TI dran und es war (jedenfalls für mich - damals auch nicht professionell in der IT unterwegs) lange wirr und man hatte keine Informationen (bzw. Quellen), man musste sich mühsam was zusammen suchen.

Und immer, wenn man den PVS-Kollegen dabei hatte, zuckte der, wenn man was am Konnektor gemacht hat, von wegen "wir sind dafür ausdrücklich geschult...", "das dürfen nur zertifizierte Dienstleister..." usw. Dabei hatten die "ausdrücklich geschulten" Kollegen vom Netzwerken so viel Ahnung wie ich von Farsi.

Irgendwann kam (stieß ich) auf das DVO-Handbuch - und das beantwortete die Frage ja eindeutig. Es gab/gibt auch noch eine direkte Aussage der Gematik, die habe ich aber nicht zur Hand.

und

Da ja auch sicher nicht ganz grundlos den ÄrztInnen die Zugangsdaten überlassen worden waren, war also der Weg frei.

Dass die lokalen PVS-Betreuer das anders sahen, wie Du sagst,
liegt in der Natur der Sache: Ich habe seinerzeit gehört, dass CGM ihre Partner für die Schulungen kräftig zur Kasse gebeten hat. Das wollte/musste man natürlich amortisieren.
Rechtliche (auch nicht vertragliche) Regeln darüber habe ich nie gesehen. Und in der Sache: Wer einen Konnektor ans Laufen bringen konnte (siehe DVO-Handbuch), der wird die Einrichtung ja wohl können.
Auch ist in 5.1 des DVO-Handbuches ja ausdrücklich als Aufgabe des DVO definiert:
Mangels kollegialer Zusammenarbeit musste man sich die Struktur im "Infomodell" und die Umsetzung im PVS allerdings selbst herleiten. Ob man sich das antun sollte oder doch lieber den PVS-Kollegen ins Boot holt, muss man je nach Lust und Selbsteinschätzung für sich entscheiden. Selber forschen ist nicht immer wirtschaftlich.

Dass man übrigens die Rechenzentrumskonnektoren (jedenfalls bei Akquinet) nicht selbst managen darf liegt faktisch nicht an TI-rechtlichen Hindernissen, sondern an praktischen und vielleicht datenschutzrechtlichen. Akquinet betreibt (oder betrieb bis vor kurzem) simple KocoBoxen, nur dass sie mehrere Kunden auf eine Box legen. Da kannst Du dann natürlich nicht mehr drauf, ohne die andere Praxis zu beeinflussen.

Viele Grüße, commodity

Toller Fund, Danke!


Ich würde sagen, noch nicht..

Es gibt ein von der KBV erfundendes Zertifizierungs-DingsdaBumsda:


und diese Zertifizierung lassen die sich auch bezahlen:


Quelle

Einziger Hinweis zur Vorbereitung:


".. muss daher mit der Methodik.." ist sehr allgemein gefasst.

Grundsätzlich begrüße ich eine Art "Führerschein" für sysadmins, habe jedoch Bedenken,
dass es Praxis-ferne Anforderungen gibt bzw.
hieraus eine "Gier-frisst-Hirn" Mentalität wächst, wie wir es in den Jahren seid "Bankkaufmann-Gesundheitsminister" zu sehen bekommen haben, welche irgendwann die KI thronen lassen möchte, da sich das besser zentral verkaufen lässt.

Ich habe einfach den Eindruck gewonnen, dass niedergelassene Ärzte als "Zahl-Vieh" entdeckt wurden und dieser Trend führt gerade dazu, dass die "frischen Ärzte" keine Lust mehr haben auf "niedergelassen" sondern in die MVZs und Krankenhäuser abwandern.

Tschuldigung, abgeschweift..

Schönes Wochenende!

Cheers

nein, die "Zertifizierung" hat weder mit dem Konnektor/DVO etwas zu tun, noch hat es rechtliche Wirkungen:

1. geht es um die IT-Sicherheitsrichtlinie der KBV. Das hat nichts mit der TI (Telematik-Infrastruktur) zu tun, die die Gematik unter ihren Fittichen hat.

2. Sagt die KBV selbst in ihren FAQ (Nr. 1), dass die Zertifizierung nicht erforderlich ist, um die TI-Sicherheitsrichtlinie umzusetzen. Sie soll bloß eine Art Ausweis am Markt sein, um sich den Ärzten als IT-Sicherheitsmensch präsentieren zu können. Weil man sich Ärzten nicht präsentieren muss (weil eh Mangel an guten Systembetreuern), macht das auch kaum einer. Zumal das Niveau auch unterirdisch sein soll (Deutsche IT halt). Sieht man ja auch schon an der schwabbeligen Sicherheitsrichtlinie selbst, die ein praktischer Informatiker mit mittleren Kompetenzen nie so verfasst hätte.

Niedergelassene Ärzte jammern viel, dass sie Zahlvieh sind und natürlich ist der Gematik-Beta-Wahn teuer. Die TI ist schwach projektiert worden, wie oft in D standen fachlich schwache Funktionsträger Anbietern gegenüber, die ihre Bereicherungspotentiale gesehen, statt an das Gemeingut "Gesundheitsversorgung" zu denken. Milliardenteure Konnektoren wären nie gebraucht worden (wie man ja nun faktisch eingestanden hat). Verschlüsselung + VPN mussten ja nicht neu erfunden werden. Man hätte auf OpenSource setzen können, aber in D heißt ein IT-Projekt machen eben, ich setzte ahnungsarme Leute in Funktion und Budget, die dann eben eine Lösung "einkaufen". Dafür braucht man dann die "Industrie" und in der Medizin, stets gebremst durch das MPG, kommt dann erstmal was unausgegorenes teures raus. War beim beA bei den Anwälten ähnlich (da konnte ich ein bisschen hinter den Vorhang schauen). Mittlerweile ist die TI doch aber gereift und auf einem Weg, mit dem man arbeiten kann. Kostenintensiv bleibt's aber sicher.

Die Ärzte vergessen aber, dass sie zu vor-PC-Zeiten mit Karteikarten, Schreibmaschine und Briefporto auch Kosten hatten. Da sprangen oft ein paar mehr MFAs herum. Das Problem ist eher, dass die Nichtfachärzte heute viel schlechter verdienen als früher (dennoch gut) und ihnen das Geld "fehlt". Besonders denen, die andere Zeiten erlebt haben. Die meisten Ärzte haben im Übrigen gar kein Verhältnis zu sinnvollen Kosten, weil sie sich nicht mit der Materie beschäftigen. So kaufen sie z.B. immer gern Gerätschaften neu, geben aber nicht gern Geld für deren Bedienung und Wartung aus. Das gibt dann 5 K für eine Firewall, die aber nie jemand einrichtet Oder eine teure Software, die niemand richtig bedient, weil man für Fortbildung der MA nichts ausgeben wollte (oder nicht dran gedacht hat).

Ich versuche, dieses Prinzip umzudrehen. Habe z.B. gerade mal wieder einen 22K-Server durch einen 2K Commodity-Server ersetzt (der nebenbei gesagt 3x so schnell ist, wie es ein neuer 22K-Server gewesen wäre). Bleiben 20K Ersparnis, die man nun guten Mutes in den Support stecken kann. Und das erkläre ich auch so. Ein Gewinn für beide Seiten.
(In diesem Forum ist man aber kein Mann, wenn man nicht sinnfrei lahme und teure Serverhardware verbaut )

Aber jetzt bin ich abgeschweift

Danke dito!
Viele Grüße, commodity

P.S. In Krankenhäuser wandert kaum ein Facharzt freiwillig ab. Da steht man nur noch im Sumpf. Das Gesundheitssystem überfordert seine "Administratoren" und es ist schwierig bis unmöglich, das in einer Legislatur zu erfassen, geschweige denn zu ordnen.
Zumal kleinste fürs Volk "nachteilige" Veränderungen heute gleich zu größtem Geschrei führen, weil es immer Gruppen gibt, die das "(un)sozial" für sich vermarkten und den Leuten den Blick für das Ganze nehmen. Der ist zu komplex.
Beispiel: Das System würde sehr wahrscheinlich durch einen einzigen Karenztag massiv entlastet werden, sowohl im Gesundheitssektor als auch in der Wirtschaft. Jedenfalls sagen das die Fachleute an der Front. Dennoch wird das bislang nicht einmal ernsthaft erwogen, denn das bedeutet ja Einkommensverlust und der wiederum Zeter & Mordio. Früher hatten wir eine Bild-Zeitung, heute schreien tausende sog. neuer Medien und stecken dabeo auch die alten an.

Endgültig off topic
done

Danke @commodity!

und


sehr nice! Dem eigenen Werk einen Namen zu geben macht es einfach schicker.
Ich habe bislang nur von "guten Gebrauchten" gesprochen.

Guten Start in die Woche!

Cheers

Nein, andersrum. Mein Nick kommt vom Terminus "commodity hardware". Und diese Ware ist natürlich brandneu.
Danke dito!

Viele Grüße, commodity

Das hast Du gut bezeichnet. Das BSI reklamiert den Stand der Technik für sich. Und das in der Tat recht kraftvoll.

Fakt ist, im Anwendungsbereich der DSGVO (um den es hier allein geht) wird der Terminus "Stand der Technik" weder legal definiert noch diese Definition einer Organisation zugewiesen. Dass das BSI den Terminus selbst verwendet verleiht ihm weder Kompetenzen noch die Vermutung sachlicher Richtigkeit, was dessen Interpretation angeht. Im Streitfalle ist es Aufgabe des Gerichts, zu ermitteln, was Stand der Technik ist und ob es einen solchen gibt.

Dass das BSI nicht der Weisheit letzter Schluss ist und eher gern den Ideen der größeren Behörden (z.B. NIST) und Hersteller (z.B. MS) folgt, ohne sie wirklich auf den Prüfstand zu stellen, hat sich ja seinerzeit hübsch beim Thema Passwortwechsel gezeigt. Dort hat man zunächst die Position des NIST (später auch MS) übernommen. Nachdem das NIST die von Anfang an unsinnige Empfehlung 2017 zurückgezogen hat, ist MS 2019 nachgezogen und das BSI dann doch mal in 2020.
FunFact: In den Konnektoren wurde der erzwungene Passwortwechsel ca. 2021 eingeführt

Aber Du legst den Finger auf die richtige Wunde, das BSI mischt auf jeden Fall mit:
Vorsichtig, wie man als tapferer Admin natürlich ist, kann man nicht von der Hand weisen, dass Einschätzungen des BSI einen Einfluss auf die Interpretation haben werden, denn Richter und Gutachter sind auch nur Menschen und ein Gutachten braucht ja fachliche Bezüge. Zumal die Leute beim BSI ja kluge Menschen sind und sich intensiv mit der Materie beschäftigen (oder doch mehr in Meetings sitzen und anderswo abschreiben?). Interpretationen des BSI werden deshalb in der Bewertung fraglos berücksichtigt werden, dies ändert aber nichts daran, dass in jedem Einzelfall der Stand der Technik konkret festzustellen ist (wenn man dessen Verletzung beurteilen will).

Mir ist Dein Punkt jetzt klarer geworden, denke ich.

Exkurs:
Der obige Link (kannte ich noch nicht) zur Infoschrift des BSI sagt ja nun einiges aus. Oder nichts:
23 Seiten weitgehend Blabla zu allgemeiner Informationssicherheit und ihrer Bedeutung. Von (praktischen) Laien für Laien könnte man boshaft sagen.

Oder wie will man solche tiefschürfenden Hinweise (das ist dort IMO die einzige inhaltliche Aussage zur Gerätesicherheit) betrachen:

"Verwenden Sie nur Geräte, Betriebssysteme und Programme, die noch vom Hersteller mit Sicherheitsupdates versorgt werden."

Oha!

Auch dieser Hinweis ist geradezu sensationell. Vor allem in der Ergebnislosigkeit:

"Aus Sicht der IT-Sicherheit ist es sicherer, wenn Aktualisierungen nur kontrolliert und getestet eingespielt werden. Um dies zeitnah zur Bereitstellung durch die Hersteller sicherzustellen, ist allerdings ein erheblicher organisatorischer Aufwand notwendig. Diese Maßnahme bringt nur einen Zuwachs an Sicherheit, wenn sie immer zeitnah umgesetzt wird."

Na dann mal ran Admin: Immer schön jeden Abend sämtliche Software auf sämtlichen Rechnern manuell auf Updates prüfen und einspielen! Vorher Testen nicht vergessen
Exkurs Ende

Fakt ist auch, dass die natürlich praktisch von der Materie ahnungslosen (Neuland-)Referenten des § 390 SGB V beim Gesetzentwurf offenbar die vom BSI verwendeten Termini übernommen haben, wenn sie ihnen griffig vorkamen. Man kann bei Betrachtung des Paragrafen fast sagen, der Begriff "Stand der Technik" ist zum Modewort geworden. Am Ende aber dreht sich alles im Kreis und niemand definiert den Terminus wirklich. Vielleicht, weil es bei der Vielfalt der technischen Aspekte der IT-Sicherheit in Bezug auf die gleichermaßen vielfältigen individuellen Nutzungen gar nicht geht?

Ein Sicherheitsgurt ist ein greifbarer Stand der Technik. Der wird eingebaut und (vielleicht) alle zwei Jahre überprüft. Ein HTTPS-Sicherheitsproxy beschädigt eine ursprünglich bestehende Sicherheit zunächst einmal und muss 24/7 überwacht werden, um als wirksame Sicherung zu nutzen. Genau genommen macht man etwas generell sicheres zum Zwecke der individuellen Sicherheit unsicher, erreicht diese Sicherheit aber letztlich nur durch konsequente Überwachung - und schafft zugleich einen Angriffsvektor, der sämtlichen (ursprünglich sicheren) Datenverkehr gefährdet. Und zugleich ein bürokratisches Monster, denn die "Überwachung" muss natürlich "rechtskonform" sein.
Das, also diese Feststellungen sind Stand der Technik. Jeder mache sich seinen Reim drauf.

Die DSGVO ist am Ende viel differenzierter. Für deren Anforderungen ist nicht nur der "Stand der Technik" maßgeblich, vielmehr gilt es, eine Abwägung aus vielen Parametern vorzunehmen und alle sind nur "zu berücksichtigen" (im Gegensatz zu "einzusetzen" oder "umzusetzen":

• Stand der Technik
• Implementierungskosten
• Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung
• unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen

Daraus abzuleiten sind geeignete technische und organisatorische Maßnahmen (die berühmten TOM), um ein

• dem Risiko angemessenes Schutzniveau (also noch eine Abwägung)

zu erreichen. Insgesamt ist das ein recht weites Ermessen und mehr ein Appell, sich über diese Punkte grundlegend Gedanken zu machen und verantwortungsbewusst umzusetzen. Ein Verlangen dahingehend, die Grundschutzanforderungen des BSI umzusetzen ist das nicht. Diese erwartet i.Ü. auch das BSI nicht, denn es verwendet ja für die Anforderungen in 3.2 den Terminus "sollten" (heißt in der formalistischen Denke des BSI: Abweichung ist möglich, wenn sachlich begründet).

Insgesamt muss also auf Grundlage der DSGVO eine - realistische - Abwägung nach den o.B. Kriterien vorgenommen werden. Über Sinn und Gefahren des Aufbrechens von E2E-Verschlüsselung kann man weidlich streiten. Dass das BSI sie (derzeit) zugrunde legt, ist mindestens ebenso fragwürdig, wie es das Passwortthema war.

Wenn Du meinst, alle Punkte von Baustein 3.2 umsetzen zu s(w)ollen, insbesondere die ab 3.19, reicht ein besserer Router natürlich nicht mehr. Dann sind aber auch ein ständiges und umfassendes Monitoring, Log-Überwachung und Auswertung sowie regelmäßige Penetration-Tests notwendig. Ich sehe nicht, das klassische Arztpraxen das umsetzen würden. Zumal hier gilt: Halbe Sachen sind oft gefährlicher als keine Sachen. Stichwort Angriffsvektor.

Am Ende hat Dein Kunde dann alles hübsch umgesetzt und zwei Jahre später kommt das BSI mit (z.B.)

Noch kurz ein Blick auf die Realitäten:

• Will sich ein Arzt oder eine Gruppe von Ärzten damit beschäftigen?
• Wieviel Zeit steht dafür zur Verfügung?
• Wieviel Geld?
• Auf wessen Einschätzung wird er hören?
• Wer wird für die Einrichtung/Überwachung/Auswertung zuständig sein?
• Wer also steckt im Falle eines Vorfalles juristisch in der Sch...?

Nichts wird Dich davor bewahren, außer gute, überlegte und vertrauensvolle Arbeit (und vielleicht nicht mal die). Schon gar keine Versicherung.

Am Ende bleibt noch zu berücksichtigen, dass die Abwehr von Angriffen von außen nur ein kleiner Teil eines Schutzkonzepts ist. Bekanntermaßen entsteht die überwiegende Zahl von Schäden durch intern verursachte Vorfälle. Hierfür sind dann adäquate Schutzkonzepte zu erstellen. Dafür hat das BSI sicher auch was im Rezeptebuch. Oder Ratiopharm. Viel Spaß

Was braucht es da für Informationen? Wie man einen günstigen und guten Server baut? Dann gerne per PN oder in einem Extra-Fred, dieser ist ja schon etwas ausgeleiert (aber interessant und sehr nett).

In aller Kürze:
Entscheidend ist hier die Fragestellung: Wozu dient Serverhardware und was sind die Vor- und Nachteile ihres Einsatzes in KU-Umgebungen.
Meine Theorie: Zu oft dem Ego des Admins. Oder seiner vermeintlichen Absicherung. Zu selten der Sache.
Einfach mal Checkliste machen, abhaken, auswerten und (vielleicht) viel Geld und Nerven sparen. Geld, das für die Betreuung bleibt, womit wir dem BSI ja entgegen kommen.

Viele Grüße, commodity

Stand der Technik:
TeleTrusT - Stand der Technik - Definition