Защита серверов клиентского доступа Exchange

Ворганизации Exchange Server 2010 все клиенты электронной почты обращаются к серверу клиентского доступа. Поскольку пользователи непосредственно взаимодействуют с этим сервером через Интернет, он может стать мишенью для злоумышленников. Поэтому обеспечение безопасности сервера клиентского доступа имеет первостепенное значение. В ранее опубликованных статьях я подробно рассказывал о различных аспектах роли сервера клиентского доступа, а также разъяснил, как осуществляется развертывание и балансировка нагрузки таких серверов. На этот раз я остановлюсь на том, как обеспечивается безопасность сервера клиентского доступа. Термин «безопасность» понимают по-разному. Мы часто исходим из того, что безопасность — понятие неоднозначное, и применяется оно для обозначения того, сколь жестко ограничен доступ к тому или иному серверу. Но когда ставится вопрос о безопасности серверов клиентского доступа, нужно иметь в виду, что уровень их защиты можно существенно повысить с помощью трех перечисленных ниже мер.

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

Использование сертификатов для внешних служб

К данным, хранящимся на серверах клиентского доступа, клиенты обращаются различными способами. Если речь идет о сообщениях электронной почты, они могут подключаться с помощью таких программных средств, как Outlook Web App (OWA), ActiveSync, Outlook Anywhere, Exchange Web Services (EWS), POP, IMAP, или через интерфейс MAPI на клиенте Outlook. Все эти методики и протоколы, если не считать интерфейса MAPI на клиенте Outlook, были разработаны специально для использования в общедоступной среде Интернет. Поэтому необходимо проследить за тем, чтобы данные, передаваемые по каналам Интернета, не могли стать добычей злоумышленников, которые могут попытаться перехватить проходящие по сети пакеты. В системе Exchange предусмотрена возможность решения этой задачи путем шифрования маршрутизируемых в Интернет соединений с помощью сертификатов SSL.

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

Первый шаг, который необходимо сделать для обеспечения безопасности передачи данных, сводится к получению сертификата для серверов клиентского доступа. Когда мы устанавливаем сервер клиентского доступа, сертификат с собственной подписью создается по умолчанию. Этот сертификат генерируется непосредственно сервером клиентского доступа. Но при его использовании возникает одна проблема: клиенты не доверяют этому сертификату. Если сервер клиентского доступа использует самостоятельно подписанный сертификат и вы пытаетесь обратиться к клиенту OWA, система выдаст сообщение об ошибке, подобное тому, которое показано на экране 1. Это необязательно означает, что сервер клиентского доступа скомпрометирован; просто клиенты не доверяют издателю сертификата (то есть серверу клиентского доступа). Если вы добавите самостоятельно подписанный сертификат к списку надежных издателей на клиенте, проблема будет решена. Однако такое решение непросто реализовать в распределенных средах. Это в первую очередь касается среды Exchange Server 2007, поскольку в ней самостоятельно подписанный сертификат по умолчанию сохраняет силу только на протяжении года. По истечении этого срока сертификат приходится возобновлять и распределять повторно. В системе Exchange 2010 срок действия сертификата увеличен до пяти лет. Но, как бы то ни было, самостоятельно подписанные сертификаты нельзя признать идеальным решением.

Экран 1. Сообщение об ошибке в сертификате безопасности

Удобнее работать с сертификатом, полученным от удостоверяющего центра Certificate Authority (CA), признаваемым обеими сторонами. Идея состоит в том, что как сервер клиентского доступа, так и клиент доверяют такому сертификату; обе стороны считают, что сертификат имеет силу. Подобные сертификаты вы можете получить в собственном удостоверяющем центре или приобрести у стороннего производителя, такого как DigiCert, VeriSign, Entrust или GoDaddy.

Серверы клиентского доступа могут вступать во взаимодействие под множеством различных имен. Вам нужно позаботиться о том, чтобы все имена, по которым к серверу будут обращаться, были внесены в сертификат при его получении. В противном случае сервер не сможет пройти проверку идентичности. Два типа сертификатов позволяют указывать для сервера более одного имени: это сертификат на дополнительное имя субъекта Subject Alternative Name (SAN) и групповой сертификат (Wildcard).

Сертификаты типа Wildcard могут стоить дорого, но они позволяют задействовать любые дополнительные имена субъекта. Так что любое имя, с использованием которого можно обращаться к серверу, считается действительным. Сертификаты SAN дешевле и имеют более широкое распространение. Сертификат SAN позволяет указывать первичное имя сервера в поле SubjectName, а альтернативные имена — в поле Subject Alternative Name, как показано на экране 2.

Экран 2. Альтернативные имена SAN-сертификата

Для получения сертификата необходимо сгенерировать файл запроса сертификата на сервере Exchange и передать этот файл удостоверяющему центру, который выдаст вам требуемый сертификат. При создании файла запроса генерируется содержащая ключ часть сертификата, после чего эта часть сохраняется на сервере, сформировавшем запрос. Таким образом обеспечивается защита секретного ключа: его не нужно передавать удостоверяющему центру, так что единственной стороной, располагающей данным ключом, является собственно сервер. В системе Exchange 2010 этот запрос на получение сертификата можно сгенерировать одним из двух способов: с помощью мастера New Exchange Certificate wizard консоли управления Exchange Management Console (EMC) или с использованием командной консоли Exchange Management Shell (EMS), где нужно ввести команду New-ExchangeCertificate.

Чтобы запустить мастер New Exchange Certificate в консоли EMC, укажите на сервер клиентского доступа, для которого вы будете запрашивать сертификат, и выберите в контекстном меню пункт New Exchange Certificate, как показано на экране 3. В окне мастера New Exchange Certificate вы можете запросить сертификаты для некоторых или для всех служб, выполняемых на сервере клиентского доступа, как показано на экране 4.

Экран 3. Запуск мастера New Exchange Certificate wizard из консоли EMC

Экран 4. Запрос сертификатов для отдельных служб, выполняемых на сервере клиентского доступа

Завершив этот процесс, вы получите файл запроса на сертификат, который можно будет передать удостоверяющему центру. Центр использует этот файл при формировании сертификата. Получив сертификат из центра, вы должны будете завершить процесс, импортировав сертификат в систему Exchange. Для этого нужно запустить консоль EMC и выделить запрос на сертификат, который вы создали для сервера клиентского доступа. Выберите запрос Complete Pending Request, как показано на экране 5; тем самым вы передадите сертификат системе Exchange и активируете его.

Экран 5. Завершение подготовки запроса на сертификат

Мне часто задают вопрос: а можно ли использовать один и тот же сертификат на всех серверах клиентского доступа? К примеру, в массиве серверов клиентского доступа доступ к каждому серверу осуществляется с использованием одного и того же внешнего имени, а раз так, нельзя ли импортировать один и тот же сертификат на каждый сервер или каждому серверу требуется отдельный сертификат? Ответ на этот вопрос зависит от нескольких факторов. Если вы покупаете сертификат в центре, пользующемся всеобщим доверием, таком как Thawte, вам придется платить за каждый сертификат, который вы хотите установить на каждом сервере клиентского доступа. Но если вы работаете с внутренним центром сертификации, юридическое обязательство применять несколько сертификатов вас не связывает. В этом случае вы можете использовать один групповой сертификат. В типичных сертификатах Exchange часто указывается несколько дополнительных имен субъектов, так что, если вы устанавливаете один и тот же сертификат на нескольких серверах клиентского доступа, проследите, чтобы действующие имена для каждого сервера были внесены в поле Subject Alternative Name.

Усиление защиты операционной системы сервера

Усиление защиты сервера предполагает удаление несущественных служб и процессов, которые могли бы образовать брешь в его защите. Даже если о каких-либо уязвимостях на сегодня ничего не известно, имейте в виду, что простым отключением неиспользуемых компонентов вы повышаете уровень защиты системы в том случае, если брешь будет обнаружена в дальнейшем. В комплект поставки Exchange 2007 входят шаблоны, которые мастер Windows Security Configuration Wizard (SCW) может использовать для повышения уровня защищенности Exchange путем отключения одной роли за другой. В версии Exchange 2010 подобные шаблоны не применяются, поскольку каждая роль защищается от нежелательных вторжений по умолчанию. Впрочем, это не значит, что функциональность операционной системы ограничивается. К числу базовых мер, которые вы можете принять для усиления защиты системы Windows Server 2008 R2 или Server 2008, относятся следующие:

разработка структуры организационной единицы (OU) для использования политик на основе ролей;
реализация политик безопасности, указанных в настройках Enterprise Client (EC) или в настройках Specialized Security — Limited Functionality (SSLF);
аудит журналов безопасности на сервере.

Основной метод усиления защиты серверов клиентского доступа состоит в использовании объектов групповой политики (GPO) с целью реализации политик на серверах. Для обеспечения эффективности данного процесса необходимо настроить структуру OU таким образом, чтобы вы могли повысить уровень защиты серверов Exchange с помощью единой политики, а затем укреплять безопасность индивидуальных серверов в зависимости от их ролей. Используя этот метод принудительного применения GPO, вы защищаете роль клиентского доступа независимо от других серверных ролей. Так, вы можете отключить службу POP или IMAP для всех серверов Exchange, но активировать ее для серверов клиентского доступа. На рисунке 1 показано, как работает эта методика применения объектов групповых политик. Дополнительные сведения по этой теме можно найти в статье TechNet «Designing OU Structures that Work» (technet.microsoft.com/en-us/magazine/2008.05.oudesign.aspx).

Рисунок 1. Использование объектов GPO для усиления защиты серверов клиентского доступа

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

Базовые показатели Enterprise Client (EC) включают в себя ряд надежных и получивших широкое распространение настроек безопасности. Название Enterprise Client не должно вводить вас в заблуждение: эти базовые показатели применимы не только к клиентским операционным системам, но и к Windows Server 2003, а также к более новым версиям рядовых серверов. Настройки безопасности базовых показателей EC предполагают отключение гостевых учетных записей и кэшированных учетных данных.

Набор базовых показателей Specialized Security — Limited Functionality (SSLF) предусматривает высокий уровень защиты за счет ограничения функциональности системы. Недаром в его названии присутствуют слова limited functionality. В базовых показателях SSLF идея защиты сервера, что называется, доведена до крайности; вполне возможно, что вам придется доискиваться до причин возникающих проблем и возвращаться к настройкам, действовавшим до применения политики базовых показателей. При использовании показателей SSLF мне самому доводилось сталкиваться с такими странными явлениями, как периодически возникающие отказы соединения с консолью EMC.

Для защиты серверов Exchange я рекомендую читателям применять базовые показатели EC, а не SSLF. Упомянутые базовые показатели, а также документацию для реализации настроек можно загрузить по адресу technet.microsoft.com/en-us/library/cc677002.aspx. Эти материалы входят в комплект поставки диспетчера Microsoft Security Compliance Manager.

И последнее замечание, касающееся усиления защиты операционной системы: следите за генерируемыми журналами аудита. Если вы начнете пользоваться рекомендованными мной базовыми показателями, настройка аудита безопасности будет осуществляться на сервере. Но надо иметь в виду, что настройка аудита — всего лишь первый шаг. Кроме того, вам нужно будет избрать метод регулярного мониторинга журналов аудита с целью выявления попыток вторжения. Существует множество инструментальных средств, предназначенных для консолидирования журналов аудита безопасности серверов. Из виденных мною инструментов наибольшей популярностью пользуются службы Audit Collection Services (ACS) диспетчера Microsoft System Center Operations Manager, а также диспетчер NetIQ Security Manager. Каждый из этих продуктов оснащен уникальными средствами, но оба они ориентированы на выполнение одной и той же задачи — сбора данных из журналов безопасности и привлечения внимания администратора к ним.

Ограничение внешних воздействий с помощью обратного прокси-сервера

Возможно, самый важный аспект защиты серверов клиентского доступа состоит в том, чтобы заблокировать попытки их взлома людьми, не являющимися членами организации. Ограничить внешние воздействия на серверы клиентского доступа — значит расположить их внутри защищенной среды и в то же время сохранить возможность обращения к таким серверам со стороны уполномоченных на это пользователей по каналам Интернета. Указанная конфигурация является предпочтительной, но, кроме того, надо отметить, что Microsoft поддерживает только такую конфигурацию, в соответствии с которой серверы клиентского доступа не могут располагаться внутри демилитаризованной зоны (DMZ). Сервер клиентского доступа не публикуется непосредственно в Интернете. Вместо него во внешней сети публикуется обратный прокси-сервер, который в дальнейшем и обеспечивает связь с сервером клиентского доступа. На рисунке 2 показано, как действует эта схема.

Рисунок 2. Ограничение внешних воздействий на серверы клиентского доступа с помощью обратного прокси-сервера

На рынке представлено множество обратных прокси-серверов, в том числе разработанный корпорацией Microsoft Internet Security and Acceleration (ISA) Server, Forefront Threat Management Gateway (64 разрядный преемник системы TMG-ISA Server), Apache, Squid, различные версии Linux с возможностями жесткой блокировки, а также аппаратные устройства корпоративного класса, такие как BIG-IP компании F5. Каждый обратный прокси-сервер имеет свои достоинства и недостатки, но в основе всех этих продуктов лежит одна и та же концепция. Задача обратного прокси-сервера состоит в том, чтобы принимать или отвергать соединения, поступающие из Интернета, и передавать их обратно на сервер клиентского доступа. Обратный прокси-сервер может характеризоваться более или менее высоким «интеллектуальным уровнем»; это зависит от конкретного продукта. Некоторые изделия обеспечивают доступ на основании простых правил, тогда как другие обладают глубокими знаниями в том, что касается защищаемых ими приложений. Достоинство этих «более сообразительных» обратных прокси-серверов в том, что они «знают», какой трафик данное приложение готово (или не готово) принять; поэтому они блокируют ненадлежащим образом отформатированные запросы приложений, а также запросы, представляющие очевидные попытки взлома. В ходе настройки обратного прокси-сервера с целью защиты серверов клиентского доступа вы должны не упускать из виду несколько соображений, а именно: каким образом осуществляется процедура аутентификации, как организуется связь по протоколу SSL и будет ли обратный прокси-сервер использоваться в качестве балансировщика нагрузки.

Одно из достоинств обратного прокси-сервера — его способность выполнять предварительную аутентификацию. Активируя функцию предварительной аутентификации, мы санкционируем проверку подлинности пользователя со стороны обратного прокси-сервера еще до того, как запрос будет передан обратно на сервер клиентского доступа. Аутентификация по-прежнему выполняется на сервере клиентского доступа, но вы можете делегировать эту процедуру таким образом, чтобы пользователю не приходилось повторно вводить свои учетные данные. К примеру, на обратном прокси-сервере вы можете реализовать аутентификацию на основе форм, а в виртуальном каталоге OWA на сервере клиентского доступа — аутентификацию с использованием HTML. В этом случае, когда пользователь обращается к OWA по каналам Интернета, система предлагает ему пройти проверку подлинности на основе форм в процессе предварительной аутентификации. Но когда к каталогу OWA непосредственно на сервере клиентского доступа обращается пользователь, находящийся в вашей внутренней сети, его учетные данные в формате NTLM передаются без промежуточных проверок, и этот пользователь не получает предложения пройти процедуру аутентификации. При планировании использования предварительной аутентификации важно помнить о том, что не все методы доступа к электронной почте допускают возможность проведения этой процедуры. Так, если вы затребуете предварительную аутентификацию для клиентов Outlook Anywhere, они не будут устанавливать соединение, ибо Outlook не знает, как обрабатывать запрос на предварительную аутентификацию. Далее, если вы используете функции федеративного общего доступа системы Exchange 2010, вам нужно исключить из настроек предварительной аутентификации следующие маршруты:

/EWS/exchange.asmx/wssecurity
/autodiscover/autodiscover.svc
/autodiscover/autodiscover.svc/wssecurity

Если вы намереваетесь применять процедуру предварительной аутентификации, важно прежде всего иметь в виду следующее: эту процедуру целесообразно использовать в ситуациях, когда обращение к электронной почте осуществляется через браузер, как в случае с веб-клиентом Outlook и панелью управления Exchange Control Panel (ECP). При необходимости установить соединение с использованием протокола SSL в вашем распоряжении, как правило, оказывается несколько вариантов в зависимости от используемого обратного прокси-сервера. В большинстве случаев это следующие варианты.

Базовый брандмауэр: поддерживать все то же соединение SSL между клиентом и сервером клиентского доступа.
Разгрузка SSL: разорвать соединение SSL на обратном прокси-сервере и использовать соединение без шифрования данных с обратного прокси-сервера на сервер клиентского доступа.
Мост SSL: разорвать соединение SSL на обратном прокси-сервере и установить новое соединение SSL с обратного прокси-сервера на сервер клиентского доступа.

Каждый из перечисленных вариантов имеет свои достоинства. В первом случае обратный прокси-сервер действует подобно базовому брандмауэру и просто передает соединение непосредственно серверу клиентского доступа; эта процедура в чем-то подобна операции перенаправления портов. В большинстве случаев данный метод обеспечивает самый низкий уровень защиты, так как обратный прокси-сервер не осуществляет проверки контента. Второй вариант, разгрузка SSL, позволяет клиенту установить соединение SSL с обратным прокси-сервером, но данные, передаваемые с обратного прокси-сервера на сервер клиентского доступа, не шифруются. Достоинство этого метода в том, что, поскольку дешифрование и верификацию данных, поступающих по соединению SSL, осуществляет обратный прокси-сервер, серверу клиентского доступа не приходится этим заниматься. Третий вариант, мост SSL, — самый безопасный. При его использовании соединение прерывается на обратном прокси-сервере, так что этот сервер может осуществлять проверку. Затем обратный прокси-сервер повторно устанавливает новое соединение SSL с сервером клиентского доступа, чтобы обмен данными в ходе сеанса по-прежнему осуществлялся в зашифрованном виде. В этом варианте разрыв соединения SSL для клиента происходит на обратном прокси-сервере, а разрыв соединения SSL для обратного прокси-сервера осуществляется на сервере клиентского доступа, как показано на рисунке 3.

Рисунок 3. Мост SSL

Последнее соображение, которое следует принимать во внимание: намерены ли вы настраивать обратный прокси-сервер так, чтобы он выполнял функцию балансировщика нагрузки серверов клиентского доступа. Для предшествующих версий Exchange этот вариант подходил больше, чем для Exchange 2010, так как клиенты MAPI системы Exchange 2010 взаимодействуют с серверами клиентского доступа напрямую. Поэтому вам следует позаботиться о том, чтобы клиенты MAPI подключались не к отдельному серверу клиентского доступа, а к массиву серверов клиентского доступа с балансировкой нагрузки. Дополнительные сведения о балансировке нагрузки можно найти в статье «Серверная роль клиентского доступа Exchange Server: балансировка нагрузки серверов», опубликованной в Windows IT Pro/RE № 2 за 2011 год. Вы можете наладить функционирование такой схемы, но для этого придется приложить некоторые усилия. Вам нужно направлять соединения для внутренних пользователей через внешний интерфейс и обратно в сеть, а это означает необходимость дать санкцию на установление соединений RPC через обратный прокси-сервер, что трудно назвать удачным решением.

Не так уж все и сложно

Организация защиты серверов клиентского доступа — не столь трудная задача, как можно было подумать. Благодаря средствам безопасности, встроенным в систему Exchange 2010, процесс упрощается; вам остается только удостовериться в том, что вы располагаете нужными сертификатами, что серверная операционная система защищена, и использовать обратный прокси-сервер для защиты своих серверов от угроз, исходящих из Интернета.

Кен Сен-Сир (ken.stcyr@microsoft.com) — архитектор решений компании Microsoft с более чем 10 летним опытом работы. Имеет сертификат Microsoft Certified Master in Directory Services