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. Normalerweise haben Sie hier dedizierte Hardware, die speziell für die Beschleunigung von TLS entwickelt wurde, 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 - anstelle von mehreren Webservern.
- 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 für Sie die Sicherheit 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 erneute Schreiben und Umleiten 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 Load Balancer oder auf dem Webserver tun. Ich neige dazu, das meiste davon auf dem Webserver zu tun - vor allem, wenn Sie Apache HTTPD verwenden -, da Sie die von mod_rewrite gebotenen Fähigkeiten und Flexibilität einfach nicht übertreffen können . 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 beibehalten, 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 Webserverebene 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, um möglicherweise langsamer zu arbeiten. Verwenden Sie nach Möglichkeit ein CDN, und konfigurieren Sie es so, dass all dies am Edge-Netzwerk abladen und Ihren Load Balancer nicht erreichen kann.
Ein Aspekt, der hier etwas knifflig 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 (wenn dies ein Problem ist) ist die Verwendung eines "zentralisierten Authentifizierungsmodells" - bei dem der Inhalt einer oberen Ebene zwischengespeichert wird, 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.