3-Tier-Modell

[af0815]

Ich habe mit zentralen ITs und "privaten" Servern in globalen Firmen Erfahrung machen dürfen, auch mit Sicherheitskonzepten, daher meine Antworten zu dem Thema.

Mit den Anforderungen lt. TISAX wird man sich als Serverbetreiber, Netzwerknutzer und App-Programmierer immer mehr beschäftigen dürfen. Betreibst du einen Server, dann darfst du dich mit den Fragen und Antworten im Audit sicher beschäftigen. Dann kannst du nichts auf die IT weiterdelegieren (abschieben).

[wodim]

Ich habe mit zentralen ITs und "privaten" Servern in globalen Firmen Erfahrung machen dürfen, auch mit Sicherheitskonzepten, daher meine Antworten zu dem Thema.

Mit den Anforderungen lt. TISAX wird man sich als Serverbetreiber, Netzwerknutzer und App-Programmierer immer mehr beschäftigen dürfen. Betreibst du einen Server, dann darfst du dich mit den Fragen und Antworten im Audit sicher beschäftigen.

Mit einer dieser Institutionen?
https://portal.enx.com/de-DE/TISAX/xap/?country=DE
Sagen wir mal so: Mit welcher hast du die wenigsten schlechten Erfahrungen?

Weißt du, ich gehe ja davon aus, dass so ein Netzwerk nach außen hin absolut "wasserdicht" ist und innerhalb des Hauses solche Daten, die "jeder" Mitarbeiter sehen und bearbeiten kann, der mit dem Patienten zu tun hat, nicht unbedingt der Sicherheitsstufe "vor dem Lesen vernichten" unterliegen.

[af0815]

Weißt du, ich gehe ja davon aus, dass so ein Netzwerk nach außen hin absolut "wasserdicht" ist und innerhalb des Hauses solche Daten, die "jeder" Mitarbeiter sehen und bearbeiten kann, der mit dem Patienten zu tun hat, nicht unbedingt der Sicherheitsstufe "vor dem Lesen vernichten" unterliegen.

Wenn das Netz gut designed ist, so hast du es in Abschnitte unterteilt (Bsp. Haus oder Stockwerk oder Abteilungs oder Funktionsebene). Weil der administrative Bereich braucht normalerweise nichts aus den operativen Bereichen. Damit kann man/muss man das ganze gliedern. Besonders die Bereiche die nach Außen kommunizieren können sind einmal grundlegend Suspekt. Die sind gerne Einfallstor für Angriffe - wir wir leider schon öfters aus den Medien erfahren durften. Somit ist es notwendig das ganze wo möglichst kleinteilig abzuschotten und die Schnittstellen so streng wie möglich zu definieren. Das heißt auch, das es Querverbindungen zwischen den Netzen (Abschnitten) am besten gar nicht gibt. Hier spreche ich aber nur mal von Angriffserschwernis (mehr kann es nicht sein) bzw. schaffen von definierten Schnittstellen die bei einem Angriffszenario notfalls physisch aufgetrennt werden können um eine definierte Grundversorgung aufrecht erhalten zu können.

Wobei ja bekannt ist, das sehr viele Geräte einmal als unsicher zu betrachten sind. Gerade bei den ?notwendigen? Wartungshintertüren haben Hersteller riesige Scheunentore offen. Das muss man beim Design des Netzwerk mitberücksichtigen. Aus diesem Grund ist eine 'einfache UDP Kommunikation' einmal kritisch zu hinterfragen und wenn nötig auch sehr genau zu dokumentieren - warum man kein gelinderes Mittel, wie polling am DB-Server verwendet hat.

----

Du willst also jetzt einen Port verwenden um den Clients mitzuteilen, das sich was an der DB geändert hat. Das heistt du verwendest den Port am Server, das sich ein Client verbinden kann und dem Server mitzuteilen, das er bei Änderungen verständigt werden soll.

Der Client meldet sich über den Socket beim Server, sagt, das er verständigt werden will. Der Server bekommt die Information welche IP der Client hat und auf welchen Port der Client die Verständigung erwartet. Dann schliesst der Client den Socket, damit andere Clients sich auch anmelden können. Soweit so gut, der Server hat jetzt eine Liste der Clients.
Eine Änderung findet in der DB statt, der Server muss jetzt Sockets für alle Clients öffnen und die verständigen. Warum viele Sockets, was ist wenn ein Client nicht erreichbar ist, der Socket ist dann mehr oder minder in einem Wartezustand bis der Client sich meldet. Inzwischen kann er am gleichen Socket keine Verbindung aufbauen. Die Timeouts für Sockets sind da nicht zu verachten. Deswegen viele Sockets. Was machst du jetzt mit den Clients die sich nicht melden. Kann ja sein, das das Netzwerk dazwischen ein Problem hat - WLAN weg/geändert, Netzwerkkabel kurz mal abgesteckt, weil das Terminal in ein anderes Zimmer verbracht wird, neu IP-Adresse, Laptopdeckel zu, PC geht in Stromsparzustand,... - also muss du den Client aus deiner Liste entfernen. Soweit so gut. Was sit, wenn der Client davon nicht wirklich was mitbekommt. Dort arbeitet wer, der vom Hintergrund keine Ahnung hat und mit deinem Programm arbeitet und das Programm davon ausgeht, das es keine Benachrichtigung bekommen hat - was ist dann mit den Daten ?

Wie gehst du mit solchen Scenarien um ? Das sind für mich normale Scenarien, keine Besonderheiten.

Das hat mich dazu bewogen, eher zu pollen und nicht Botschaften vom Server zu bekommen.

Mein Lieblingsszenario ist übgrindes der hippe Manager (oder was du hier einsetzen willst) der einen Datensatz beginnt zu editieren und durch den Scheduler plötzlich den Hinweis bekommt, das sein Meeting in 5 Minuten beginnt. Der klappt den Deckel zu und geht auf das Meeting. -> Andere IP-Range weil Besprechungszimmer, Programm im Hintergrund oder mitten in der Bearbeitung abgeschossen, weil bei der Präsentation stört das ja nur. Geiles Sccenario - aus der Praxis.

[wodim]

Ok, ich hab's mit lNet aufgegeben.

Das war ein Fehler. Nochmal das Ganze:

tcpudp.zip

(8.36 KiB) 35-mal heruntergeladen

Und da steht unter ./examples/console/ltcp genau das, was ich suchte! Zwar erst mal nur auf Konsolenebene, aber wenigstens funktionieren sowohl Server, Client als auch der Verbindungsaufbau auf Anhieb!

Auch mit Client und Server auf verschiedenen Maschinen (wie's wohl die Regel sein dürfte). Auch das Senden und Empfangen von Strings (und mehr will ich ja letztlich nicht). Und der Server ist erst mal so programmiert, dass er empfangene Messages einfach zurücksendet. Aber an alle verbundenen Clients ...

Wunder gibt es immer wieder! (Ok, man muss unter "Compilereinstellungen" noch das Häkchen bei "Win32-GUI-Anwendung" 'rausnehmen. Aber langsam komme ich schon den Tücken der IDE auf die Schliche, bin schließlich nicht der erste, der über sowas stolpert.) Also wer sagte da, lNet wäre zu kompliziert?

Also ich kann's nur jedem empfehlen. Anfängergerecht und ausbaufähig. Meine Begeisterung nimmt kein Ende! Und das ist wohl die wichtigste Motivation

[wodim]

Weißt du, ich gehe ja davon aus, dass so ein Netzwerk nach außen hin absolut "wasserdicht" ist und innerhalb des Hauses solche Daten, die "jeder" Mitarbeiter sehen und bearbeiten kann, der mit dem Patienten zu tun hat, nicht unbedingt der Sicherheitsstufe "vor dem Lesen vernichten" unterliegen.

Wenn das Netz gut designed ist, so hast du es in Abschnitte unterteilt (Bsp. Haus oder Stockwerk oder Abteilungs oder Funktionsebene). Weil der administrative Bereich braucht normalerweise nichts aus den operativen Bereichen. Damit kann man/muss man das ganze gliedern. Besonders die Bereiche die nach Außen kommunizieren können sind einmal grundlegend Suspekt. Die sind gerne Einfallstor für Angriffe - wir wir leider schon öfters aus den Medien erfahren durften.

Ja, was ich da so mitgekriegt habe: Da hat's doch mal die Kommunikation einer ganzen Klinik lahmgelegt, mit dem Klassiker: Ein E-Mail-Anhang, als harmlose Datei getarnt (*.pdf oder wasweißich), der aber in Wirklichkeit ein ausführbares Programm war. Und welches Rindvieh macht da Doppelklick drauf? Nicht etwa eine ahnungslose Stationsschwester, sondern ein "ITler" selber. Der sollte sich seine Studiengebühren wiedergeben lassen.

Somit ist es notwendig das ganze wo möglichst kleinteilig abzuschotten und die Schnittstellen so streng wie möglich zu definieren. Das heißt auch, das es Querverbindungen zwischen den Netzen (Abschnitten) am besten gar nicht gibt.

Ja klar, und deshalb jeder Patient in jeder Abteilung zum ...zigsten Mal nach seinen Daten gefragt wird, die schon bei der Anmeldung erfasst wurden. Spätestens - es gibt auch die Möglichkeit, sich vorher online anzumelden und einen Termin zu vereinbaren (über "doctolib" oder wie das heißt). Da platzte mir also so beim 5. oder 6. Mal der Kragen. Und als ich den hochbezahlten (und mehr als voll beschäftigten) Thoraxchirurgen sah, der auch mich operiert hatte, wie er für einen anderen Patienten auf meinem Zimmer so einen Anmeldebogen ausfüllte, tat mir was weh.

Hier spreche ich aber nur mal von Angriffserschwernis (mehr kann es nicht sein) bzw. schaffen von definierten Schnittstellen die bei einem Angriffszenario notfalls physisch aufgetrennt werden können um eine definierte Grundversorgung aufrecht erhalten zu können.

Ich höre immer "Angriffszenario". Mal ganz im Ernst. Welchen "Hacker" sollten wohl meine Wehwehchen und die diesbezügl. Kommunikation des medizinischen Personals interessieren? Und mit den Röntgenaufnahmen geht's doch auch: Die waren immer schneller auf der Station als ich vom Röntgen zurück. Mit den CT-Aufnahmen von ganz wondersher auch (ich lag in Gauting, die Aufnahmen wurden in Großhadern gemacht). Da kriegte ich allerdings ein Papier in die Hand, mit einem QR-Code drauf. Den mussten sie in Gauting nur einscannen - und voilà.

Wobei ja bekannt ist, das sehr viele Geräte einmal als unsicher zu betrachten sind. Gerade bei den ?notwendigen? Wartungshintertüren haben Hersteller riesige Scheunentore offen. Das muss man beim Design des Netzwerk mitberücksichtigen. Aus diesem Grund ist eine 'einfache UDP Kommunikation' einmal kritisch zu hinterfragen und wenn nötig auch sehr genau zu dokumentieren - warum man kein gelinderes Mittel, wie polling am DB-Server verwendet hat.

Naja, TCP möchte schon sein. Und Doku ist ja wohl auch kein Thema.

Du willst also jetzt einen Port verwenden um den Clients mitzuteilen, das sich was an der DB geändert hat. Das heistt du verwendest den Port am Server, das sich ein Client verbinden kann und dem Server mitzuteilen, das er bei Änderungen verständigt werden soll.

Der Client meldet sich über den Socket beim Server, sagt, das er verständigt werden will. Der Server bekommt die Information welche IP der Client hat und auf welchen Port der Client die Verständigung erwartet. Dann schliesst der Client den Socket, damit andere Clients sich auch anmelden können. Soweit so gut, der Server hat jetzt eine Liste der Clients.
Eine Änderung findet in der DB statt, der Server muss jetzt Sockets für alle Clients öffnen und die verständigen. Warum viele Sockets, was ist wenn ein Client nicht erreichbar ist, der Socket ist dann mehr oder minder in einem Wartezustand bis der Client sich meldet. Inzwischen kann er am gleichen Socket keine Verbindung aufbauen. Die Timeouts für Sockets sind da nicht zu verachten. Deswegen viele Sockets. Was machst du jetzt mit den Clients die sich nicht melden. Kann ja sein, das das Netzwerk dazwischen ein Problem hat - WLAN weg/geändert, Netzwerkkabel kurz mal abgesteckt, weil das Terminal in ein anderes Zimmer verbracht wird, neu IP-Adresse, Laptopdeckel zu, PC geht in Stromsparzustand,... - also muss du den Client aus deiner Liste entfernen. Soweit so gut. Was sit, wenn der Client davon nicht wirklich was mitbekommt. Dort arbeitet wer, der vom Hintergrund keine Ahnung hat und mit deinem Programm arbeitet und das Programm davon ausgeht, das es keine Benachrichtigung bekommen hat - was ist dann mit den Daten ?

Wie gehst du mit solchen Scenarien um ? Das sind für mich normale Scenarien, keine Besonderheiten.

Das hat mich dazu bewogen, eher zu pollen und nicht Botschaften vom Server zu bekommen.

Mein Lieblingsszenario ist übgrindes der hippe Manager (oder was du hier einsetzen willst) der einen Datensatz beginnt zu editieren und durch den Scheduler plötzlich den Hinweis bekommt, das sein Meeting in 5 Minuten beginnt. Der klappt den Deckel zu und geht auf das Meeting. -> Andere IP-Range weil Besprechungszimmer, Programm im Hintergrund oder mitten in der Bearbeitung abgeschossen, weil bei der Präsentation stört das ja nur. Geiles Sccenario - aus der Praxis.

Ja und - wenn der Server einen Client nicht erreicht, geht postwendend eine Message an den Admin: "Schau' mal. was da los ist, und gib' dem Kollegen Bescheid, dass er seine Daten mal neu abfragen möchte". Oder / und der Mitarbeiter wird selber benachrichtigt, meinetwegen per E-Mail. Wo liegt das Problem?

[af0815]

Ransomware Beispiel https://www.mwv-berlin.de/meldung/!/id/484

Deine Kommunikation geht, Port kannst du dir mal aussuchen, wie gehts weiter

[theo]

https://github.com/ultibohub/Examples/t ... aemon/RPi2

Naja, das ist wohl für Einsteiger weniger geeignet. Das ist doch nur ein Socket, wenn ich das richtig sehe. Ich brauche ein einfaches ausbaufähiges Beispiel für Server und Client. Damit sind die Profis hier wohl etwas unterfordert, scheint mir.

Nö, das hier https://github.com/ultibohub/Examples/b ... 2/echo.pas macht genau was du wolltest.
Das ist der Code für einen einfachen Mutlithreaded Echo Server.

Ein Test Client dafür ist ja kein Ding:

Code: Alles auswählen

procedure TForm1.Button3Click(Sender: TObject);
var
  sock: TTCPBlockSocket;
  s: string;
begin
  sock:= ttcpblocksocket.Create;
  try
    sock.Connect('127.0.0.1','8008');
    sock.SendString('yourdata' + CRLF);
    s := sock.recvstring(15000);
    //...
  finally
    sock.Free;
  end;
end;

[wodim]

https://github.com/ultibohub/Examples/t ... aemon/RPi2

Naja, das ist wohl für Einsteiger weniger geeignet. Das ist doch nur ein Socket, wenn ich das richtig sehe. Ich brauche ein einfaches ausbaufähiges Beispiel für Server und Client. Damit sind die Profis hier wohl etwas unterfordert, scheint mir.

Nö, das hier https://github.com/ultibohub/Examples/b ... 2/echo.pas macht genau was du wolltest.

Noch lange nicht. Vergleich' das nur mal damit:

tcpudp.zip

(8.36 KiB) 63-mal heruntergeladen

Das ist der Code für einen einfachen Mutlithreaded Echo Server.

Für den praktischen Betrieb viel zu einfach. Der Server soll ja nicht einfach den Wald spielen, aus dem es herausschallt, wie man hineinruft. Und auch unter den gerade hier angesprochenen Sicherheitsaspekten ist das Ding für die Tonne.

Ransomware Beispiel https://www.mwv-berlin.de/meldung/!/id/484

Deine Kommunikation geht, Port kannst du dir mal aussuchen, wie gehts weiter

Komisch - kein Wort darüber, wie's dem Hacker gelungen ist, das Programm da 'reinzuschmuggeln. Ich weiß es nicht genau, aber ich glaube, das war eben die Klinik, wo das mit einem Mailanhang passiert ist. Und mach' mir mal vor, wie mein Prinzip (Messages an die Clients statt Polling) das begünstigen würde, also der Server zur Spamschleuder mutieren. Da müsste ich mich schon sehr dumm anstellen.

Nochmal: Der Server kriegt (als "Objektschicht-Manager") Strings, die er gem. getroffener Konventionen als Funktionsaufrufe interpretiert, woraus er also z.B. macht "LiesAusDatenbankUndErstelleObjekt (<Daten von Max Mustermann>, <Klasse "Patient">)". Und wenn er mit einem String nichts dergleichen anfangen kann, macht er gar nichts, liefert nur eine Fehlermeldung zurück. Ach, noch 'ne Idee - dann möchten auch gleich in der IT die Alarmglocken schrillen: "Achtung, Hackerangriff von IP nnn.nnn.n.nnn!"

[theo]

Für den praktischen Betrieb viel zu einfach. Der Server soll ja nicht einfach den Wald spielen, aus dem es herausschallt, wie man hineinruft. Und auch unter den gerade hier angesprochenen Sicherheitsaspekten ist das Ding für die Tonne.

Ich dachte du wolltest ein minimales Beispiel, da du "Einsteiger" bist?
Na gut, dann lasse ich dich mal in Ruhe.
Viel Erfolg!

[wodim]

Für den praktischen Betrieb viel zu einfach. Der Server soll ja nicht einfach den Wald spielen, aus dem es herausschallt, wie man hineinruft. Und auch unter den gerade hier angesprochenen Sicherheitsaspekten ist das Ding für die Tonne.

Ich dachte du wolltest ein minimales Beispiel, da du "Einsteiger" bist?

Ja doch, aber eben eins, das ohne große Klimmzüge erweiterbar ist. Und absicherbar auch. Ach, noch 'ne Idee: Verschlüsseln wir die Strings doch auch noch ein bisschen, dann kann hoffentlich nichts mehr schiefgehen. Ok, die TISAX-Gurus werden schon noch was finden.

Viel Erfolg!

Danke. Aber die nächsten "Einsteiger"-Fragen werden nicht lange auf sich warten lassen. Mein gewähltes Beispielprojekt ist für meinen Level nun gerade noch nicht zu komplex, so dass ich auch verstehe, was ich mache.

[af0815]

Auch ich wünsche dir viel Erfolg bei deiner Software.

[wodim]

Auch ich wünsche dir viel Erfolg bei deiner Software.

Danke. Aber sag' doch nochmal was zu meiner Lösung des DAU-Problems:

Wenn der Server einen Client nicht erreicht, geht postwendend eine Message an den Admin: "Schau' mal. was da los ist, und gib' dem Kollegen Bescheid, dass er seine Daten mal neu abfragen möchte". Oder / und der Mitarbeiter wird selber benachrichtigt, meinetwegen per E-Mail.

Und zu meiner Absicherung gegen (zwar unwahrscheinliche, aber immerhin mögliche) Angriffe:

Der Server kriegt (als "Objektschicht-Manager") Strings, die er gem. getroffener Konventionen als Funktionsaufrufe interpretiert, woraus er also z.B. macht "LiesAusDatenbankUndErstelleObjekt (<Daten von Max Mustermann>, <Klasse "Patient">)". Und wenn er mit einem String nichts dergleichen anfangen kann, macht er gar nichts, liefert nur eine Fehlermeldung zurück. Ach, noch 'ne Idee - dann möchten auch gleich in der IT die Alarmglocken schrillen: "Achtung, Hackerangriff von IP nnn.nnn.n.nnn!"

Ach, noch 'ne Idee: Verschlüsseln wir die Strings doch auch noch ein bisschen ...

... mit einem einfachen Algorithmus, der trotzdem nicht beim ersten Versuch zu knacken ist. Und mehr als einen Versuch kriegt keiner.

Also die Meinung eines alten Hasen zu den Ideen eines Neulings?

[wodim]

tcpudp.zip

(8.36 KiB) 54-mal heruntergeladen

Und da steht unter ./examples/console/ltcp genau das, was ich suchte!
[...]
Also ich kann's nur jedem empfehlen. Anfängergerecht und ausbaufähig. Meine Begeisterung nimmt kein Ende! Und das ist wohl die wichtigste Motivation.

Und an welchen Schräubchen ich auch drehe, und was ich auch einbaue - es funktioniert einfach. Und wenn nicht, ist der Fehler ratz-fatz gefunden. Kann's wirklich allen empfehlen, die eigene Client-Server-Lösungen bauen wollen. Ohne Polling, mit Callbacks, wie sich das gehört.

Eine Unklarheit gibt's da noch im Code des Servers (hab' mir zwecks besserem Verständnis die Kommentare mal übersetzt, alles ein bisschen anders angeordnet, auch die Variablen ein bisschen aussagekräftiger benannt) ...

Code: Alles auswählen

program lserver;

{$mode objfpc}{$H+}

uses
  Classes, Crt, SysUtils, lNet, lnetbase;    

type

{ tlTCPServer }

  tlTCPServer = class
      
   ....
   
   public
    constructor Create;
    procedure Run; // Hauptschleife mit CallAction
    destructor Destroy; override;
  end; 

.....

constructor tlTCPServer.Create;
begin
  fCon := tlTCP.Create(nil); // Neue TCP-Verbindung aufbauen
  fCon.OnError := @OnEr;     // Alle Callbacks zuweisen
  fCon.OnReceive := @OnRe;
  fCon.OnDisconnect := @OnDs;
  fCon.OnAccept := @OnAc;
  fCon.Timeout := 100; // Reagiert ausreichend, beansprucht aber nicht die CPU
  fCon.ReuseAddress := True;
end;

.....

destructor tlTCPServer.Destroy;
begin
  fCon.Free; // Die TCP-Verbindung freigeben
  inherited Destroy;    // ?????
end;
{ /tlTCPServer }

{ Hauptprogramm }

var
  Server: tlTCPServer;
begin
  Server := tlTCPServer.Create;
  Server.Run;
  Server.Free;  // ?????  Nicht Destroy?
end.   

Also ganz unten, wo meine Fragezeichen stehen: Müsste zum Schluss nicht der Destruktor aufgerufen werden? Und was heißt da drin "inherited Destroy"? Vererbt woher?

[wodim]

tcpudp.zip

(8.36 KiB) 54-mal heruntergeladen

Und da steht unter ./examples/console/ltcp genau das, was ich suchte!

Also ich kann's nur jedem empfehlen. Anfängergerecht und ausbaufähig. Meine Begeisterung nimmt kein Ende! Und das ist wohl die wichtigste Motivation.

Und an welchen Schräubchen ich auch drehe, und was ich auch einbaue - es funktioniert einfach. Und wenn nicht, ist der Fehler ratz-fatz gefunden. Kann's wirklich allen empfehlen, die eigene Client-Server-Lösungen bauen wollen. Ohne Polling, mit Callbacks,

Und welcher Callback steht im Code sowohl des Servers als auch des Clients an allererster Stelle? Genau: Behandlung von Netzwerkfehlern. Ok, erst mal nur "Writeln(msg);" (beim Client außerdem Beendigung der Anwendung). Mein Problem also, die richtigen Reaktionen zu coden.

Mit den Anforderungen lt. TISAX wird man sich als Serverbetreiber, Netzwerknutzer und App-Programmierer immer mehr beschäftigen dürfen.

So weit nachvollziehbar. Freue mich schon drauf.

Betreibst du einen Server, dann darfst du dich mit den Fragen und Antworten im Audit sicher beschäftigen. Dann kannst du nichts auf die IT weiterdelegieren (abschieben).

Wer redet denn von "Abschieben"? Wenn das Ding einmal läuft, getestet und abgenommen ist - klapperst du da täglich deine Kunden ab, ob's auch wirklich keine Probleme mehr gibt, oder verlässt du dich nicht eher auf Feedback, falls es wider Erwarten doch mal irgendwo hakt?