mySQL sicher machen - SSH oder SSL - Kosten - Anleitung

[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 von Valle:

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 von 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?

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 von Valle:

@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