Grundeinstellung "Datenbank Kommunikation verschlüsseln" ja oder nein

[Saugguat]

Liebe Runde,

für o.g. Grundeinstellung ist der Auslieferungszustand "nein". Wieviel Sinn macht denn die Verschlüsselung für die Sicherheit, gibt es Einfluss auf die Stabilität?

Gruß und Dank, Martin

[FortiSecond]

Das wird vermutlich niemand verbindlich beurteilen wollen.
Sicherlich ist es besser, die Pakete zwischen Datenbank und Client zu verschlüsseln, damit nicht jemand einfach den Datenverkehr im Netzwerk ausliest und die Daten im Klartext vorliegen.
Aufgrund der vielen kleinen Paketchen entsteht ein gewisser Overhead. Der kann die Performance beeinträchtigen. Weniger stabil habe ich TM dadurch aber nicht erlebt. Geht oder geht nicht, aber dazwischen... okay... aber das hat nix mit der o.g. Einstellung zu tun.

Ich schalte die Verschlüsselung im Regelfall ein - außer für Nutzer auf dem Terminalserver, auf dem auch der Datenabnkserver liegt. Innerhalb des Geräts zu verschlüsseln, halte ich für albern, weil die DB ohnehin geöffnet ist.

[Saugguat]

Hallo Forti, danke für die Antwort. Spannend finde ich, dass die Grundeinstellung „aus“ ist. Probiere dann mal beides aus. Wir hatten mit Win 10 viele Abstürze, v.a. beim schnellen Schreiben und beim Zeilenumbruch, dort war die Datenbankkommunikation als verschlüsselt eingestellt - mit den neuen Win 11 Rechnern (und aktuell ohne Verschlüsselung) ist es dtl. flüssiger.

[lcer]

Hallo,


ist eigentlich irgendwo dokumentiert, was und wie da verschlüsselt wird?

Vielleicht der Zugriff auf den FastObjectsServer? Wie mit SSL/TLS? Welche Version?

Und wenn es Sinn machen soll, müsste man ja am Server einstellen, dass nur verschlüsselte Clientverbindungen akzeptiert werden.

Und sie ist das mit der Authentifizierung? Kann da jeder Client mit jedem Server - oder wird irgendwo geprüft, wer sich da am FastObjectsServer anmeldet?

Fragen über Fragen. Ich lasse das deaktiviert.

Ich glaube übrigens, dass es gravierendere Schwachstellen in Turbomed gibt als unverschlüsselte Verbindungen zum FastObjectsServer. Wie soll da das Angriffsszenaio aussehen? Mal kurz gesponnen: Um den unverschlüsselten Datenverkehr zwischen Client und Turbomedserver abzufangen, könnte man den Switch so programmieren, dass aller Datenverkehr vom Clientport und/oder vom Serverport auf je einen zusätzlichen Switchport gespiegelt wird. An die hängt man dann jeweils einen kleinen PC und schneidet die Daten einfach mit. Also wenn jemand in seiner Praxis ständig Besuch von „Elektrikern“ und „Technikern“ hat, die irgendetwas an den Switch dranklemmen wollen und dazu nach dem Passwort fragen…

Alternatives Szenario: Jemand betreibt seinen Turbomedserver offen im Internet. Die Clients verbinden sich direkt - ohne VPN - mit dem Server. Dann könnte man sich in den Server hacken. Das wird aber (hoffentlich) keiner machen, zumal in diesem Szenario Turbomed ständig abstürzt, da die Latenzen der Verbindung zu lang sind.

Alles in allem - die Verschlüsselung ist vermutlich Schlangenöl.


Grüße


lcer

[pmortara]

Der Schalter aktiviert die Verschlüsselung seitens des FastObjectsServer/Client, d.h. eine Dokumentation dazu findet man vermutlich nur beim Hersteller der Datenbank. Über Sinn- und Unsinn dieser Funktion im Umfeld einer Turbomed-Arztpraxis kann man wahrscheinlich Doktorarbeiten schreiben. Sehe das wie lcer: macht keinen Sinn für TurboMed und da wo es Sinn machen würde (Kommunikation über Intenet), macht Turbomed keinen Sinn.

Eine entsprechende Funktion Serverseitig nur verschlüsselte Verbindungen zu akzeptieren gibt es mit Sicherheit auch, wenn man die Dokus hätte könnte man die bestimmt auch aktivieren.

[FortiSecond]

Ich glaube übrigens, dass es gravierendere Schwachstellen in Turbomed gibt als unverschlüsselte Verbindungen zum FastObjectsServer. Wie soll da das Angriffsszenaio aussehen? Mal kurz gesponnen: Um den unverschlüsselten Datenverkehr zwischen Client und Turbomedserver abzufangen, könnte man den Switch so programmieren, dass aller Datenverkehr vom Clientport und/oder vom Serverport auf je einen zusätzlichen Switchport gespiegelt wird. An die hängt man dann jeweils einen kleinen PC und schneidet die Daten einfach mit. Also wenn jemand in seiner Praxis ständig Besuch von „Elektrikern“ und „Technikern“ hat, die irgendetwas an den Switch dranklemmen wollen und dazu nach dem Passwort fragen…

Mit Software wie Wireshark kann man schon viel mitschneiden.
Aber ich stimme zu: Warum sollte man sowas machen, wenn die Datenbank viel leichter zu erreichen ist?

[lcer]

Hallo,

Mit Software wie Wireshark kann man schon viel mitschneiden.

ja, aber nur wenn Wireshark auf einem Rechner läuft, an den die Daten auch gesendet/Empfangen werden. Switche schicken Daten für z.B. PC-A nur an den Port, an dem PC-A auch dranhängt (deshalb heißen die auch "Switch", und nicht wie früher "Hub"). Daher müsste Wireshark entweder auf dem Client-PC, dem Turbomed-Server oder eben an einem gespiegelten Switchport laufen, damit die Daten sichtbar sind. Also: PC-B sieht nichts davon, auch wenn er im selben Netzwerk hängt, auch nicht der Laptop im Wartezimmer.

Anders wäre es nur bei Verbindungen über das Internet, kommen dann noch alle Router dazu, über die die Verbindung hergestellt wird.

Damit wollen wir aber den Exkurs in das Kapitel "Switching und Routing" schließen.

Grüße

lcer

Nachtrag: Wer auf Client oder Turbomed-Server Wireshark starten kann, kann auch die Turbomed-Datenbank kopieren.

[FortiSecond]

Nachtrag: Wer auf Client oder Turbomed-Server Wireshark starten kann, kann auch die Turbomed-Datenbank kopieren.

Eben
Full ack.