mySQL sicher machen - SSH oder SSL - Kosten - Anleitung

[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 von 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.

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