Dies ist keine ideale Frage für Super User. Server Fault wäre wohl ein besseres Ziel für diese Frage gewesen. Das gesagt...
Es gibt keine konkreten Antworten auf Ihre Fragen - es gibt viele verschiedene Optionen, um jeden Punkt zu erreichen. Ich werde vor allem mit dem antworten, was ich empfehlen würde.
- Ist TLS dort, wo ich es gezeigt habe?
Ein dediziertes Gerät wie ein Load Balancer ist, bei dem ich TLS auslagern würde, ja. In der Regel haben Sie hier dedizierte Hardware, die speziell dafür ausgelegt ist, TLS zu beschleunigen, ohne langsamere allgemeine CPU-Zyklen zu verwenden. Die Zentralisierung Ihrer TLS-Zertifikate auf einem solchen Gerät hilft auch bei der Zertifikatsverwaltung - oder bietet bei Sicherheitsproblemen wie Heartbleed oder POODLE einen zentralen Punkt, an dem alle erforderlichen Sicherheitsänderungen vorgenommen werden müssen - und nicht mehrere Webserver.
- Idealerweise verfügen Sie über zwei oder mehr Load-Balancer, die in einer hoch verfügbaren Konfiguration für Failover und Redundanz aktiv / aktiv oder aktiv / passiv konfiguriert sind.
- Im Fall von Heartbleed waren zumindest einige der auf dem Markt befindlichen signifikanten Lastverteiler nicht anfällig - aufgrund der Verwendung eines nativen SSL / TLS-Stacks anstelle von OpenSSL.
Wenn Sicherheit für Sie von größter Bedeutung war, sollten Sie den Datenverkehr zwischen Ihrem Load Balancer und Ihren Webservern in einer neuen TLS-Verbindung tunneln. Beenden Sie alternativ das TLS nicht und leiten Sie die TCP-Verbindung nur an einen oder mehrere Ihrer Webserver weiter. Wenn Sie jedoch beides tun, werden die oben genannten Vorteile weitgehend rückgängig gemacht. Außerdem würde ich hoffentlich davon ausgehen, dass sowohl Ihre Load Balancer als auch Ihre Webserver (und deren Kommunikation) in einem sicheren Rechenzentrum enthalten sind, in dem keine verschlüsselte Kommunikation erforderlich ist. (Wenn diese Geräte nicht sicher sind, sind alle Wetten sowieso deaktiviert.)
Siehe auch: https://security.stackexchange.com/questions/30403/should-ssl-be-terminated-at-a-load-balancer
- Wo geschieht das Umschreiben und Weiterleiten von URLs?
Wie Sie bereits erwähnt haben, wäre ein CDN eine andere Möglichkeit dafür - die ich hier sonst ignorieren werde.
Sie können dies entweder innerhalb eines Lastenausgleichs oder auf dem Webserver tun. Ich neige dazu, das meiste davon innerhalb des Webservers zu tun - vor allem, wenn Sie Apache HTTPD verwenden -, da Sie einfach die Fähigkeiten und die Flexibilität nicht übertreffen können, die von angeboten werden mod_rewrite . Die Möglichkeit, diese Regeln in einer geräteunabhängigen Textdatei zu speichern, die in SVN usw. quellengesteuert werden kann, ist ebenfalls ein zusätzlicher Bonus - zumal die Regeln häufig (aufgrund ihrer Natur) häufig geändert werden müssen.
Ich würde immer alle Umschreibungen und Weiterleitungen behalten, die sich auf der Website / Domäne befinden, die Sie auf dem Webserver hosten. In eingeschränkten Fällen, in denen URLs innerhalb einer gehosteten Site an eine andere Stelle umgeleitet werden müssen und die Leistung ein kritisches Problem darstellt, würde ich mir diese Arbeit mit dem Load Balancer ansehen.
- Soll / kann ich statischen Inhalt auf der Lastverteilungsschicht (die sich auf einem separaten Server befinden kann) oder auf der Webserver-Ebene behandeln lassen?
In seltenen Ausnahmefällen werden Inhalte von einem Webserver und nicht von einem Lastverteiler bereitgestellt. Was Sie hier tun können / sollten, ist, Ihren Webserver so zu konfigurieren, dass er solche statischen Inhalte direkt bereitstellt - und ihn nicht an PHP / Python / Tomcat / usw. senden lässt, möglicherweise langsamer. Verwenden Sie nach Möglichkeit ein CDN, und konfigurieren Sie es so, dass all dies am Randnetzwerk entladen wird und nicht einmal Ihren Lastverteiler erreicht.
Ein Aspekt, der hier etwas kompliziert werden kann, ist die Authentifizierung, Autorisierung und Protokollierung. Wenn Sie solche "statischen" Inhalte auslagern, ist den unteren Ebenen möglicherweise nie bewusst, dass diese Inhalte bereitgestellt werden. Sie können sie nicht schützen oder deren Zugriff nicht verfolgen. Eine Möglichkeit hier (wenn dies ein Problem ist) ist die Verwendung eines "zentralisierten Authentifizierungsmodells", bei dem der Inhalt einer oberen Ebene zwischengespeichert werden kann, die Anforderung jedoch mit einem "If-Modified- Da "Header. Der Ursprung kann dann die Sitzungs-ID / Cookies / etc. überprüfen - und hat die Möglichkeit, entweder mit "HTTP 403 Forbidden" oder "HTTP 304 Not Modified" (Rückgabe aus dem Cache) zu antworten.
