interne DB-Server Ports ins Netz stellen

[UrsDerBär]

Hallo zusammen,

Habe hier bzw. bei einer Umgebung die ich betreue eine Anforderung die mir nicht ganz geheuer ist.
Und zwar soll ein interner Server-Port eines DB-Servers im Internet veröffentlicht werden.

Der Server
- muss der internen Domäne angehören
- muss auf Freigaben schreiben für Files
- Der DB-Server muss sowohl in die DB als auch in die Freigaben schreiben können

Die Writes werden z.B. durch Java-Scripts direkt geschrieben. Die Schnittstelle ist Java. Des weiteren via einer fremden Datenbankanwendung welche die Befehle von einem Silverlight-Plugin bekommt.

Kommunikation ist also so:
- Client macht was im Silverlight Plugin
- Der Fremde DB Server verarbeitet das ganze
- Der Fremde DB Server schickt Daten sowie Files an den eigenen DB-Server bzw. dessen Java-Webserver-Schnittstelle
- Der eigene DB Server verarbeitet den angekommene Kram

Das ganze ist für ne sehr kleine Firma. Irgendwie finde ich das totaler Schwachsinn, da keinerlei Überwachung und KnowHow am anderen Ende vorhanden ist. Java ist zudem nicht unbedingt für Sicherheit bekannt. Silverlight ebensowenig.

Ganz zu schweigen, dass mich ein komplett offener Port auf nem internen Server mit einer quasi Full-Write-Schnittstelle für Java ohne aufwändige Absicherung irgendwie extrem ungeheuer ist.

Was meint Ihr dazu? Alternativen gibts leider keine. Entweder Friss oder lass es. Nur noch manuelle Daten-Einpflegung ist eine Option. Also Silverlight-auswahl, Speichern, entpacken, Import.

Grüsse und Danke

[rprengel]

Was meint Ihr dazu? Alternativen gibts leider keine. Entweder Friss oder lass es. Nur noch manuelle Daten-Einpflegung ist eine Option. Also Silverlight-auswahl, Speichern, entpacken, Import.

Grüsse und Danke

Hallo,
in Kurzform:
Finger weg davon
in Langform:
eine schriftliche Bestätigung das du auf die Risiken hingewiesen hast und von jeder Verantortung frei gestellt bist.

Gruss

[omicronont]

Falls rprengel's Vorschlag ("Finger weg") aus welchen Gründen auch immer nicht zum Tragen kommen kann, folgende Vorschläge:

Kommunikation zwischen "Fremde DB Server" und "eigene DB Server" absichern - durch Firewall, die den von Dir genannten Port an genau eine IP freischaltet (die IP des "fremden Servers".

Oder, wahrscheinlich besser, den von Dir skizzierten "Offline-Weg" (Silverlight-Auswahl, Speichern, entpacken, Import") automatisieren. Z.B. automatisiertes Speichern aus Silverlight, per E-Mail weitergeleitet, automatisiert entpacken und importieren. Das könnte den offenen Port ersparen.

Klingt aber alles nach ganz viel manueller Arbeit, die man für genau einen Kunden macht ("sehr kleine Firma").

Gruß,

Knut

[rprengel]

Falls rprengel's Vorschlag ("Finger weg") aus welchen Gründen auch immer nicht zum Tragen kommen kann, folgende Vorschläge:

Kommunikation zwischen "Fremde DB Server" und "eigene DB Server" absichern - durch Firewall, die den von Dir genannten Port an genau eine IP freischaltet (die IP des "fremden Servers".

Knut

Ein VPN könnte auch helfen aber das Grundproblem bleibt. Von aussen sind Fremde auf dem System mit Innenkontakt unterwegs.

Gruss

[UrsDerBär]

Hallo Zusammen,

Vielen Dank für eure Einschätzung.

Durchsetzen kann ich alles, das ist nicht so das Problem. Das Problem ist, dass diese Anwendung sehr viel Arbeit erspart im täglichen Betrieb und dieser Krempel auch von einigen anderen Firmen genutzt wird.
Da muss ich mir dann eben anhören, dass es doch andere auch machen und es überall funktioniert.
Ein wenig zusätzliche Sicherheit, dass das tatsächlich fahrlässig ist, ist daher nicht verkehrt.

Denke halt, die haben das so gemacht, weil sie mit Silverlight bzw. dem Browser nie so richtig wissen, was an Sicherheitseinstellungen vorliegt. Da werden sie sich gedacht haben, bei direkter Kommunikation haben wir ne Stelle weniger die Probleme machen kann und es ist egal was der Kunde für Browser-Settings hat. HTML5 sei auch in Planung.
Grundgedanke eigentlich gar nicht so schlecht, kann man dem Browser und seinen Plugins wirklich alles verbieten.

Meines erachtens könnte man gleich ein eigenes Programm schreiben welches lokal installiert wird und via Internet auf deren Datenbank zugreift. Scheint mir deutlich sinnvoller zu sein. Aber das wird halt der aktuelle Wahn sein, dass alles irgendwie per Weboberfläche und Browser gemacht werden muss.

VPN wäre ne Sonderlösung. Werden Sie nicht machen.

Nun denn, vielleicht bekomme ich ja mal nen höheren Entwickler von denen an die Strippe welcher mir genau sagen kann, wie man das System abschotten kann, sollte ich mich dennoch eingehender damit beschäftigen müssen. Die die das installieren, wissen ned mal, was sie tun geschweige denn, wie der Kram aufgebaut ist.

Grüsse und Vielen Dank!