Это не идеальный вопрос для суперпользователя. Ошибка сервера, возможно, была бы лучшей целью для этого вопроса. Это сказал ...
На ваши вопросы нет конкретных ответов - доступно много разных вариантов для достижения каждого пункта. Я прежде всего отвечу тем, что я бы порекомендовал.
- TLS происходит там, где я его показал?
Выделенное устройство, такое как балансировщик нагрузки, - это то место, где я бы разгрузил TLS, да. Обычно здесь используется специальное оборудование, специально разработанное для ускорения TLS без использования более медленных циклов ЦП общего назначения. Централизация ваших TLS-сертификатов на таком устройстве также помогает в управлении сертификатами - или в случае проблем безопасности, таких как Heartbleed или POODLE, обеспечивает единую точку, где необходимо внести любые необходимые изменения безопасности, - вместо нескольких веб-серверов.
- В идеале у вас должно быть 2 или более балансировщика нагрузки, настроенных как активные / активные или активные / пассивные в конфигурации с высокой доступностью для переключения при отказе и избыточности.
- В случае Heartbleed, по крайней мере, некоторые из существенных балансировщиков нагрузки на рынке не были уязвимы - из-за использования собственного стека SSL / TLS вместо OpenSSL.
Если бы безопасность была для вас первостепенной, вы могли бы рассмотреть возможность туннелирования трафика между вашим балансировщиком нагрузки и веб-серверами в новом соединении TLS. Или не прерывайте TLS, а только перенаправляйте TCP-соединение на один или несколько веб-серверов. Однако выполнение любого из них в значительной степени отменяет любое из преимуществ, которые я упомянул выше. Кроме того, я надеюсь, что как ваши балансировщики нагрузки, так и веб-сервер (ы) (и их связь) будут находиться в безопасном центре обработки данных, где не требуется шифрованная связь. (Если эти устройства не защищены, все ставки в любом случае отключены.)
Смотрите также: https://security.stackexchange.com/questions/30403/should-ssl-be-terminated-at-a-load-balancer
- Где происходит перезапись URL и перенаправление?
Как вы упомянули, CDN была бы еще одной возможностью для этого - которую я иначе проигнорирую здесь.
Вы можете сделать это внутри балансировщика нагрузки или на веб-сервере. Я по умолчанию склонен делать большую часть этого на веб-сервере - особенно при использовании Apache HTTPD - поскольку вы просто не можете превзойти возможности и гибкость, предлагаемые mod_rewrite. Возможность хранить эти правила в текстовом файле, не зависящем от устройства, которым можно управлять с помощью источника в SVN и т.д., Также является дополнительным бонусом - тем более что правила, как правило, необходимо часто менять (учитывая их природу).
Я всегда буду сохранять любые переписывания и перенаправления, которые являются внутренними для сайта / домена, который вы размещаете на веб-сервере. В ограниченных случаях, когда URL-адреса внутри размещенного сайта необходимо перенаправить в другое место, а производительность - критическая проблема, я бы посмотрел на выполнение этой работы на балансировщике нагрузки.
- Следует ли разрешить / разрешить обработку статического содержимого на уровне балансировки нагрузки (который может находиться на отдельном сервере) или оно должно обрабатываться на уровне веб-сервера?
За редким исключением контент обслуживается веб-сервером, а не балансировщиком нагрузки. Здесь вы можете / должны сделать так, чтобы ваш веб-сервер настраивался на прямое обслуживание такого статического контента, а не на его отправку в PHP / Python / Tomcat / и т.д., Возможно, для более медленного обслуживания. Когда это возможно, используйте и настройте CDN, чтобы все это было выгружено в пограничной сети и даже не доходило до вашего балансировщика нагрузки.
Один аспект, который может быть немного сложным, - это аутентификация, авторизация и регистрация. В любой момент, когда вы выгружаете такой "статический" контент, ваши нижние уровни могут даже не знать, что такой контент обслуживается - не могут защитить его или даже отслеживать его доступ. Одна из возможностей здесь (если это проблема) заключается в использовании модели "централизованной аутентификации", когда верхний уровень может кэшировать контент, но все равно отправит запрос обратно на нижний уровень / источник с «If-Modified- С заголовка. Затем источник может проверить идентификатор сеанса / файлы cookie / и т.д. - и может либо ответить, например, "HTTP 403 Forbidden" или "HTTP 304 Not Modified" (возврат из кэша).
