nicht angemeldet
Moin Moin!
Wie immer: It depends.
ist es eine sinnvolle Lastverteilung, wenn die DB auf einem zweiten Server läuft?
Ja, oft, aber nicht immer. Es ist jedenfalls ein gängiges Setup für größere Web-Anwendungen (nicht nur PHP/MySQL), Webserver und DB-Server auf zwei verschiedene Maschinen zu legen. Damit ist es oft auch möglich, einfach zwei oder drei identische Webserver auf die selbe DB zugreifen zu lassen und vor die Webserver einen Loadbalancer zu stellen. Genau dieses Setup läuft seit fast 10 Jahren bei einem meiner früheren Arbeitgeber zur Zufriedenheit aller.
(In dem Setup gibt es außerden noch einen dedizierten Fileserver, der den Webservern größere Datenmengen außerhalb der DB bereitstellt.)
Während PHP auf die Antwort von MySQL wartet, müsste der PHP- Rechner doch für weitere Requests mehr Zeit haben?
Nicht Zeit, sondern Resourcen. Die Arbeit, die die DB macht, entfällt und steht der Web-App zur Verfügung.
Oder frisst das Handling für das Übertragen diesen Zeitvorteil wieder weg?
Damit hast Du genau den Knackpunkt getroffen. Wenn Du riesige Datenmengen aus der DB ziehen mußt, kann die Verbindung zwischen Web-Server und DB-Server zum Nadelöhr werden. In der Regel ist es aber so, dass man möglichst viel innerhalb der DB anstellt und dann nur die Daten wirklich aus der DB holt, die letztlich beim Browser landen. Wenn man riesige Mengen aus der DB zieht, um dann zwei oder drei Zahlen zum Browser schickt, macht man etwas grundsätzlich falsch, vermutlich angefangen bei der DB-Struktur.
Eine dedizierte Verbindung zwischen DB- und Webserver (Crossover-Kabel und/oder Gigabit Ethernet) ist auf jeden Fall sehr hilfreich. Über PPP und RS232 würde ich so ein Setup jedenfalls nicht fahren wollen. ;-) So ein privates DB-Netz reduziert auch die Angriffsmöglichkeiten auf die DB, die explizit so eingestellt wird, dass sie nur auf Anfragen aus dem privaten DB-Netz reagiert.
Aus Sicherheitsgründen kann es dennoch sinnvoll sein. Wird der PHP- Server gehackt, ist die DB nicht automatisch betroffen.
Doch, ist sie. Sobald ich den Programmcode analysieren kann, kenne ich auch den Weg, auf die DB zuzugreifen. Und damit hast Du verloren. Egal, ob Du PHP, Java, Perl, C, C++, VB.NET oder Assembler einsetzt. Du kannst es mir mit einigen Techniken etwas schwerer machen, Deinen Code zu analysieren, aber Du kannst es nicht verhindern.
Wenn Du Dein System (egal ob 1 oder 2 Server) sicher machen willst, sorg erst einmal dafür, dass es möglichst wenig Angriffsflächen gibt:
* Alle Eingaben als Angriff werten, bis das Gegenteil durch einen mathematischen Beweis bewiesen ist. Triviales Beispiel: Eine Altersangabe sollte auf /[1]+$/ matchen, meinetwegen auch noch strenger auf /[2]{1,3}/ oder auf /[3][0-9]{0,2}$/, nach der Umwandlung in einen Integer sollte der Wert >=0 und <130 sein. Ist auch nur eine Bedingung nicht erfüllt, wird die Eingabe nicht angenommen.
* Möglichst wenige Services laufen lassen. Beispiel: IRC hat auf einem reinen Webserver nichts verloren, ebenso wenig ein SVN-Repository oder ein Game-Server.
* Keine bekannt unsicheren Services laufen lasssen: Beispiele: rsh, rlogin, rexec auf gar keinen Fall. Telnet und FTP besser durch SSH ersetzen.
* Services so sicher wie möglich konfigurieren. Beispiel: SSH nur mit Protokollversion 2, root-Login ausschalten, Passwort-basiertes Login ausschalten, nur Public Key Login erlauben.
* Keine unnötigen Optionen aktivieren. Beispiel: Wenn der Webserver nur FastCGI braucht, haben mod_proxy, mod_php, mod_perl, mod_rewrite und mod_speling dort nichts verloren.
* Keine unnötigen Informationen preisgeben. Beispiel: Apache kann sich mit Versionsnummer plus jedem Modul plus Betriebssystem identifizieren (ServerTokens Full). Besser konfiguriert hält der Apache aber die Klappe und verrät nur so viel wie absolut nötig (SererTokens ProductOnly). Idealerweise würde der Apache gar nichts verraten, aber das geht nur mit Eingriffen in den Code. Anderes Beispiel: use CGI::Carp qw(fatalsToBrowser) gibt im Fehlerfall möglicherweise sehr viele Informationen über die Programmstruktur preis.
Dann solltest Du einen fähigen, guten Freund bitten, Dein System anzugreifen, so hart und so böse wie möglich. Laß ihn alle Informationen zukommen, die er haben will (Konfigurationsdateien, Programmcode, ... -- denn genau das wird sich auch ein echter Angreifer besorgen), bis auf Passworte und SSH-Keys. Idealerweise scheitert er kläglich. Für den Lerneffekt ist es aber besser, wenn er in das System reinkommt und Dir die noch vorhandenen Lücken aufzeigt.
Alexander
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".