mySQL sicher machen - SSH oder SSL - Kosten - Anleitung

[baumina]

Hallo ihr Lieben,

ich möchte meine mySQL-Verbindung zu einem entfernten Rechner sicher machen, doch für mich sind das alles noch recht böhmische Dörfer. Als erstes muss ich mich glaub entscheiden ob SSL oder SSH.

Wo liegen die Vor- und Nachteile bei SSH oder SSL?
Was kommen für Kosten auf mich zu bei SSH oder SSL?
Irgendwie tendiere ich zu SSH, wenn ich mich dafür entscheiden sollte, welche Software ist da zu empfehlen bzw. hat jemand eine richtig gute und einfache Anleitung das einzurichten?
Was würdet ihr bevorzugen, womit habt ihr Erfahrungen?

Natürlich habe ich schon ein wenig gegoogelt und ein wenig das mySQL-Handbuch zu Rate gezogen, trotzdem bin ich für alle Anregungen und Links dankbar!

Edit : Noch ein paar aktuelle Fakten:
Im Moment habe ich ein Delphi-Programm, das über UniDAC eine nicht verschlüsselte Verbindung zum mySQL-Server herstellt (einfach nur IP-Adresse des Servers, Port 3306 und User + Passwort).
Dieses Programm wird von mehreren Firmen und dort von mehreren Arbeitsplätzen aus benutzt, die alle auf ein und den selben entfernten mySQL-Server greifen.

[mkinzler]

Es kommt darauf an, wie die Lösung aussieht. Geht es allgemeinum einen sicheren Zugriff (ggf. Schichtenarchitektur) oder nur darum eine vorhandenes Programm, welches bisher über eine unsichere Verbindung auf eine MySQL-Server zugreift.

Für 2. hast du die Wahl zwischen VPN oder einefacheren Tunnellösungen wie stunnel o. ö.

https://www.stunnel.org/index.html
http://netz10.de/2011/01/10/ssh-tunnel/

[baumina]

Es handelt sich um ein vorhandenes Programm, das bislang eine unsichere Verbindung verwendet (IP-Adresee des mySQL-Servers und Port 3306 über UniDAC)

[Sir Rufo]

Ein MySQL Server der direkt übers Internet erreichbar ist, ist das größte Sicherheitsrisiko.

Darum sollte der Zugriff darauf niemals direkt erfolgen.

Die fertige Lösung gibt es doch direkt bei DevArt
http://www.devart.com/unidac/docs/in...ov_article.htm

[mkinzler]

Ist natürlich noch besser als die Verwendung von 3rd-Party-Lösungen.

[baumina]

Dass der Zugriff mit UniDAC über SSL geht, weiß ich. Dass man mySQL mit OpenSSL oder yaSSL laufen lassen kann, weiß ich auch. Mein Haupt-Problem ist, dass momentan weder der mySQL-Server, noch die Clientsoftware für SSL konfiguriert ist und ich nocht nicht so richtig herausgefunden habe, was ich denn so alles kaufen/installieren und mein meinem Delphi-Programm ausliefern muss.

[mkinzler]

Wo läuft der MySQL-Server?
Läuft dort auch ein Webserver?
Ist schon ein SSL-Zertifikat vorhanden?
Interne Benutzung oder auch Zugriff von Kunden?

[baumina]

Zitat:

Zitat von mkinzler (Beitrag 1262157)

Wo läuft der MySQL-Server?
Läuft dort auch ein Webserver?
Ist schon ein SSL-Zertifikat vorhanden?
Interne Benutzung oder auch Zugriff von Kunden?

Das mySQL läuft auf einem Kunden-Windows Server, auf dem ich remote-Zugriff habe, um das mySQL administrieren zu können.
Auf diesem Server läuft nur mein mySQL und ein FTP-Server, den mein Programm ebenfalls zur Dokumentenablage benutzt. Ein Webserver läuft darauf glaube ich nicht.
Da ich kein SSL-Zertifikat erstellt habe, gehe ich davon aus dass keins vorhanden ist.
Der Kunde greift auch mit meinem Programm intern darauf zu, allerdings über eine andere IP-Adresse als die externen Firmen.

Zur Zeit wird mir bei dem Kunden ein neuer Windows Server 2012 als VM erstellt, auf dem ich dann das neueste mySQL installieren werde. In diesem Zuge kam jetzt die Überlegung das mySQL so zu installieren, dass in Zukunft der Zugriff über SSL erfolgen soll, oder eben über SSH.

[samso]

Das ist doch ein Server der nur im LAN genutzt werden soll und nur für Wartungszwecke von außen erreicht werden soll, oder habe ich das falsch verstanden? Dann ist aus meiner Sicht ein VPN-Zugang doch sehr viel einfacher, als jeden einzelnen Dienst zu verschlüsseln (denn nachdem Du mySql verschlüsselt hast, musst Du ja auch noch FTP verschlüsseln).

[mquadrat]

Soll intern auch verschlüsselt werden? Wenn du SSL sowohl von außen als auch von innen verwenden möchtest, muss die Domain gleich sein, sonst wird das Server-Zertifikat im Client zurückgewiesen. Beispiel: Wenn dein Zert auf dbserver.meinefirma.de lautet, dann musst du den Server auch IMMER über diesen Namen aufrufen, sonst kaputt.

[baumina]

@samso Ohje, FTP ist also auch unsicher, wie ich deinen Worten entnehme. Dann ist die SSH-Lösung wohl eher etwas für mich ... ist VPN denn SSH? Ich bin komplett verwirrt. Ich glaube ich muss verdammt viel Grundwissen erlangen *schnief

@mquadrat auf sowas hat mich mein Kollege auch schon hingewiesen, performancetechnisch ist das natürlich grauenhaft, aber zur Not würde ich eben dann auch interne Zugriffe verschlüsseln.

[mkinzler]

VPN bedeutet, das eine Teilstrecke eines Netwerkes über einen verschlüsselten Kanal durch eine unsichere "Wolke" erfolgt. Dafür gibt es verschiedene Wege.
-SSL
-IPSEC
-SSH

und weitere.

Dies kann jeweils über Software oder auch über Hardware (Router) bereitgestellt werden

[Valle]

Du suchst ein VPN (z.B. mit OpenVPN). Von der Lösung mit einzeln per SSL verschlüsselten Services würde ich abraten, da diese Services am besten gar nicht öffentlich erreichbar sein sollten.

SSH dient zu Administration von (u.a.) Linux Webservern und hat hier gar nichts zu suchen. Damit kann man zwar theoretisch auch Ports tunneln (ähnlich zu einem VPN), aber davon rate ich ab. SSH ist nicht für deinen Einsatzzweck konzipiert.

@mkinzler: SSL und SSH sind doch kein VPN! Neben IPSec gibt's da vor zum Beispiel OpenVPN, Cisco VPN, Fritz VPN und mehr.

[Sir Rufo]

Das einfachste (und trotzdem sicher(er)) wäre einen Webserver (mit PHP-Unterstützung) zu installieren. Die Verbindung wird per SSL abgesichert.

Auf dem Webserver kommt dann das PHP-Skript von DevArt zum Einsatz und schon steht die Verbindung zum MySQL-Server.

Ein weiteres PHP-Skript (müsste erstellt werden) regelt dann den Austausch der Dateien. Intern kann das auch bei FTP bleiben.

Der Sinn und Zweck dabei ist es, den Zugriff auf die einzelnen Dienste über einen Vermittler laufen zu lassen.

Code:

Client <-- HTTPS --> WebServer <-- PHP --> MySQL-Server
Client <-- HTTPS --> WebServer <-- PHP --> FTP-Server
Client <-- HTTPS --> WebServer <-- PHP --> Was auch immer

Die einzige Schwachstelle ist nun der WebServer und die PHP-Skripte und nicht mehr (wie vorher) der MySQL-Server, der FTP-Server, der "Was auch immer" Dienst. Das reduziert die Angriffsfläche.

[samso]

Hmm, die https-Lösung verstehe ich nicht wirklich. Das heißt ja dann, dass man den Client/die Clients anpassen muss. Das würde ich persönlich eher vermeiden wollen. Das scharmante an einem VPN-Tunnel ist ja, dass man weder den Server noch den Client ändern muss. Dafür muss sich allerdings mit den VPN-Clients und VPN-Servern auseinander setzen und das Routing im Netzwerk klären. Aber nur einmal - danach sind alle Dienste und Protokolle abgesichert.

[Valle]

Es handelt sich eigentlich auch um zwei Lösungen für zwei verschieden Probleme.

Die Frage ist einfach: Sind die Clients vertrauenswürdig?

Falls ja, dann tut es ein VPN. Damit ist der Zugriff auf den Server abgesichert (Authentifiziert und verschlüsselt). Beachte, dass dabei allerdings die Clients vollen Zugriff auf den Server haben. Oder zumindest so viel, wie sie Zugriffsrechte auf den Server haben.

Die andere Lösung benutzt du, wenn die Clients nicht vertrauenswürdig sind. Also zum Beispiel, wenn du eine App entwickelst. Da darf natürlich nicht jeder Zugriff auf alles auf dem Server haben. Dann benutzt man diese Proxy-Lösung via HTTP, um die Zugriffsrechte zu verfeinern.

Man kann die HTTP-Proxy-Lösung auch mit VPN kombinieren, um es noch sicherer zu gestalten.

Für mich klang das vom TE jetzt so, als sei die Proxy Lösung hier nicht relevant.

[Sir Rufo]

Zitat:

Zitat von samso (Beitrag 1262253)

Hmm, die https-Lösung verstehe ich nicht wirklich. Das heißt ja dann, dass man den Client/die Clients anpassen muss. Das würde ich persönlich eher vermeiden wollen. Das scharmante an einem VPN-Tunnel ist ja, dass man weder den Server noch den Client ändern muss. Dafür muss sich allerdings mit den VPN-Clients und VPN-Servern auseinander setzen und das Routing im Netzwerk klären. Aber nur einmal - danach sind alle Dienste und Protokolle abgesichert.

Den Client muss man trotzdem ändern (VPN=>Client-Rechner/HTTPS=>Client-Anwendung).
Jetzt kommt es darauf an, wie aufwändig welches Szenario ist.

Beispiele:

• Bei 1000 Rechnern (unterschiedlichste Windows-Versionen, irgendwo auf der Welt verteilt) und einer Client-Anwendung mit einer Update-Funktion wird es wohl einfacher sein auf die HTTPS Variante umzusteigen (wenn 90% das Update installiert haben, dann den alten Zugangsweg blockieren ;))
• Bei 10 Rechnern (gleiche Windows-Version, alle quasi direkt zugreifbar) und einer Client-Anwendung ohne Update-Funktion wird die VPN-Variante günstiger sein.

[Sir Rufo]

Zitat:

Zitat von Valle (Beitrag 1262256)

Es handelt sich eigentlich auch um zwei Lösungen für zwei verschieden Probleme.

Die Frage ist einfach: Sind die Clients vertrauenswürdig?

Egal ob vertrauenswürdig oder nicht, wenn man alle Zugriffe über einen Webserver leitet, dann hat das einige Vorteile:

• Der Anwender benötigt nur ein Konto, und das wird immer für alle erlaubten Dienste synchron sein (der Webserver identifiziert Benutzer X und kennt die zugewiesenen Zugangsdaten für alle anderen Dienste)
• Ist ein Anwender nicht mehr vertrauenswürdig, dann wird an genau einer Stelle der Zugang gesperrt
• Egal welcher Dienst/welches Protokoll intern angesprochen wird, der Client spricht immer HTTP/HTTPS. Das kann eigentlich jedes Device. (Bei MySQL wird die Luft schon dünner und bei SAMBA wird es eng)
• Bei einem Strukturwechsel (MySQL wird gegen DB2 getauscht, statt FTP jetzt SAMBA) kann das idR ohne Änderung an den Clients erfolgen
• ...

[samso]

Irgendwie erklärst Du Deine https-Lösung nicht wirklich, oder ich verstehe das einfach falsch. Du willst doch der Client-Anwendung das https-Protokoll beibrigen? Sehe ich das erst mal richtig? Falls ich das richtig sehe, dann musst Du doch alles auf https umstellen. Dann ist nichts mehr mit FTP, RDP, bla-Protokoll. Dann muss alles über https gejuchtelt werden. Das heißt programmieren bis der Arzt kommt oder nicht?

[Sir Rufo]

Zitat:

Zitat von samso (Beitrag 1262261)

Irgendwie erklärst Du Deine https-Lösung nicht wirklich, oder ich verstehe das einfach falsch. Du willst doch der Client-Anwendung das https-Protokoll beibrigen? Sehe ich das erst mal richtig? Falls ich das richtig sehe, dann musst Du doch alles auf https umstellen. Dann ist nichts mehr mit FTP, RDP, bla-Protokoll. Dann muss alles über https gejuchtelt werden. Das heißt programmieren bis der Arzt kommt oder nicht?

Nur der Client spricht dann HTTP/HTTPS mit dem Webserver, der kann dann wiederum mit allem auf jede erdenkliche Weise sprechen, sofern der das erreichen kann.

"Programmieren bis der Arzt kommt" das kommt darauf an, wie die Client-Anwendung gebaut wurde.
Wenn da einfach eine FTP-Komponente draufgeklatscht wurde und dann kreuz und quer darauf zugegriffen wird, dann ja (das rächt sich also jetzt).

Hat man den Zugriff aber abstrakt gehalten, dann baut man sich einfach eine konkrete Klasse, die das nun über HTTP/HTTPS bewerkstelligt.

Delphi-Quellcode:

IFileRepository = interface
  procedure ChangeDir( const ADirectory : string );
  function CurrentDir : string;
  procedure GetFile( const AFilename : string; AStream : TStream );
  procedure PutFile( const AFilename : string; AStream : TStream );
  ... usw ...
end;

und statt

Delphi-Quellcode:

var
  FileRepository : IFileRepository;
begin
  FileRepository := TFtpFileRepository.Create( 'ftp.example.com', 'user', 'pass' );
  ...
end;

nimmt man also nun

Delphi-Quellcode:

var
  FileRepository : IFileRepository;
begin
  FileRepository := THttpFileRepository.Create( 'www.example.com/ftpapi.php', 'user', 'pass' );
  ...
end;

der ganz große Vorteil dabei ist auch, dass man bei der Entwicklung der Anwendung drumherum sich diesen Umweg über das Internet sparen kann, wenn man noch das hier

Delphi-Quellcode:

var
  FileRepository : IFileRepository;
begin
  FileRepository := TLocalFileRepository.Create( 'C:\Data\mirror-ftp-example-com\' );
  ...
end;

aus dem Hut zaubern kann :)

[mkinzler]

Zitat:

@mkinzler: SSL und SSH sind doch kein VPN! Neben IPSec gibt's da vor zum Beispiel OpenVPN, Cisco VPN, Fritz VPN und mehr.

Dann schau mal, auf was OpenVPN basiert -> SSL ( SSL-VPN) und auch Cisco arbeitet nun primär über SSL und nicht mehr IPSEC (CISCO AnyConnect).

http://openvpn.net/index.php/access-.../overview.html

Und es gibt auch Lösungen mit OpenSSH

https://wiki.archlinux.org/index.php/VPN_over_SSH

[Valle]

@mkzinler: SSL ist trotzdem kein VPN. ;-)

Java ist auch kein Webserver. Und ein Rechteck kein Quadrat. Klar was ich meine?

Bei deinem Link ist SSH aber auch nicht das VPN direkt, sondern der TUN/TAP Treiber des Linux Kernels. SSH überimmt die Point-to-Point Verbindung zum Remote Server und schiebt die Daten durch einen Tunnel. Du hast also einen Tunnel, aber kein Network. (VPN) (Ich gebe aber zu, dass das Wortklauberei ist.)

@Sir Rufo: Du hast Recht mit dem was du sagst, aber ich habe die Absicht des TE anders verstanden. Deine Technik kann durchaus sinnvoll sein. Aber wenn es nur um die Anbindung externer Standorte an einen MySQL-Server geht, wäre das nicht die Lösung, die ich bevorzugen würde. Zumal man mit halb-öffentlichen Webservices die Angriffsfläche ziemlich breit fächert. Es hängt eben vom Einsatzszenario ab. Lass uns warten was der TE sagt.

[baumina]

Wow, danke für diese rege Beteiligung mir helfen zu wollen, danke! Wie gesagt sind das für mich noch recht viele Abkürzungen unter denen ich mir bislang nur so ungefähr etwas vorstellen kann.

Ich versuche das gerade mal für mich alles zusammenzufassen.

Lösung 1 : HTTPS
Hierfür müsste ich auf dem Server noch zusätzlich einen Apache o.ä. installieren, der als Web-Server dienen soll. Dienst wie FTP oder mySQL wären dann zwar auch auf dem Server, aber von außen nicht erreichbar. Den Zugriff aus meinem Client-Programm für FTP (im Moment nehme ich eine TALWinInetFTPClient-Komponente dafür) müsste ich dann auf ein HTTP-Zugriff abändern. Der MySQL-Zugriff müsste dann wie geändert werden? Das habe ich nicht verstanden mit dem "PHP-Skript von DevArt", ist das bei der UniDAC-Komponente dabei, muss ich auf der Clientseite den Zugriff ändern? Muss ich für all das Zertifikate erstellen und wenn ja womit erstelle ich die?

Lösung 2 : VPN
Hierfür müsste ich auf dem Server und auf allen Clients VPN (z.B. OpenVPN) installieren? Gibt man dann dafür serverseitig nur die Ports 3306 und 21 frei und auf der Clientseite bleibt alles gleich?

Lösung 3 : Beide Dienste (mySQL und FTP) auf SSL umstellen
Dafür müsste ich mySQL serverseitig umstellen und Zertifikate erstellen. Clientseitig müsste ich dann die Zertifikate auf jedem PC installieren und den mySQL-Zugriff in meinem Programm anpassen. Ebenso für FTP server- und clientseitig umstellen und Zertifikate verteilen, wobei der FTP-Server nicht in meinem Administrationsbereich liegt, das müsste dann die IT-Abteilung meines Kunden übernehmen.

Nochmal kurz zu meinem Ist-Zustand:
- 1 Server, der bei meinem Kunden steht, der Kunde ist groß, sehr groß. Die IT-Abteilung hat den Server meines Wissens nach außen (außer für meinen FTP- und mySQL-Zugriff) komplett abgeschirmt, d.h. er ist sicherlich hinter einer Firewall und was es da sonst noch so alles gibt. Über Juniper habe ich darauf remote-Zugriff um ihn administrieren zu können.
- Mit meiner Client-(Delphi)-Software greifen nun ca. 10 verschiedene Firmen (in ganz Deutschland verteilt) via mySQL (UniDAC) und FTP (TALWinInetFTPClient) auf die Daten zu.
- Ebenfalls läuft meine Client-Software innerhalb der Firma, in der der Server steht und greift ebenfalls auf den mySQL- und FTP-Server zu, allerdings über eine interne IP-Adresse.

[mkinzler]

Zitat:

Zitat von baumina (Beitrag 1262396)

Wow, danke für diese rege Beteiligung mir helfen zu wollen, danke! Wie gesagt sind das für mich noch recht viele Abkürzungen unter denen ich mir bislang nur so ungefähr etwas vorstellen kann.

Ich versuche das gerade mal für mich alles zusammenzufassen.

Lösung 1 : HTTPS
Hierfür müsste ich auf dem Server noch zusätzlich einen Apache o.ä. installieren, der als Web-Server dienen soll. Dienst wie FTP oder mySQL wären dann zwar auch auf dem Server, aber von außen nicht erreichbar. Den Zugriff aus meinem Client-Programm für FTP (im Moment nehme ich eine TALWinInetFTPClient-Komponente dafür) müsste ich dann auf ein HTTP-Zugriff abändern. Der MySQL-Zugriff müsste dann wie geändert werden? Das habe ich nicht verstanden mit dem "PHP-Skript von DevArt", ist das bei der UniDAC-Komponente dabei, muss ich auf der Clientseite den Zugriff ändern? Muss ich für all das Zertifikate erstellen und wenn ja womit erstelle ich die?

Du würdest nur ein Zertifikat benötigen, für den Server. Ich würde aber bei diesem Szenario eher auf eine Mehrschichtarchitektur setzen.

Zitat:

Lösung 2 : VPN
Hierfür müsste ich auf dem Server und auf allen Clients VPN (z.B. OpenVPN) installieren? Gibt man dann dafür serverseitig nur die Ports 3306 und 21 frei und auf der Clientseite bleibt alles gleich?

Nach aussen gibst Du die Ports überhaupt nicht frei. Per VPN werden die entfernten Rechner in das Netz eingebunden, sie sind dann wie "intern".
Dafür musst du dann aber auch eine VPN-Server installieren, dessen Port nach aussen Freigegeben und an den Server weitergeleitet wird. Oder Du verwendest die VPN-Funktionalität der Firewall ( in Deinem Fall Juniper kann wohl sowohl IPSEC wie SSLVPN). Am Client werden die Daten durch den VPN Client durch den Tunnel ins Netz des Server transportiert.

Zitat:

Nochmal kurz zu meinem Ist-Zustand:
- 1 Server, der bei meinem Kunden steht, der Kunde ist groß, sehr groß. Die IT-Abteilung hat den Server meines Wissens nach außen (außer für meinen FTP- und mySQL-Zugriff) komplett abgeschirmt, d.h. er ist sicherlich hinter einer Firewall und was es da sonst noch so alles gibt. Über Juniper habe ich darauf remote-Zugriff um ihn administrieren zu können.

Also scheinst Du ja schon einen VPN Zugriff zu haben?

Zitat:

- Mit meiner Client-(Delphi)-Software greifen nun ca. 10 verschiedene Firmen (in ganz Deutschland verteilt) via mySQL (UniDAC) und FTP (TALWinInetFTPClient) auf die Daten zu.

Für diesen Fall ist es fraglich, ob der Kunde bereit wäre diesen externen Kunden einen VPN-Zugriff auf ihr Netz zu gewähren. Für dieses Szeneario fällt VPN imho aus. Ich würde FTP auf SFTP (SSH) oder FTPS (SSL) umstellen und den Zugriff über SSL sichern.

Zitat:

- Ebenfalls läuft meine Client-Software innerhalb der Firma, in der der Server steht und greift ebenfalls auf den mySQL- und FTP-Server zu, allerdings über eine interne IP-Adresse.

Dies sollte ja keine Gefahr darstellen.

[mkinzler]

Zitat:

Zitat von Valle (Beitrag 1262270)

@mkzinler: SSL ist trotzdem kein VPN. ;-)

Nein und IPSEC, PPTP und L2TP auch nicht. Aber mit allen der Protokolle, kann man ein VPN aufbauen.

Zitat:

VPN bedeutet, das eine Teilstrecke eines Netwerkes über einen verschlüsselten Kanal durch eine unsichere "Wolke" erfolgt. Dafür gibt es verschiedene Wege.
-SSL
-IPSEC
-SSH

[baumina]

Ah ja, da wäre ja noch

Lösung 3 : Beide Dienste (mySQL und FTP) auf SSL umstellen
Dafür müsste ich mySQL serverseitig umstellen und Zertifikate erstellen. Clientseitig müsste ich dann die Zertifikate auf jedem PC installieren und den mySQL-Zugriff in meinem Programm anpassen. Ebenso für FTP server- und clientseitig umstellen und Zertifikate verteilen, wobei der FTP-Server nicht in meinem Administrationsbereich liegt, das müsste dann die IT-Abteilung meines Kunden übernehmen.

Habe das oben mal ergänzt.

[mkinzler]

Die Zertifikate brauchst Du nur auf den Clients installieren, wenn es sich nicht um "offizielle" handelt, d.h. wenn du diese selbst signierst.
Ich wundere mich sowieso, dass eine große Firma soche Dienste ungesichert zulässt. Oder ist Dein Programm das einzige, welches diese verwendet (und auch dann leigen wohl daten des Unternehmens in den Diensten)

[baumina]

Ja, der Server ist dort ausschließlich für den Zugriff aus meinem Programm eingerichtet worden. Ich glaube der Server befindet sich dort auch nicht im normalen Firmennetz, sondern irgendwie in einem separaten Netzbereich. Bevor wir jetzt nen riesen Wirbel machen, muss ich das Ganze auch wirklich sehr gut planen, denn sobald das Wort Sicherheitslücke beim Kunden fällt, werden alle sicher sehr panisch.

[mkinzler]

Dann könntest Du Dir auch überlegen gleich auf eine Mehrschicht-Architektur umzustellen. (DataSnap, RemoteDB, mORMoT, ...)

[baumina]

Zitat:

Zitat von mkinzler (Beitrag 1262410)

Dann könntest Du Dir auch überlegen gleich auf eine Mehrschicht-Architektur umzustellen. (DataSnap, RemoteDB, mORMoT, ...)

Auch damit habe ich mich noch niemals beschäftigt. Deswegen die laienhafte Frage : Müsste ich dafür komplett alle SQL-Befehle, die ich in meiner Anwendung drin habe, rauswerfen und durch irgendwas anderes ersetzen?

[mkinzler]

Nein, Diese würden nur in den Serverdienst verschoben.

Code:

                         SSL
Client -> ClientDataSet -----> WebService -> UniDAC-DataSet -> DBMS

[baumina]

OK, die Lösung "Mehrschichtenmodell" kommt für mich dann leider nicht in Frage, denn bis ich mit dieser Umstellung als Einzelkämpfer fertig bin, sind Monate vergangen.

Ich brauche eine Lösung, die sich eher im Aufwandsbereich von Tagen bewegt.

Daher werde ich mich wohl für Lösung 3 entscheiden. Erst mal mySQL mit yaSSL konfigurieren und mich versuchen irgendwie durchzuwurschteln. Sollte jemand eine brauchbare Anleitung (vorzugsweise auf deutsch) dafür haben, wäre ich sehr dankbar.

Wenn das dann alles geklappt haben sollte, dann noch die Umstellung von FTP auf SFTP in Angriff nehmen. Dafür muss ich Clientseitig dann wohl ne andere Komponente nehmen. Weiß mir da jemand eine Komponente und deren Kosten?

[Klaus01]

Guten Morgen,

vielleicht ist secureBridge [Features] von devArt etwas für Dich?

Grüße
Klaus

[mkinzler]

Indy ist bei Delphi dabei und kann FTP über SSL (FTPS)
Sonst Synapse, IP*Works, SecureBridge, SecureBlackBox, ...

[Neumann]

Meine Erfahrung mit MyDac sind folgende:

Verbindung zu MySQL über die Tunnel.php von Devart funktioniert mit wenigen Clients einigermassen; es gibt aber oft Verbindungsabbrüche und ist auch langsam.

Bei größerer Zahl von Clients (Grenze liegt so zwischen 10 und 20) wird die Sache unsicher und problematisch.

Verbindung mit SSL funktioniert besser, wesentlich schneller und stabiler als über Tunnel. Die Konfiguration der Verbindung ist einfach, man muss nur die entsprechenden Zertifikate haben und der Connection zuweisen.

Kaufen muss man dafür nichts.

[baumina]

Bislang ist es mir leider noch nicht gelungen meinem mySQL bei zu bringen, dass es yaSSL verwenden soll. Evtl. lag es daran, dass ich mysql über den msi-Installer installiert habe? Ich bin weiterhin für alle Tipps dankbar.

[baumina]

Ich muss das hier nochmal nach oben holen.

Ich werde nun nochmal versuchen mein mySQL auf SSL umzustellen und den FTP auf FTPS. Eine grundlegende Frage konnte mir das Internet bislang noch nicht richtig beantworten. Ein Benutzer fragt mich nach der Proxyfähigkeit meiner Anwendung.

So viel wie ich bei FileZilla verstanden habe, kann man Proxy-Einstellungen nur für FTP aber nicht für FTPS benutzen.

Fragen:
- Kann ich den FTP-Proxy weiterhin benutzen, wenn ich in Zukunft FTPS benutzen will oder umgeht man bei diesem Protokoll immer den Proxy?

- So wie ich Proxys verstehe (und ich verstehe nur wenig davon), kann man wohl für jeden Dienst (Protokoll/Port) einen Proxy-Port definieren. Was würde für mich bedeuten, dass ich für meine mySQL-Verbindung auch Proxy-Einstellungen machen (zulassen) sollte?

Wir haben hier im Haus keinen Proxy, so dass ich das leider alles gar nicht ausprobieren kann.

[Klaus01]

Hallo Baumina,

sieht nicht so gut aus für FTPs mit 'nem Proxy.

SFTP ist keine Option für Dich?

Grüße
Klaus

[baumina]

Danke Klaus,

natürlich ist SFTP eine Option, da es dafür allerdings keine kostenlose Komponente gibt dachte ich erst mal an FTPS. Doch bevor ich mir Ärger mit einem Proxy einhandle, bestelle ich lieber eine Komponente (dieses Argument müsste ja ausreichend für meinen Chef sein :wink:).

[Klaus01]

Hallo,

was ich noch gesehen haben ist tlswrap (ob das gut oder schlecht ist kann ich nicht sagen).
Ist so eine Art TLS-Proxy, FTP -> tlsWrap -> FTPs-Server.

Zu SFTP, ich nutze da die Komponente secureBridge von DevArt.

Grüße
Klaus