Share via

Не размещайте сервер клиентского доступа в пограничной сети!

  • Article

Иногда мы слышим, что заказчики говорят о размещении серверов клиентского доступа (Client Access Servers, CAS) Exchange 2007 или Exchange 2010 в пограничной сети (известной также как Demilitarized Zone, DMZ). Пограничная сеть – это сеть, которую многие компании размещают между Интернет и их внутренней сетью для усиления защиты. Идея пограничной сети состоит в том, что хакеру нужно будет сделать дополнительные шаги, чтобы получить доступ к внутренним ресурсам. Чтобы получить максимально возможную защиту, вам следует разместить на периметре только те серверы, которым вы доверяете прием на себя атак из Интернет, и затем вы должны допустить, что они могут быть, в конце концов, взломаны.

В случае Exchange 2000/2003 такой сценарий поддерживался, и существовала документация, объясняющая, как разместить фронтальный (front-end) сервер Exchange 2000/2003 сервер в пограничной сети с межсетевым экраном между фронтальными и тыловыми (back-end) серверами. Это приводит к тому, что некоторые заказчики, которые мигрируют с Exchange 2000/2003, ожидают такой же схемы работы от Exchange 2007/2010.

Как только вы начнете планировать размещение сервера клиентского доступа Exchange 2007/2010 в пограничной сети, вы быстро обнаружите, что документации о том, как это сделать, не существует. Возможно, вы даже найдете документацию TechNet, которая явно объясняет, что это не поддерживается  Microsoft. Microsoft не тестировала и не поддерживает любые топологии, в которых межсетевой экран размещается между серверами клиентского доступа и серверами почтовых ящиков. Единственная роль Exchange 2007/2010, которая поддерживается в пограничной сети с межсетевым экраном между ней и другими серверами Exchange – это роль пограничного сервера (Edge Transport). Причем это верно как для серверов Exchange внутри одного сайта, так и в случае, когда серверы в
разных сайтах Active Directory.

Тот факт, что отсутствует поддержка использования межсетевого экрана между серверами Exchange (за исключением роли пограничного сервера), иногда вызывает путаницу в том, как использовать Windows Server Firewall with Advanced Security на серверах Exchange 2007/2010. Включенный межсетевой экран Windows на серверах Exchange поддерживается. На самом деле мы настоятельно рекомендуем вам  оставлять встроенный межсетевой экран Windows включенным как меру усиления защиты. Программа установки Exchange 2010 достаточно умна, чтобы настроить межсетевой экран Windows так, чтобы пропускать трафик Exchange  надлежащим образом. Обратите внимание, что для  Exchange 2007 вам необходимо запускать мастер конфигурации безопасности (Security
Configuration Wizard) и применять основанный на ролях шаблон Exchange 2007. Подробные инструкции можно найти в документации по Exchange 2007 Using the Security Configuration Wizard (SCW) to Secure Windows for Exchange Server Roles.

Примечание: В Exchange 2010 не требуется использовать Security Configuration Wizard для того, чтобы открыть необходимые порты для ролей и сервисов, работающих на сервере Exchange 2010. Эти шаги по настройке включены в программу установки Exchange 2010, и мы не распространяем никакие шаблоны SCW для Exchange 2010.

Причины, почему мы не поддерживаем CAS в пограничной сети

При обсуждении того факта, что размещение сервера клиентского доступа в пограничной сети не поддерживается, следующий очевидный вопрос – "почему?". Если это поддерживалось и было документировано для фронтальных серверов Exchange 2000/2003, то почему это не так для серверов клиентского доступа Exchange 2007/2010?

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

Важно понимать, что роль сервера клиентского доступа в Exchange 2007/2010 существенно отличается от фронтального сервера в Exchange 2000/2003.

Фронтальные серверы Exchange 2000/2003 предназначались для аутентификации пользователей и передачи трафика к тыловым серверам, где этот трафик действительно обрабатывался. Например, фронтальные серверы в Exchange 2000/2003 не выполняли рендеринг Outlook Web Access (OWA). Это происходило на тыловых серверах. С другой стороны, роль сервера клиентского доступа Exchange 2007/2010 содержит весь промежуточный (middle-tier) код для процессов вроде OWA, Exchange ActiveSync (EAS), Exchange Web Services (EWS) и других.

После выхода  Exchange 2007 многоие заказчики начали использовать обратное проксирование (т.е. Internet Security and Acceleration server (ISA) 2000 FP1, 2004 или 2006) с предварительной аутентификацией. Это означало, что существует хороший способ аутентификации трафика Exchange до того, как он достигнет серверов Exchange. Роль, которую фронтальный сервер Exchange 2000/2003 играл в усилении защиты путем предварительной аутентификации трафика до того, как он достигнет серверов, которые включают Exchange, могла бы теперь гораздо лучше
выполняться этими новыми серверами обратного проксирования. Вот причины, по которым обратный прокси делает работу по усилению защиты лучше, чем фронтальные серверы / серверы клиентского доступа Exchange:

  • Серверы клиентского доступа Exchange требуют полного доступа ко всем почтовых ящикам в сайте AD и значительные права доступа в AD. Это тот уровень привилегий, который вы должны
    избегать от передачи в пограничную сеть.
  • Фронтальный сервер Exchangeвыполнял минимум бизнес-логики Exchange, а сервер клиентского доступа Exchange выполняет много бизнес-логики Exchange. Чем больше логики вы размещаете в пограничной сети, тем больше риска, что это логика будет взломана. Для серверов, которые вы размещаете в сети периметра, вы захотите минимизировать объемы логики/кода, которые они исполняют, и которые являются областью атаки извне. Главная задача обратных прокси как раз в том, чтобы выдерживать подобные атаки из Интернет. Хотя серверы Exchange также крепки с точки зрения безопасности, но они несут гораздо больше логики, чем обратные прокси, что увеличивает риск.
  • Обратные прокси создаются для размещения в пограничной сети или на ее границе. Они включают множество функций усиления безопасности для заказчиков, определяя высокий уровень безопасности, который оправдан в любой пограничной сети. Некоторые из этих функций усиления безопасности легко использовать (например, использование предварительной аутентификации, когда ваш обратный прокси является членом домена Active Directory; или исключение членства в домене Active Directory и ограничение возможностей предварительной аутентификации), тогда как другие функции усиления защиты требуют большей работы (например, использование предварительной аутентификации без домена с помощью RADIUS). Но главное различие между обратным прокси и сервером клиентского доступа заключается в том, что обратные прокси имеют намного больше функций усиления защиты и схем развертывания, чем сервер клиентского доступа Exchange.

Помимо этих причин, по которым обратный прокси работает в пограничной сети лучше, чем фронтальный сервер / сервер клиентского доступа Exchange, существует также проблема с фронтальным сервером / сервером клиентского доступа, расположенном на периметре, которая исчезает при использовании обратного прокси. Размещение фронтального сервера E2000/2003 в пограничной сети было сложной задачей. Настройки портов и другие требуемые настройки межсетевого экрана были сложными, и многие испытывали проблемы в корректном выполнении этих настроек. Различные типы
внутренних межсетевых экранов требовали различных настроек, и если что-то было настроено неверно, то это было не всегда легко обнаружить по тем проблемам, которые испытывали клиенты в Интернет. Такая сложность и ошибки, которые она вызывала, были проблемой для заказчиков Exchange. Настройка внутреннего межсетевого экрана при использовании обратного прокси в пограничной сети намного проще. Вот почему мы не предлагаем "сервер клиентского доступа в пограничной сети" как поддерживаемое решение даже для тех заказчиков, которые хотят  принять на себя все вышеперечисленные риски: люди могут свернуть себе шею, когда попытаются настроить такие вещи, как фронтальный сервер / сервер клиентского доступа в пограничной сети.

Если вам интересно, то используемые между серверами E2007 порты описаны в Exchange Network Port Reference.

Заключение

Лучший способ для развертывания сервера клиентского доступа в пограничной зоне – это использовать в пограничной зоне обратный прокси, которому вы доверяете, настроить межсетевой экран между периметром и интранет с как можно более жесткими ограничениями и разместить сервер клиентского доступа сервер во внутренней сети. Это позволит инспектировать трафик и выполнять другие проверки безопасности на обратном прокси прямо в пограничной сети.

В качестве экстра-защиты вы можете настроить предварительную аутентификацию на обратном прокси. Это возможно не для всех протоколов Exchange, если вы захотите получить некоторые расширенные функции вроде Exchange 2010 Federated Free/Busy и Calendar Sharing. Подробности смотрите в Общих сведения хо федерации (Understanding Federation) и Общих сведениях о федеративном общем доступе (Understanding Federated Delegation). Но вы можете настроить предварительную аутентификацию для тех клиентов и протоколов, которые поддерживаются вашим обратным прокси и сценариями, которые вы ходите разрешить.

С уважением,

Кристиан Андакер, Джейсон Хендерсон

Перевод: Илья Сазонов, MVP

Comments

  • Anonymous
    August 01, 2013
    Актуально ли это для Exchange 2013?