Прокси-серверы

5.3.5 Обратные прокси

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

Обратные прокси имеют много общего кода с пересылающими прокси: фактически одни и те же продукты могут быть сконфигурированы одним или другим образом либо двумя сразу! Однако с функциональной и практической точки зрения в нашем случае мы рассматриваем обратные прокси как полностью другой инструмент.

Обратные прокси и прозрачность

Обратные прокси прозрачны, отчасти по определению. За обратным прокси пользователь вообще не знает о своем общении с прокси-сервером. Пользователь полагает, что общается с реальным предметом – сервером, на котором находится контент.

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

Обратные прокси с кешем

Обратные прокси обычно избраны и реализованы в целях обеспечения изоляции контента и зон. Однако, вы можете также добавить в обратные прокси функциональные возможности по кешированию для обеспечения производительности заодно с преимуществами обеспечения безопасности.

Рис. 5.2. Типичный обратный прокси

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

Однако когда на обратном прокси разрешено кеширование, важным становится обеспечение его должной защиты. Весь контент, даже если он полностью статичен, продолжает нуждаться в защите. Вы же не хотите проснуться и обнаружить, что статическая и неконфиденциальная часть вашего Web-сайта была полностью уничтожена хакерами в кеше обратных прокси.

Обратные прокси с дополнительным обеспечением безопасности

Серверы безопасности – обратные прокси [Reverse Proxies Secure Servers (RPSS)] соединяют в одном блоке (или продукте) функции "чистых" обратных прокси и функции прокси обеспечения безопасности, которые были описаны ранее.

Зачастую такие продукты RPSS будут иметь в обратном прокси встраиваемый компонент, обрабатывающий запросы управления доступом и авторизации и объединенный с конечной системой управления доступом предприятия, которая фактически проверяет права пользователя или клиента на доступ и авторизацию. Этот встраиваемый компонент иногда называют лезвием ( blade^{1Термин "blade" ("лезвие") чаще применяется к специальным аппаратным серверным решениям, см., например, IBM Blade Center.} ). К примеру, в качестве решения для обеспечения безопасности на предприятии вы можете использовать IBM Tivoli Access Manager; но у вас есть выбор в том, какое лезвие использовать на уровне прокси (WebSeal или более "легкий" плагин, иногда называемый WebSeal-lite).

5.4 Обратные прокси и технологии Lotus

Большинство технологий на основе Lotus Domino поддерживали сценарии применения обратных прокси на протяжении многих лет. В настоящее время в качестве исключения поддержку обратных прокси получил только продукт Lotus Sametime. Более подробно он описан в следующем разделе.

Последующие требования обратных прокси к Domino должны быть рассмотрены для традиционных технологий на основе Lotus Domino (Notes/Domino, iNotes, QuickPlace и т. д.).

5.4.1 Анализ кеширования в Domino

Первым для кеширования следует принять во внимание то, что приложения, сайты и технологии на основе Domino могут быть очень динамичными по природе. Основываясь на этом, любая реализация обратного прокси с разрешенным кешированием должна принимать на обработку указания кеширования из заголовков HTTP. Это предотвратит кеширование динамического контента Domino тогда, когда он не должен подвергаться кешированию.

Кроме того, основными кешируемыми элементами, которые будут кешироваться обратными прокси с возможностями кеширования, являются изображения, файлы Java-класса и ресурсы изображений. К сожалению, Domino обрабатывает некоторые изображения способом, при котором большинство прокси-серверов не распознает их по умолчанию. Для обеспечения поддержки прокси-сервер должен быть сконфигурирован на распознавание двух элементов дизайна Domino как кешируемых элементов:

?OpenImageResource
?OpenElement&FieldElemFormat = gif URL

В IBM WebSphere Edge Server это выполняется посредством параметров настройки фактора последнего модифицирования ("Last Modified Factor").

5.4.2 HTTP-методы, необходимые Domino

Поддержка методов HTTP (HTTP Methods) большинством прокси-серверов позволяет вам определить типы запросов, обслуживаемые прокси-сервером. Существует несколько типов, которые включаются по умолчанию в большинстве прокси, но единственными необходимыми Domino для функционирования являются GET, HEAD и POST. Другие являются необязательными и могут представлять собой риск для безопасности.

5.4.3 Преобразования URL, необходимые Domino и продуктам на основе Domino

Существует возможность сконфигурировать правило прокси для типа реализации "передача всего", который будет поддерживать технологии на основе Domino. Фактически это может быть параметром по умолчанию для множества прокси-серверов.

requests for /* go to http://xxx.xxx.xxx.xxx/*

В этом случае правило определяет, что если запросу не соответствует никакое из правил набора по умолчанию, то прокси пересылает запрос запрашиваемому серверу вне зависимости от того, что было на сервере запрошено.

Несмотря на то что подобный шаг может быть достаточно простым, он является рискованным, так как разрешает прямой доступ к какому-либо ресурсу на сервере Domino, доступному посредством HTTP.

В качестве альтернативы для ограничения доступа только до уровня необходимой функциональности может быть определен специфический набор правил. К примеру, правила для обычной инфраструктуры Domino, использующей iNotes, будут выглядеть следующим образом:

requests for /mail* go to http://xxx.xxx.xxx.xxx/mail*
requests for /iNotes* go to http://xxx.xxx.xxx.xxx/iNotes*
requests for /inotes5* go to http://xxx.xxx.xxx.xxx/inotes5*
requests for /icons* go to http://xxx.xxx.xxx.xxx/icons*
requests for /domjava* go to http://xxx.xxx.xxx.xxx/domjava*
requests for /names.nsf go to http://xxx.xxx.xxx.xxx/names.nsf

При таких правилах обслуживается только контент в подкаталогах /mail*. Правила определены таким образом, что если сайт имеет множество почтовых подкаталогов (к примеру, /mail[1-3] ), то они включены. Если вы хотите ограничить доступ только к подмножеству из почтовых баз данных, переместите их в специальную папку, такую, как /pubmail/*.

Другие правила разрешают доступ для поддержки контента, необходимого для предоставления конечному пользователю практики работы с iNotes Web Access. Еще одним важным правилом, которое необходимо рассмотреть, является правило /names.nsf, используемое для аутентификации. Оно разрешает доступ из Интернета к Domino Directory, но не к контенту, который находится вне списка каталогов по умолчанию.

Результат построения URL-адресов со стороны Domino выглядит так. Когда пользователь посредством аутентификации сеанса входит в Domino, экран входа в систему по умолчанию отправляет запрос к /names.nsf?Login. Прокси-сервер согласовывает этот запрос и передает его Domino. Если, к примеру, пользователь пытается открыть вид групп (Groups) с помощью запросов /names.nsf/Groups?Openview или /names. nsf/85255ed5006cafef852556d4006ca21c?OpenView, то как запрос Domino, так и запрос прокси-сервера потерпят неудачу, потому что они не соответствуют правилу. Пользователь получит сообщение об ошибке 403, гласящее о запрещении доступа.