Стратегия связывания SSL в приложениях

Question

Мне интересно услышать, что делают другие, когда в определенном приложении некоторые страницы должны быть защищены, а другие нет. Возьмите любое решение со стола, для которого требуется отдельный домен / поддомен. В этом случае все звонки, безопасные или небезопасные, будут связаны с одним и тем же доменом. Я вижу несколько вариантов:

1. Хет-кулак, просто зафиксируй все подходы.
2. Решение для перезаписи URI, которое обеспечивает доступ к нужным страницам по протоколу https и либо игнорирует другие страницы, либо, наоборот, принудительно переводит их на стандартный http
3. Подход, ориентированный на приложения, где каждая ссылка отвечает за знание того, указывает ли она и применяет ли правильный протокол. В этом решении все ссылки должны быть полностью квалифицированы.
4. Правдоподобная версия подхода, ориентированного на приложения, в котором ссылки на защищенные страницы полностью определены, а ссылки на другие страницы - нет. В этом случае протокол будет унаследован для страниц, которые не обрабатываются явно, и несущественные страницы могут быть доступны через https.

Время от времени я использовал несколько из них, но все они имеют недостатки. Что все остальные делают в этих ситуациях? Есть ли другой путь, который я не рассмотрел?

UPDATE:

Ответ vartec, приведенный ниже, заставил меня осознать, что я упустил одну важную информацию. В моем сетевом конфиге вся SSL-обработка выполняется на уровне балансировки нагрузки. Таким образом, LB связывается с кластером веб-серверов через порт 80. В результате сами приложения не имеют представления о том, поступил ли трафик безопасно. Все, что они видят, это соединение с портом 80.

Спасибо.

Answer 1

Я за самый надежный подход к безопасности всего этого, но затем вы сняли мое реальное решение со стола, что (как ни странно) исключает решения для доменов / поддоменов. Ошибки в защите сайта гораздо более опасны, чем незначительные накладные расходы на обработку.

У нас есть наш основной сайт, который небезопасен (но в основном маркетинг), а затем у нас есть сайт приложений, который является другим поддоменом. Просто, легко и эффективно. Зачем снимать эту опцию со стола?

Answer 2

Подход, ориентированный на приложения, когда контроллер для каждой страницы знает, должна ли она быть защищенной. Если он должен быть безопасным, но доступ к нему осуществляется через небезопасный http, перенаправьте его на https, передав все параметры.

Answer 3

Я использую смесь № 4 и № 2: стараюсь указывать абсолютные URL-адреса, где это возможно, когда мне нужно переключать протоколы, и реализую перенаправление на стороне сервера, чтобы перехватывать любые ссылки, на которых я не использовал абсолютные URL-адреса (или если доступ к URL-адресу напрямую, а не по ссылке).

На мой взгляд, одна важная вещь заключается в том, что страницы, к которым требуется безопасный доступ (отправка форм и т. Д.), Доступны безопасно, и для этого я использую директиву Apache SSLRequireSSL. Это позволяет легко убедиться, что к определенным страницам никогда не будет никакого доступа, кроме как по SSL.