PHP Sichere Kommunikation zwischen zwei Servern

[darton]

Hallo!
Ich muss für einen Kumpel etwas programmieren und weiß nicht so ganz genau, wie man da vorgehen soll. Es geht darum, dass von einem Server zu einem anderen ein POST-Request abgeschickt werden muss, woraufhin der andere Server dann eine bestimmte Datenbank-Query ausführt. Das Ding ist, dass dies natürlich sicher sein soll, d.h. nur von dem einen Server darf der Request akzeptiert werden und sonst von keinem anderen.
Ich hab schon überlegt, ob man das mit einer Verschlüsselung macht, also dass jeder Server einen öffentlich und privaten Schlüssel hat und man dann einen verschlüsselten String austauscht, der dann beim ankommenden Server entschlüsselt wird. Aber vielleicht gibt es da ja schon was irgendwo im Internet vorprogrammiert, was man dann einfach mit PHP benutzen kann. Wisst ihr, wie man sowas am besten macht?

 

[benneq]

Wie wäre es mit SSL? Das sollte jeder Webserver, der PHP bereitstellen kann, auch beherrschen.

Das mit dem "d.h. nur von dem einen Server darf der Request akzeptiert werden und sonst von keinem anderen." Das Problem löst sich doch von selbst durch Angabe der IP bzw. URL. Oder nicht?!


EDIT: Eine Alternative wäre natürlich noch ein VPN. ;-) Dann befinden sich beide Server in ihrem eigenen verschlüsselten Netzwerk und (falls richtig konfiguriert) kann niemand anders drauf zugreifen.

 

[jan4321]

Hast du zugriff auf die Webserver? Ich würde es nämlich sonst einfach über eine Whitelist lösen. Nur der erste Server bzw. Cluster darf auf den DB Server zugreifen und fertig. Verschüsselung würde ich eh immer machen, das sollte heutzutage eh Standard sein...

Aber wenn du mir die frage gestattest, warum das ganze?^^ Wäre es nicht einfacher dich direkt auf die DB zu conecten und den Query vom eigentlich Webserver zu starten? XD
So ein paar Hintergrund infos währen für eine Empfehlung nicht schlecht ;-)

 

[Karol_]

So wie du es beschreibst, scheint aber nicht nur der Zugriff sondern auch der Transport der Daten über das Internet (Intranet?) geschützt werden. Nun, es gibt mehrere Möglichkeiten, wie man sich so etwas basteln kann - in jedem Fall aber erhält man die maximale Sicherheit nur mit einer Kombination aus mehreren Elementen.

Zum Zugriff: die wohl einfachste Variante wäre, den Zugriff auf die gefragte(n) .php Dateie(n) nur von bestimmten IP-Adressen zuzulassen. Sofern es sich um statische IPs handelt und diese nicht mit anderen Benutzern geteilt werden müssen (zB Shared Server), wäre dies ein guter erster Schritt. Zusätzlich kann das zweite PHP-Script auch gewisse GET, POST oder COOKIE Daten verlangen, bevor es eine Datenbankanfrage startet und die Daten ausgibt.

Zum Transport: PHP und die meisten (?) oder vielleicht sogar alle relevanten Socket-Funktionen beherrschen das https-Protokoll. Würde das schon reichen oder willst du die Daten selbst auch noch zusätzlich verschlüsseln? Wenn du Zugriff auf die PHP-Installation hast (also Admin-Zugriff auf beiden Servern), kannst du mit GnuPG eine Erweiterung zur sicheren Verschlüsselung installieren.

 

[benneq]

Eine DB über das ganze Internet freizugeben ist ... ganz schön fahrlässig! Vor allem funktioniert das Whitelisting bei dynamischen IPs nicht mehr wirklich. Deshalb setzt man z.B. (wie hier) einen Webserver davor, der ein Interface zur Datenbank bereitstellt, damit der Zugriff kontrolliert / beschränkt werden kann.

 

[ice-breaker]

Klingt für mich auch erstmal nach nem IP-Whitelisting. Als Alternative für dynamische IPs einfach die Nachricht (zum Auslösen der Aktion) digital signieren, damit ist sichergestellt, dass sie von dem ganz bestimmten Sender kommt.

 

[jan4321]

Um Dynamische IPs geht es hier ja auch nicht... Wenn ein Webserver auf den anderen zugreift gehe ich davon aus, das beide eine Feste IP haben, die man Whitelisten kann. Inwiefern die Infrastruktur schüzenswert ist, können wir doch gar nicht beurteilen, mit den paar infos, die wir haben.
Außerdem gehe ich mal davon aus, das die DB nicht aus dem Inet erreichbar sein soll (Wie gesagt gut^^), sonst hätte er das ja machen können, was ich oben gesagt habe. Wobei man die DB auch nur intern auf dem Server Connecten erreichbar machen könnte (so wie bei den Meisten Webhostern üblich) damit wäre die DB geschützt. Authentifizierung auf dem Webserver ist ein ganz anderes Thema.

Wie gesagt, wenn man nicht mehr über die Hintergründe weiß, kann man keine Empfehlungen aussprechen.

 

[darton]

Also es geht um einen Online-Shop. Diesen Shop gibt es in vielen Sprachen, allerdings ist das blöderweise so gemacht worden, dass jeder Shop auf einem anderen Server läuft und somit auch seine eigene DB hat. Jetzt sollen Artikel als nicht vorrätig markiert werden und zwar auf allen Servern gleichzeitig. Dafür brauche ich dann eben so einen Request, der einmal im Kreis verteilt wird, sodass überall der Artikel nicht mehr vorrätig ist. Von einem zentralen Server würde dann dieser Request abgeschickt werden. Also man könnte jetzt erstmal nur Anfragen von diesem Server zulassen (IP-Whitelisting). Und wenn ich eure Vorschläge so durchlese scheint ja https vernünftig zu sein, um eine sichere Request abzuschicken. Im Request selbst steht dann also nur eine Artikel-Nummer, die nicht verschlüsselt werden müsste.

 

[ice-breaker]

HTTPS schützt nur die Satenübertragung, garantiert dir aber nicht von welchem Server die Anfrage kommt.

 

[Daaron]

Entweder du machst ein IP-Whitelisting für deinen Request, oder du lässt direkt für die Whitelist-IPs einen Datenbank-Zugriff zu. Normalerweise hast du ja nur als DB_User@localhost mit Rechten, es ist aber keineswegs unsicher, einem anderen User (oder demselben) von außen Zugriff zu erlauben, solange er von einer bestimmten IP (oder mehreren) kommt. Anders funktioniert Master-Slave - Replikation bei Datenbanken ja eh nicht.

 

[Funart]

Das was du suchst ist eine Digitale Signatur. Damit lässt sich feststellen ob der Request von richtigen Empfänger kommt.
Die Datenbank würde ich niemals nach ausen hin zugänglich machen.
Mir stellt sich eher die Frage ob es nicht möglich ist die Datenbanken nur im Rechenzentrum intern frei zu geben oder per VPN etc.

 

[darton]

Ich denke, ich werde es jetzt mal so probieren, wie es auf dieser Seite beschrieben ist.

 

[asdfman]

das was du suchst ist eine digitale signatur. Damit lässt sich feststellen ob der request von richtigen empfänger kommt.

nö.

 

[darton]

nö.

Warum "nö"? Digitale Signaturen haben ja gerade den Zweck die Integrität von Nachrichten und die Authentizität des öffentlichen Schlüssels sicherzustellen. Natürlich muss man sicherstellen, dass der öffentliche Schlüssel nicht gefälscht ist, aber wenn man das mal vernachlässigt, erfüllen digitale Signaturen ja genau meinen Zweck.

 

[Daaron]

Die Datenbank würde ich niemals nach ausen hin zugänglich machen.

Genau das tut man aber, wenn man mit Replikation und redundanten Systemen arbeitet. Dann ist z.B. Server A der primäre Ansprechpartner für die DB-gestützte Anwendung, gleichzeitig erzählt Server A alle seine Änderungen auch Server B... dementsprechend hat B einen offenen Zugang für A (und sonst keine IP).

Sowas ist absolut sicher, solange man nicht
a) das Passwort zu lasch wählt und
b) weder die Kontrolle über A verliert noch auf IP Spoofing hereinfällt

 

[darton]

Genau das tut man aber, wenn man mit Replikation und redundanten Systemen arbeitet. Dann ist z.B. Server A der primäre Ansprechpartner für die DB-gestützte Anwendung, gleichzeitig erzählt Server A alle seine Änderungen auch Server B... dementsprechend hat B einen offenen Zugang für A (und sonst keine IP).

Sowas ist absolut sicher, solange man nicht
a) das Passwort zu lasch wählt und
b) weder die Kontrolle über A verliert noch auf IP Spoofing hereinfällt

Leider blocken ja viele Anbieter den Zugriff von außen auf die Datenbank. Das heißt, ich müsste wohl einen SSH-Tunnel verwenden und wenn ich mit PHP programmiere, funktioniert dies ja nur, wenn die SSH-Erweiterung installiert ist. Das weiß ich leider nicht, ob das der Fall ist. Müsste ich mal rausfinden. Wenn nicht, werd ich wohl auf die Variante mit den digitalen Signaturen zurückgreifen.

 

[Funart]

nö.

Für ein wenig mehr Begründung war wohl keine Zeit mehr?

Genau das tut man aber, wenn man mit Replikation und redundanten Systemen arbeitet. Dann ist z.B. Server A der primäre Ansprechpartner für die DB-gestützte Anwendung, gleichzeitig erzählt Server A alle seine Änderungen auch Server B... dementsprechend hat B einen offenen Zugang für A (und sonst keine IP).

Sowas ist absolut sicher, solange man nicht
a) das Passwort zu lasch wählt und
b) weder die Kontrolle über A verliert noch auf IP Spoofing hereinfällt

Ich persönliche glaube nicht das es best practice ist den Datenbankserver nach ausen hin zugänglich zu machen. Jedenfalls verstehe ich darunter den Zugang über das Internet.
Zugänglich sollte eine Datenbankserver nur über interne Netzwerke VPN etc sein. Die Konfiguration findet halt nicht auf dem Server statt.

 

[asdfman]

Eine digitale Signatur allein hilft nicht, weil man auch sicher stellen muss, von wem die Signatur kommt.
Jeder kann seine Kommunikation signieren. Deshalb benötigt man eine vernünftige PKI, die hinzubekommen
wieder nicht gerade trivial ist.

€: Noch ein Beispiel, dass nichtmal superreiche Firmen digitale Signaturen richtig verwenden.

Ich habe einen Ipod Touch, der mit IOS läuft. Immer, wenn eine neue Version von IOS herauskommt und
ich diese auf meinem MP3-Player installieren will, fordert Itunes von Apple eine digitale Signatur für die
Firmware an und das Gerät bootet nicht, wenn die Signatur ungültig ist. Kurze Zeit nach dem Erscheinen
einer neuen Version von IOS signiert Apple die ältere Version nicht mehr, um zu verhindern, dass man
auf sein Gerät ältere Firmwares installiert.

Letzteres geht aber trotzdem unter bestimmten Umständen. Und das liegt daran, dass einfach nur eine
vorhandene digitale Signatur nicht reicht, zu verifizieren, dass diese auch aktuell ausgestellt wurde
(oder überhaupt von dem, der vorgibt sie ausgestellt zu haben). Und dafür muss nicht einmal der private
Schlüssel kompromittiert sein.

 

[Funart]

Manchmal denk ich mir Personen posten / wiedersprechen nur des postens / wiedersprechens wegen.
Ich könnte mich nämlich nicht daran erinner gepostet zu haben er soll eine nutzlose Form der Digitialen Signatur verwenden. Der Grad der benötigten Sicherheit obliegt darton.

Soviel als Hinweis, dass was er betreibt ist kein Atomreaktor. Für alles weitere soll er sich selbst in die Thematik einlesen wenn er Fragen dazu hat wird er sie sicher stellen.
Komm mir hier manchmal vor als müsste ich meine Posts in einer Art und weise verfassen, dass sie mein Formaler Methoden Prof als formalen Beweis akzeptiert.

 

[asdfman]

Eine digitale Signatur allein ist nunmal nutzlos. Und mehr hast du nicht gesagt. Deshalb war dein Tip
nicht produktiv. Wenn du ihm jetzt sagst, wie man eine vernünftige PKI implementiert, könnte man
das sogar hilfreich nennen. Aber das ist schwer. Zu sagen "Nutze digitale Signaturen" ist leicht, aber
jeder naive Ansatz ist zum Scheitern verurteilt.

Und wenn er ja doch keinen Atomreaktor betreibt und das ist ja alles kein Drama, dann kann er auch
auf digitale Signaturen oder andere Versuche, die Kommunikation zu schützen gleich verzichten. Dann
war dein Einwurf sogar deinem eigenem Verständnis nach sinnlos und du hättest ihn dir sparen können.