it-swarm.com.de

Warum ist es nicht ratsam, die Datenbank und den Webserver auf demselben Computer zu haben?

Als Scott Hanselman das Interview mit dem Stack Overflow-Team hörte ( Teil 1 und 2 ), bestand er darauf, dass sich der SQL-Server und der Anwendungsserver auf getrennten Computern befinden sollten. Damit soll nur sichergestellt werden, dass bei einer Beeinträchtigung eines Servers nicht auf beide Systeme zugegriffen werden kann. Überwiegen die Sicherheitsbedenken die Komplexität von zwei Servern (zusätzliche Kosten, dedizierte Netzwerkverbindung zwischen den beiden, mehr Wartung usw.), insbesondere für eine kleine Anwendung, bei der keines der beiden Teile zu viel CPU oder Speicher benötigt? Selbst bei zwei Servern und einem kompromittierten Server kann ein Angreifer weiterhin schwerwiegenden Schaden anrichten, indem er entweder die Datenbank löscht oder den Anwendungscode durcheinanderbringt.

Warum wäre das so eine große Sache, wenn Leistung kein Problem ist?

114
Tai Squared
  1. Sicherheit. Ihr Webserver befindet sich in einer DMZ, die für das öffentliche Internet zugänglich ist und nicht vertrauenswürdige Eingaben von anonymen Benutzern entgegennimmt. Wenn Ihr Webserver kompromittiert wird und Sie beim Herstellen einer Verbindung zu Ihrer Datenbank die Regeln mit den geringsten Rechten befolgt haben, kann Ihre App über die Datenbank-API die maximale Verfügbarkeit gewährleisten. Wenn Sie eine Geschäftsstufe dazwischen haben, haben Sie einen weiteren Schritt zwischen Ihrem Angreifer und Ihren Daten. Befindet sich Ihre Datenbank hingegen auf demselben Server, hat der Angreifer jetzt Root-Zugriff auf Ihre Daten und Ihren Server.
  2. Skalierbarkeit. Wenn Sie Ihren Webserver staatenlos halten, können Sie Ihre Webserver mühelos horizontal skalieren. Es ist sehr schwierig, einen Datenbankserver horizontal zu skalieren.
  3. Performance. 2 Boxen = 2-fache CPU, 2-fache RAM und 2-fache Spindeln für den Plattenzugriff.

Trotzdem kann ich durchaus vernünftige Fälle erkennen, in denen keiner dieser Punkte wirklich von Bedeutung ist.

139
Mark Brackett

Es spielt keine Rolle wirklich (Sie können Ihre Site mit Web/Datenbank ziemlich glücklich auf demselben Computer ausführen), es ist nur der einfachste Schritt bei der Skalierung. .

Genau das hat StackOverflow getan - angefangen mit einem einzelnen Computer, auf dem IIS/SQL Server ausgeführt wird, und als es anfing, stark ausgelastet zu werden, wurde ein zweiter Server gekauft, auf den der SQL Server verschoben wurde.

Wenn die Leistung keine Rolle spielt, verschwenden Sie kein Geld, wenn Sie zwei Server kaufen/warten.

39
dbr

Andererseits bezogen sie sich auf einen anderen Blogger, Scott (Watermasyck, von Telligent), und stellten fest, dass die meisten Benutzer die Websites beschleunigen konnten (mithilfe von Telligents Community Server), indem sie die Datenbank auf demselben Computer wie die Website bereitstellten. Im Fall der Kunden sind jedoch in der Regel die db & web-Server die einzigen Anwendungen auf diesem Computer, und die Website belastet den Computer nicht so sehr. Die Effizienz, keine Daten über das Netzwerk senden zu müssen, machte die erhöhte Belastung dann wieder wett.

21
James Curran

Da hat Tom recht. Einige andere Gründe sind, dass es nicht kosteneffektiv ist und dass es zusätzliche Sicherheitsrisiken gibt.

Webserver haben andere Hardwareanforderungen als Datenbankserver. Datenbankserver schneiden mit viel Arbeitsspeicher und einem wirklich schnellen Festplattenarray besser ab, während Webserver nur genügend Arbeitsspeicher zum Zwischenspeichern von Dateien und häufigen Datenbankanforderungen benötigen (abhängig von Ihrer Konfiguration). In Bezug auf die Kosteneffizienz sind die beiden Server nicht unbedingt günstiger, das Verhältnis von Leistung zu Kosten sollte jedoch höher sein, da nicht unterschiedliche Anwendungen um Ressourcen konkurrieren müssen. Aus diesem Grund müssen Sie wahrscheinlich viel mehr für einen Server ausgeben, der für beide Systeme geeignet ist und eine Leistung bietet, die der von zwei spezialisierten Servern entspricht.

Die Sicherheitsbedenken bestehen darin, dass sowohl der Webserver als auch die Datenbank anfällig sind, wenn der einzelne Computer kompromittiert wird. Mit zwei Servern haben Sie eine gewisse Atempause, da der zweite Server (zumindest für eine Weile) noch sicher ist.

Es gibt auch einige Vorteile in Bezug auf die Skalierbarkeit, da Sie möglicherweise nur einige Datenbankserver warten müssen, die von einer Reihe verschiedener Webanwendungen verwendet werden. Auf diese Weise müssen Sie weniger Upgrades oder Patches installieren und die Leistung optimieren. Ich glaube, dass es Server-Management-Tools gibt, die diese Aufgaben vereinfachen (im Einzelfall).

14
Dana the Sane

Ich würde denken, der große Faktor wäre die Leistung. Sowohl der Webserver-/App-Code als auch SQL Server würden häufig angeforderte Daten im Speicher zwischenspeichern, und Sie können Ihre Cache-Leistung beeinträchtigen, indem Sie sie im selben Speicherbereich ausführen.

13
Tom Ritter

Sicherheit ist ein wichtiges Anliegen. Im Idealfall befindet sich Ihr Datenbankserver hinter einer Firewall, in der nur die für den Datenzugriff erforderlichen Ports geöffnet sind. Ihre Webanwendung sollte eine Verbindung zum Datenbankserver mit einem SQL-Konto herstellen, das nur über ausreichende Berechtigungen für die Funktion der Anwendung verfügt und nicht mehr. Sie sollten beispielsweise Rechte entfernen, die das Löschen von Objekten ermöglichen, und Sie sollten mit Sicherheit keine Verbindung mit Konten wie "sa" herstellen.

Für den Fall, dass Sie den Webserver durch einen Hijack verlieren (dh eine vollständige Ausweitung der Rechte auf Administratorrechte), besteht das schlimmste Szenario darin, dass die Datenbank Ihrer Anwendung gefährdet ist, jedoch nicht der gesamte Datenbankserver (wie dies der Fall wäre) Datenbankserver und Webserver waren derselbe Rechner). Wenn Sie Ihre Datenbankverbindungszeichenfolgen verschlüsselt haben und der Hacker nicht geschickt genug ist, um sie zu entschlüsseln, ist alles, was Sie verloren haben, der Webserver.

9
Kev

Ein Faktor, der noch nicht erwähnt wurde, ist der Lastausgleich. Wenn Sie anfangen, den Webserver und die Datenbank als separate Maschinen zu betrachten, optimieren Sie für weniger Netzwerk-Roundtrips und es wird auch einfacher, einen zweiten Webserver oder eine zweite Datenbank-Engine hinzuzufügen, wenn der Bedarf steigt.

8
Paul Tomblin

Ich kann aus eigener Erfahrung sagen, dass es oft eine gute Idee ist, den Webserver und die Datenbank auf verschiedenen Computern zu platzieren. Wenn Sie über eine ressourcenintensive Anwendung verfügen, können die CPU-Zyklen auf dem Computer leicht zu Spitzenwerten führen und den Computer im Wesentlichen zum Stillstand bringen. Wenn Ihre Anwendung die Datenbank jedoch nur eingeschränkt nutzt, ist es wahrscheinlich keine große Sache, wenn sie einen Server gemeinsam nutzen.

6
Mr. Will

Wow, niemand bringt die Tatsache zur Sprache, dass Sie den SQL-Server, wenn Sie ihn tatsächlich für 5.000 Dollar kaufen, möglicherweise für mehr als Ihre Webanwendung verwenden möchten. Wenn Sie Express verwenden, ist es Ihnen vielleicht egal. Ich sehe, dass SQL Server Datenbanken für 20 bis 30 Anwendungen ausführen, daher wäre es nicht klug, sie auf den Webserver zu stellen.

Zweitens, hängt davon ab, für wen der Server ist. Ich arbeite für Finanzunternehmen und die Regierung. Wir haben also den wahnsinnigen Ärger, nur Sprocs zu verwenden und die Ports vom Webserver auf SQL zu beschränken. Also, wenn die Web-App gehackt wird. Der Hacker kann nur Sprocs aufrufen, da das Benutzerkonto auf dem Webserver gesperrt ist, um nur Sprocs in der Datenbank anzuzeigen/aufzurufen. Nun muss der Hacker herausfinden, wie er in die DB kommt. Wenn es auf dem Webserver ist, ist es leicht zu erreichen.

5
Jojo

Ich stimme Daniel Earwicker zu - die Sicherheitsfrage ist ziemlich fehlerhaft.

Wenn Sie ein Single-Box-Setup mit einem Webserver und nur der Datenbank für diesen Webserver verwenden und dieser Webserver gefährdet ist, verlieren Sie sowohl den Webserver als auch nur die Datenbank für diese bestimmte Anwendung.

Dies ist genau das gleiche, was passiert, wenn Sie den Webserver bei einem 2-Server-Setup verlieren. Sie verlieren den Webserver und nur die Datenbank für diese bestimmte Anwendung.

Das Argument, dass bei einer Konfiguration mit zwei Servern der Rest der Integrität des DB-Servers erhalten bleibt, ist irrelevant, da im ersten Szenario auch jeder andere Datenbankserver, der sich auf eine andere Anwendung bezieht (sofern vorhanden), davon nicht betroffen ist - so wie sie sind, woanders untergebracht sein.

Ähnlich wie bei der Frage von Kev ', was ist mit all den anderen Datenbanken auf dem DB-Server? Sie haben nur eine Datenbank verloren. '

  • wenn Sie eine Anwendung und eine Datenbank auf einem Server hosten würden, würden Sie nur Datenbanken auf diesem Server hosten, die sich auf diese Anwendung beziehen. Aus diesem Grund würden Sie in einem einzelnen Server-Setup im Vergleich zu einem Mehrserver-Setup keine zusätzlichen Datenbanken verlieren.

Im Gegensatz dazu können bei einer Konfiguration mit zwei Servern, bei der der Angreifer Zugriff auf den Webserver und über einen Proxy eingeschränkte Rechte (im besten Fall) für den Datenbankserver hatte, die Datenbanken aller anderen Anwendungen gefährdet werden, wenn sie übertragen werden langsame, speicherintensive Abfragen ausführen oder den verfügbaren Speicherplatz auf dem Datenbankserver maximieren. Indem Sie die Anwendungen ähnlich wie bei der Virtualisierung in ihre eigenen Belange aufteilen, isolieren Sie sie auch zu Sicherheitszwecken auf positive Weise.

5
Oriental

Das hängt von der Anwendung und dem Zweck ab. Wenn hohe Verfügbarkeit und Leistung nicht kritisch sind, ist es nicht schlecht, die Datenbank und den Webserver nicht zu trennen. Insbesondere in Anbetracht des Leistungsgewinns: Wenn die Anwendung eine große Anzahl von Datenbankabfragen durchführt, kann eine erhebliche Netzwerklast vermieden werden, indem alle auf demselben System ausgeführt werden und die Antwortzeiten niedrig gehalten werden.

3
simon

Ich denke, das liegt daran, dass die beiden Maschinen normalerweise auf unterschiedliche Weise optimiert werden müssen. Abgesehen davon habe ich keine Ahnung, dass wir alle unsere Anwendungen mit der Server-Datenbank auf demselben Computer ausführen - vorausgesetzt, wir sind nicht öffentlich -, aber wir hatten keine Probleme.

Ich kann mir nicht vorstellen, dass sich zu viele Leute darum kümmern, dass ein Rechner über beide hinweg kompromittiert wird, da die Webanwendung normalerweise fast uneingeschränkten Zugriff auf zumindest die Daten hat, wenn nicht das Schema in der Datenbank.

Interessiert an dem, was andere sagen könnten.

2
George Mauer

Ich habe mir diesen Podcast angehört und es war amüsant, aber das Sicherheitsargument ergab für mich keinen Sinn. Wenn Sie Server A kompromittiert haben und dieser Server auf Daten auf Server B zugreifen kann, haben Sie sofort Zugriff auf die Daten auf Server B.

2

Datenbanklizenzen sind nicht billig und werden häufig pro CPU berechnet. Durch die Trennung Ihrer Webserver können Sie die Kosten für Ihre Datenbanklizenzen senken.

Zum Beispiel, wenn Sie 1 Server haben, der sowohl das Web als auch die Datenbank betreibt und 8 CPUs enthält, müssen Sie für eine 8-CPU-Lizenz bezahlen. Wenn Sie jedoch zwei Server mit jeweils 4 CPUs haben und die Datenbank auf einem Server ausführen, müssen Sie nur für 4-CPU-Lizenzen bezahlen

2
Ian Ringrose

Ein weiteres Problem ist, dass Datenbanken gerne den gesamten verfügbaren Speicherplatz in Anspruch nehmen und für die Zeit reservieren, in der sie ihn nutzen möchten. Sie können erzwingen, dass der Speicher begrenzt wird, dies kann jedoch den Datenzugriff erheblich verlangsamen.

1
HLGEM