Мобильные служащие создают для отделов ИТ особенные проблемы в плане безопасности. Удаленным пользователям необходим безопасный доступ к данным и службам, таким как электронная почта. К сожалению, самым
слабым звеном в цепи безопасности являются слабые пароли, вредоносное программное обеспечение (например, программы для кражи паролей) и вирусы, находящиеся на удаленных компьютерах, которые получают доступ к внутренним ресурсам вашей организации.
Одним из путей усиления безопасности в этой мобильной среде является удаление одного из этих слабых звеньев: паролей (хотя идея предоставления доступа без пароля, проверяющего подлинность, может показаться небезопасной). Основной метод для решения этих проблем, связанных с паролями, известен как двухфакторная проверка подлинности (или иногда как многофакторная проверка подлинности). Вместо того чтобы полагаться на единственный метод – пароль – для предоставления доступа, двухфакторная проверка подлинности подключает дополнительные методы проверки подлинности, включающие сочетание имени пользователя/пароля, физического устройства, например, смарт-карты, и биометрического идентификатора, такого как отпечаток пальца.
Если у вас есть удаленные пользователи, то обычно вам нужно чуть снизить уровень защиты вашего брандмауэра, чтобы разрешить удаленный доступ к вашей корпоративной сети. Стандартный брандмауэр предоставляет вам основные режимы снижения рисков при помощи изоляции на сетевом уровне между внутренними и внешними сетями (см. рис. 1). Для обеспечения дополнительной безопасности происходит закрытие портов, а если необходима связь с устройством во внутренней сети, порты переадресовываются в правильное место. Эти методы обеспечивают достаточную защиту на сетевом уровне, но вследствие появления все более изощренных атак сегодня необходимо применять многоуровневые методы сетевой безопасности.
Рис. 1 Стандартный брандмауэр с заблокированными или переадресованными портами
Поскольку наиболее часто используемыми мобильными служащими корпоративными службами являются электронная почта и обмен сообщениями, безопасная настройка вашей инфраструктуры Exchange становится все более важным делом. Предоставление вашим пользователям доступа через Outlook® Web Access (OWA) – это один из способов безопасной работы со службами для ваших мобильных служащих. Еще одним важным шагом является обеспечение двухфакторной проверки подлинности для OWA при помощи смарт-карт. В этой статье мы подробно рассмотрим вопросы настройки и установки, в которых вы должны разбираться при развертывании вашей системы проверки подлинности для OWA при помощи смарт-карт.
Лучше, чем брандмауэр
Использование Microsoft® Internet Security and Acceleration (ISA) Server 2006 в вашей сети может упростить задачу более безопасного открытия вашей сети для удаленных пользователей. ISA Server 2006 обладает функциями, улучшающими безопасность, такими как вход в виртуальные частные сети (VNP) при помощи смарт-карт, проверка подлинности по протоколу LDAP для Active Directory®, а также ограниченное делегирование Kerberos. ISA Server слегка отличается от того, как вы традиционно представляете себе брандмауэр. Он обеспечивает множество уровней безопасности не только потому, что функционирует на сетевом уровне – и может делать это в сочетании со стандартным брандмауэром или вместо него – но и потому, что включает в себя дополнительные функции безопасности, которыми обычно не располагают традиционные брандмауэры, например, фильтры приложений. Не хотите, чтобы кто-либо использовал метод HTTP POST на конкретном размещенном веб-узле? Нужно обеспечить соответствие нормативам RFC всех сообщений SMTP перед тем, как они попадут на ваш сервер Exchange? Хотите просмотреть зашифрованные в протоколе Secure Sockets Layer (SSL) пакеты HTTP до того, как они попадут в сеть? ISA Server может выполнить все эти задачи и сделать так, чтобы только чистый и фильтрованный трафик перенаправлялся в вашу DMZ или внутреннюю сеть.
Для стандартных брандмауэров сеансы SSL всегда являются некоторой проблемой. По мере прохождения пакетов через брандмауэр они остаются зашифрованными (что означает, что SSL работает правильно). Таким образом, если приложение, например, OWA, публикуется через аппаратный или программный брандмауэр при помощи SSL, стандартный брандмауэр не сможет провести практически никакой проверки, кроме проверки с сохранением состояния пакета. Простое открытие и переадресация портов оставляет большую поверхность для атаки. Поскольку на границе сети не проводится тщательной проверки, пакеты без проверки подлинности могут быть направлены в вашу внутреннюю сеть.
ISA Server 2006 может выступать в качестве конечной точки SSL для клиентов HTTP, обеспечивая выход на опубликованный сервер Exchange только для трафика, прошедшего проверку подлинности. ISA Server поддерживает такую полезную функцию, как режим моста SSL. Обычно пакет шифруется клиентом, который связывается с сервером ISA при помощи стандартного сеанса SSL. При помощи моста SSL ISA Server может отменить шифрование SSL на локальном уровне, проверить незашифрованный пакет, определить пользователя для Active Directory (если нужно), вновь зашифровать пакет при помощи SSL и отправить зашифрованный пакет на соответствующий сервер Exchange (см. рис. 2). Используя этот прием, мост SSL защищается от атак, скрытых в сеансе SSL и могущих выглядеть как просто зашифрованные фрагменты данных для брандмауэра, в котором отсутствует защита на уровне приложения.
Рис. 2 ISA Server рассматривает трафик на уровне приложения
Попадание на сервер трафика, подлинность которого предварительно проверена, – это важный аспект, который необходимо отметить при упоминании ограниченного делегирования Kerberos. В стандартном брандмауэре порты просто переадресовываются на сервер Exchange, а сервер первого уровня сам несет ответственность за проверку подлинности тех, кто может считаться пользователем-злоумышленником. Когда требуется проверка подлинности, ISA Server может напрямую связаться с Active Directory и сделать запрос на учетные данные от лица самого пользователя. Если подлинность пользователя проверена, ISA Server переадресует сообщение на сервер клиентского доступа Exchange. Серверу клиентского доступа больше не нужно устанавливать подлинность случайных запросов неизвестных пользователей, следовательно, его можно использовать только для формирования запросов на серверы, работающие непосредственно с базой данных. Кроме того, ISA Server 2006 может использовать ограниченное делегирование Kerberos для предоставления доступа на основе сертификатов к таким технологиям, как Windows SharePoint Services и Exchange ActiveSync.
Exchange Server 2003 поддерживает проверку подлинности Kerberos между серверами клиентского доступа и баз данных для входов в сеть с помощью OWA. (Вы ведь используете IPsec для защиты клиентского трафика?) Exchange Server также поддерживает проверку подлинности Kerberos для кластеризованных почтовых серверов.
Включение проверки подлинности по
смарт-картам
Реализация проверки подлинности для OWA на основе смарт-карт было непростой задачей. Однако решение было найдено на основе функции ограниченного делегирования Kerberos, которая сейчас доступна в ISA Server 2006. Это решение позволяет пользователю передавать учетные данные через сертификат, чтобы успешно пройти проверку на подлинность для OWA. Ограниченное делегирование Kerberos явилось долгожданным улучшением поддержки делегирования Kerberos в Windows® 2000, которая использовала неограниченное делегирование. Ограниченное делегирование Kerberos более безопасно и ограничивает возможный риск изощренных атак, использующих олицетворение.
В ситуации, когда смарт-карты включены, ISA Server 2006 связывается с Active Directory для проверки подлинности пользователя, поскольку у пользователя нет маршрутизируемого доступа к центру распределения ключей (KDC) из внешней сети. ISA Server проводит сопоставление сертифицированного пользователя в Active Directory для проверки его подлинности, а затем принимает соответствующие билеты Kerberos на основе имени пользователя-участника (UPN). В этом случае ISA Server предоставляет функциональность ограниченного делегирования Kerberos серверу клиентского доступа Exchange через фильтрацию на уровне приложения и служб обратных прокси. Если делегирование предпринимается без служб обратных прокси, повышенный риск использования уязвимостей может повлиять на целостность сети или домена Active Directory.
И Exchange Server 2003, и Exchange Server 2007 позволяют проводить и базовую, и объединенную проверки подлинности. Однако вам необходимо установить обновление программного обеспечения для Exchange Server 2003, чтобы вы могли использовать проверку подлинности при помощи смарт-карт для OWA. (Для получения дополнительных сведений см. статью "Описание новой функции Exchange Server 2003, поддерживающей проверку подлинности при помощи смарт-карт для доступа к Outlook Web Access".) У вас должен быть домен в основном функциональном режиме Windows Server® 2003, все задействованные серверы Exchange Server 2003 должны иметь SP2 или более позднюю версию, а также вам понадобится сервер ISA Server 2006 в качестве обратного прокси для узла OWA.
После того, как вы установите программное обновление и произведете настройку ваших серверов ISA и Exchange, пользователи смогут проходить проверку подлинности для сеанса OWA, используя смарт-карты. Нарис. 3 показан поток событий, требуемый для проверки подлинности при помощи смарт-карт. Пользователь начинает процедуру с открытия узла OWA в Internet Explorer® (1). Фактически пользователь подключается к ISA Server, получает запрос на сертификат, а не на имя пользователя и пароль, чтобы начать сеанс OWA. Соответствующий сертификат хранится на смарт-карте, для которой пользователю потребуется ПИН-код.
Рис. 3 Проверка подлинности для OWA при помощи смарт-карты
Подтверждение сертификата (2) обрабатывается по запросу списков отзыва сертификатов (CRL) или интерактивного протокола состояния сертификатов (OCSP) в зависимости от настройки ISA Server и другого установленного программного обеспечения. ISA Server делает запрос на контроллер домена (DC) для проверки учетных данных пользователя. Если во время запроса происходит ошибка, ISA Server показывает пользователю страницу ошибки, а на сервер клиентского доступа Exchange не идет никакого запроса.
После подтверждения учетных данных создается билет Kerberos, а запрос передается на сервер клиентского доступа Exchange, использующий объединенную проверку подлинности (3). Когда сервер Exchange первого уровня получает запрос, он подтверждает билет Kerberos и находит сервер базы данных почтового ящика пользователя (4).
Сервер клиентского доступа требует билет Kerberos для соответствующего сервера базы данных посредством ограниченного делегирования Kerberos и передает почтовый запрос на сервер базы данных, используя объединенную проверку подлинности (5). Запрос обрабатывается сервером базы данных (6), а данные почтового ящика возвращаются на сервер клиентского доступа Exchange (7). Данные формата HTML для страницы OWA передаются на ISA Server (8), который затем возвращает их на клиентскую машину (9).
Настройка среды
Exchange
Статья базы знаний, упомянутая ранее, описывает программные обновления для Exchange Server 2003, а также содержит информацию, которая познакомит вас с процессом включения ограниченного делегирования Kerberos при использовании ISA Server 2006 и Exchange Server 2003.
Основная функция, включаемая обновлением программного обеспечения, -- автоматизация процесса ограниченного делегирования Kerberos от сервера клиентского доступа Exchange до соответствующих серверов баз данных. Обновление не будет автоматизировать процесс ограниченного делегирования Kerberos от ISA Server до сервера клиентского доступа, поскольку ISA Server не является частью Exchange. Это делегирование необходимо включать вручную от каждого экземпляра ISA Server до каждого сервера клиентского доступа Exchange.
При обновлении ПО добавляется новая вкладка в диспетчер системы сервера Exchange (ESM), который позволяет вам назначить сервер клиентского доступа Exchange в качестве KCD-FE (см. рис. 4), который, в свою очередь, позволяет выставлять этот сервер во вкладке делегирования соответствующих серверов баз данных Exchange.
Рис. 4 Включение ограниченного делегирования Kerberos
Новый пользовательский интерфейс также позволяет вам определять в свойствах административной группы, какие учетные данные использовать для заполнения атрибута msDS-AllowedToDelegateTo (A2D2), как показано на рис. 5. Этот атрибут отвечает за ограниченное делегирование Kerberos.
Рис. 5 Настройка учетной записи, контролирующей делегирование
В соответствии с принципом минимальных полномочий можно использовать стандартную учетную запись пользователя и давать ей возможность делегировать пользователей и компьютеры при помощи объекта групповой политики (GPO). После того, как учетной записи вручается это повышенное право, она может использоваться как служебная учетная запись для автоматизации процесса ограниченного делегирования Kerberos для соответствующей административной группы.
Вы должны принять необходимые меры, чтобы убедиться в том, что пользователь-злоумышленник не сможет взломать служебную учетную запись ограниченного делегирования Kerberos. Даже если учетная запись не является записью администратора домена, доступ к ней может привести к изощренным попыткам воспользоваться делегированием Kerberos. Поскольку учетная запись может устанавливать новые ассоциации Kerberos, с ней следует обращаться осторожно. Примите необходимые меры предосторожности для обеспечения безопасности и целостности учетной записи: длинный сложный пароль, повышенный аудит, приемы отключения учетной записи и т.д.
Программное обновление Exchange также вносит значительные изменения в интерфейс ESM в плане объединенной проверки подлинности. Ранее в Exchange Server 2003, когда сервер был назначен сервером клиентского доступа, возможность включения объединенной проверки подлинности Windows для виртуальных каталогов HTTP (под виртуальным сервером HTTP) не была доступна (см. рис. 6).
Рис. 6a Обновление позволяет включать объединенную проверку
подлинности
Рис. 6b Обновление позволяет включать объединенную проверку
подлинности
Это происходило потому, что объединенная проверка подлинности не поддерживалась серверами клиентского доступа Exchange по техническим причинам из-за того, что прокси-серверы прерывали сеансы NTLM, пользователям, проходящим проверку подлинности Kerberos, была необходима связь с Active Directory, а пользователи Интернета обычно не были частью домена. Обновление, описанное в вышеупомянутой статье базы знаний, снимает эти ограничения. При установленном обновлении вы можете просто войти в виртуальный каталог и установить флажок для объединенной проверки подлинности Windows в качестве механизма проверки учетных данных пользователя. Если флажок установлен, происходит настройка атрибута под названием msexchAuthenticationFlags на объекте виртуального каталога в Active Directory (вы можете увидеть это, использовав оснастку Adsiedit.msc в консоли управления Майкрософт).
Пользователи, проверяющие почту при помощи OWA, могут знать название своих серверов баз данных Exchange и могут связаться с ними, используя объединенную проверку подлинности, если они находятся в корпоративной интрасети. Разница в поддержке пользователей со объединенной проверкой подлинности состоит в том, что, когда вы входите в сеть, вам предлагают ввести имя пользователя и пароль, потому что Internet Explorer будет производить автоматическую проверку подлинности перед входом на веб-узел. Это очень удобно для пользователей корпоративной сети, но внешние пользователи – а пользователи OWA обычно относятся к внешним – не смогут войти в домен, если они входят из внешней сети на сервер клиентского доступа Exchange. (Этот процесс подробно объясняется в статье в статье базы знаний "Как IIS проверяет подлинность клиентов обозревателя".)
В Exchange Server обновление заносит на вкладку делегирования возможность использования атрибута A2D2, а не атрибута имени участника-службы (SPN) в Active Directory. Если посмотреть на объект компьютера сервера Exchange при помощи Adsiedit.msc, можно увидеть два различных атрибута: атрибут A2D2, являющийся списком ограниченного делегирования Kerberos; и атрибут SPN, который служит в качестве локатора Kerberos и точки спецификации учетной записи. Хотя оба атрибута работают вместе для того, чтобы можно было производить ограниченное делегирование Kerberos, при помощи графического интерфейса нужно изменить только атрибут A2D2.
Windows может использовать встроенный HOST SPN в качестве псевдонима для нахождения других служб. Это означает, что не обязательно использовать setspn.exe, чтобы ограниченное делегирование Kerberos работало для делегирования с сервера клиентского доступа Exchange на сервер базы данных Exchange. (Хотя явное определение HTTP/Servername в списке атрибута SPN подходит для этого метода, оно оставляет больше возможностей для ошибок администратора и не является обязательным для функционирования ограниченного делегирования Kerberos.) Ограниченное делегирование Kerberos ищет атрибут A2D2 в Active Directory. Если этот атрибут не включен (или включен с неправильным значением SPN), ограниченное делегирование Kerberos не будет работать между соответствующими серверами. В кластере Exchange, однако, для нормальной работы необходимо лишь, чтобы атрибут A2D2 от сервера клиентского доступа указывал на учетную запись компьютера узла кластера.
Как отмечалось ранее, домен Windows Server 2003, содержащий серверы Exchange 2003, должен находиться в основном функциональном режиме. Ограниченное делегирование Kerberos нельзя использовать, пока не достигнут этот уровень функциональности домена. Если ваш домен все еще находится в смешанном режиме, а вы установили программное обновление, которое описывалось выше, оно будет работать, но регистрации SPN – не будут. Ограниченное делегирование Kerberos – это тоже функция домена, а не функция уровня леса. Это означает, что на серверах Exchange Server 2003, ISA Server и Exchange серверы клиентского доступа и баз данных должны быть членами одного и того же домена (хотя пользователи из разных доменов могут проходить проверку подлинности при помощи ограниченного делегирования Kerberos). Экземпляр ISA Server, не являющийся членом домена или являющийся членом другого домена, не будет являться частью этого метода.
Настройка узла OWA
IIS Admin не следует использовать ни для каких видов изменений проверки подлинности для OWA. Несмотря на то, что OWA работает под IIS и будет реагировать на изменения в метабазе, как и любой другой веб-узел, сервер Exchange составляет некоторую трудность для процесса службы каталогов в метабазу (DS2MB). Процесс DS2MB скопирует изменения из Active Directory в метабазу IIS в одностороннем порядке с перезаписью любых изменений, сделанных напрямую в IIS. В результате этого процесса, если администратор будет напрямую изменять метабазу IIS (например, настройку объединенной проверки подлинности), то этот метод будет работать, но отключится сразу, как только будет запущен следующий цикл репликации DS2MB.
Функция подключения объединенной проверки подлинности Windows для виртуальных каталогов HTTP была сделана доступной в ESM потому, что ESM производит свои изменения непосредственно в Active Directory, после чего эти изменения реплицируются в метабазу IIS. Учтите, что при остановке службы системного помощника остановится и процесс DS2MB, позволяющий вам вносить изменения в метабазу IIS, которые не будут переписаны, поэтому делать этого не рекомендуется. При следующем запуске системного помощника он запросит изменения из Active Directory, и решение будет отключено автоматически.
Вкладка делегирования показывает следующие варианты: «Использовать только Kerberos» и «Использовать любой протокол проверки подлинности». Простая логика подскажет вам выбрать вариант «Использовать только Kerberos», поскольку решение, которое мы обсуждаем, связано с ограниченным делегированием Kerberos, однако эта одна из многих ситуаций в ИТ, где простая логика не применима. Поэтому вы должны выбрать вариант «Использовать любой протокол проверки подлинности» (как показано на рис. 7), потому что запрос не будет иметь вид запроса Kerberos; он будет приходить как запрос HTTP с соответствующим сертификатом, сопоставленным с учетной записью Active Directory.
Рис. 7 Правильная настройка проверки подлинности для смарт-карт
В данном случае ISA Server запрашивает пользовательский сертификат PKI через SSL. Входящий запрос не является билетом Kerberos, поэтому необходимо произвести переход, чтобы ограниченное делегирование Kerberos функционировало правильно. Выбор настройки "Использовать только Kerberos» нарушит цепь связи на ISA Server. Отметим, однако, что вариант «Использовать только Kerberos» будет работать при делегировании с сервера клиентского доступа Exchange на сервер базы данных Exchange, поскольку сервер клиентского доступа будет получать только билеты Kerberos с ISA Server.
Виртуальные каталоги \Exchange и \Public – единственные каталоги, где должна хранится персональная информация пользователей и информация по общим папкам. Настройка SSL в Exchange не является чем-то новым для ограниченного делегирования Kerberos или двухфакторной проверки подлинности, поскольку это перенос из стандартного включения OWA при помощи SSL с базовыми учетными данными проверки подлинности. Необходимо придерживаться указанных способов включения SSL в OWA, поскольку неправильное обращение с SSL может негативно сказаться на OWA, а также на ESM.
Дополнительные подробности настройки
При использовании этого метода гораздо легче вначале развернуть серверы ISA Server и Exchange стандартным образом. Не нужно сразу разворачивать ограниченное делегирование Kerberos со всеми настроенными параметрами (особенно если до этого вы не развернули ISA Server). Это может осложнить процесс исправления ошибок, если возникнут проблемы с каким-либо компонентом или этапом процесса. Гораздо легче вначале развернуть серверы ISA Server и Exchange стандартным образом (с именем пользователя и паролем, но без проверки подлинности на основе форм), убедиться, что все работает правильно, а затем перейти к ограниченному делегированию Kerberos и проверке подлинности на основе сертификатов.
Обычно проверка подлинности на основе форм не может использоваться вместе с проверкой на основе смарт-карт. Проверка подлинности на основе форм показывает, что пользователь должен передать имя пользователя и пароль через стандартную форму Outlook. Однако при двухфакторной проверке подлинности при помощи смарт-карт у пользователя будет только смарт-карта и не будет пароля. Таким образом, проверка подлинности на основе форм не имеет возможностей принять или передать данные только одного сертификата для проверки подлинности. Использование проверки подлинности на основе форм где-либо в цепи (например, на сервере клиентского доступа за ISA Server) нарушит настройку проверки подлинности для OWA при помощи смарт-карт. Если вы включите проверку подлинности на основе форм, виртуальный каталог сервера Exchange будет вынужден перейти на базовую проверку подлинности, и вслед за ним метабаза IIS также будет настроена на базовую проверку подлинности.
Если у вас есть пользователи как с именами пользователей/паролями, так и со смарт-картами, вы можете включить двойную проверку подлинности на веб-слушателе ISA, и когда пользователь нажимает клавишу ESC после запроса ввести учетные данные на основе сертификата, ему будет предложено ввести стандартные имя пользователя и пароль, даже если встроенная проверка подлинности включена за ISA Server на сервере Exchange. Кроме того, ISA Server может отключать сессию SSL вследствие бездействия точно так же, как при проверке подлинности на основе форм.
Заключение
Поддержка смарт-карт для проверки подлинности в OWA – это долгожданное дополнение как к Exchange Server 2003, так и к Exchange Server 2007. Имея возможность входа в OWA, используя сертификат, пользователи могут больше не беспокоиться о запоминании длинных и сложных паролей, а у администраторов появился эффективное средство клавиатурных шпионов и других вредоносных программ, которые могут извлекать учетные записи из зараженной системы. Для получения дополнительных сведений см. панель «Материалы».
Правильная настройка ISA Server для двухфакторной проверки подлинности при помощи смарт-карт еще более улучшит общий уровень безопасности с применением фильтрации на уровне приложения для публикуемых приложений OWA. Кроме того, у ISA Server 2006 имеется встроенная поддержка для публикации как Exchange Server 2003, так и Exchange Server 2007 при помощи простых мастеров публикации, поэтому ISA Server по-прежнему остается удачным приобретением организаций, переходящих на Exchange Server 2007.