Новые материалы по безопасной публикации Exchange

Несколько месяцев назад мы опубликовали руководство, детально описывающее шаги по безопасной публикации Exchange в Интернет с помощью TMG и UAG. Недавно документ был обновлен и сейчас доступна новая версия.

В конце прошлого поста я упомянул о нескольких новых руководствах. Первые два из них уже готовы. Первое – о применении IPSec для ограничения доступа к OWA и Outlook Anywhere на компьютерах, которые вы контролируете или которыми управляете. Это руководство доступно тут.

Причина появления этого руководства весьма интересна, по крайней мере, я так думаю. Exchange уже давно предлагал множество способов повсмеместного доступа к почтовым ящикам, но некоторые из наших клиентов все еще не разрешают подключения Outlook Anywhere (и OWA, хотя его в меньшей степени, т.к. OWA имеет на рынке много решений по многофакторной аутентификации) из Интернета: службы безопасности этих клиентов продолжают думать об этих способах подключения как о небезопасных, потому что любой компьютер может выполнить подключение, и существует потенциальная угроза для атаки Denial of Service (DoS) и атаки перебора паролей, их политика безопасности требует двухфакторную аутентификацию, и так далее.

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

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

Доступные варианты:

• VPN – установка VPN соединения до запуска Outlook или OWA позволяет использовать  двухфакторную аутентификацию, но требует от пользователя дополнительных усилий: он не может просто вызвать свою почтовую программу и получить доступ к почте.
• Direct Access – Direct Access обеспечивает доступ из любого места наподобие локального и без дополнительных усилий со стороны пользователя. Он похож на VPN, только без необходимости пользователю выполнять любые действия. Но он имеет важное требование: его поддерживают только клиенты Windows 7 Ultimate/Enterprise,  а на границе лучше всего иметь UAG.
• Security by obscurity – использование внутреннего Центра сертификатов для генерации SSL-сертификатов для того, чтобы предотвратить подключения компьютеров без корневого сертификата, но это легко обойти, просто установив сертификат как доверенный.
• Использование IPSec для безопасности HTTPS подключений – когда IPSec разрешен и обязателен на точке публикации Exchange, только компьютеры с правильными учетными данными могут установить подключение. Затем Outlook/OWA аутентифицируются как обычно, т.к. они не видят и не используют уровень сетевой безопасности.

Если вы хотите решение, которое работает со всеми версиями Exchange и может быть развернуто сегодня без существенных дополнительных инвестиций, IPSec – это самое привлекательное решение. И так совпало, что это именно то, что описано в новом руководстве.

IPSec на уровне компьютера

 

IPSec между компьютерами

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

Настройки политики IPSec могут легко распространяться на клиентские компьютеры (можно и на серверы) с помощью групповых политик Active Directory. Клиент настраивается так, что он будет согласовывать параметры IPSec, когда подключается к определенному адресу или адресам, и будет выполнять аутентификацию, используя сертификат или общий ключ (последний полезен только для отладки, т.к. в случае компрометации его надо будет сменить на всех клиентах, а это может занять очень много времени, и на это время опасность несанкционированного доступа будет сохраняться).

Для компьютеров включенных в домен для работы IPSec достаточно обычного машинного сертификата, который распространяется автоматически в домене. Если необходимо, могут также обрабатываться запросы сертификатов для недоменных компьютеров: такие запросы могут быть разрешены для определенных недоменных компьютеров.  Такие компьютеры могут запросить сертификат, который затем импортируется, после чего  политика IPSec настаивается вручную. Подобные оффлайн-запросы могут требовать аутентификации и авторизации перед выпуском сертификата. Все детали настройки описаны в упомянутом руководстве.

После применения политики клиент и сервер выполняют обмен ключами (Internet Key Exchange, IKE) или используют AuthIP (это зависит от версии операционной системы, но результат будет один и тот же) по порту UDP 500 или порту UDP 4500 (NAT-T), если обнаружен NAT. Затем они согласуют уровни шифрования и аутентификации для установления Security Association (SA). SA периодически обновляется по истечении определенного периода времени или после пропуска определенного количества трафика.

Как только SA установлена, Outlook, OWA или любой другой клиент может установить подключение к удаленному хосту (в нашем случае к внешнему IP-адресу TMG) как будто он подключился непосредственно. Если Outlook/OWA закрывается, то SA остается открытым до истечения тайм-аута или пока одна из сторон не разорвет соединение.

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

Некоторые достоинства этого решения:

• Клиенты выполняют безопасное подключение к серверу в фоне без участия пользователя или приложения. IPSec работает на уровне 3 модели OSI (сетевой уровень).
• Только клиенты с действующим сертификатом компьютера, который выпущен центром сертификатов, которому доверяет точка подключения, может выполнить подключение и даже аутентификацию. DoS уходит с уровня имя/пароль на уровень согласования IPSec, который гораздо труднее взломать.
• Работает с AutoDiscover, EWS, OA, OWA.
• Когда объединено с блокировкой компьютера, оно может рассматриваться как двухфакторная аутентификация: нечто, что вы имеете (сертификат), и нечто, что вы знаете (ваш пароль).
• Вы можете также сказать, что так или иначе существует двухфакторность: нечто, что вы имеете, это сертификат, и нечто, что вы знаете, это  имя/пароль, который требуется для OWA.
• Работает с NAT и всеми версиями Windows старше, чем XP SP2.

Некоторые недостатки этого решения:

• Если IP адрес точки подключения изменился, то политика становится устаревшей. Политики основаны на IP адресе, а не на FQDN.
• Windows Mobile не имеет встроенной поддержки IPSec для сценария точка-точка, и поэтому не может использовать это решение. Однако существуют решения третьих фирм по IPSec для WM и других платформ. Хотя, если используется EAS (Exchange ActiveSync), AutoDiscover должен быть на отдельном от Outlook Anywhere IP-адресе, так что он может быть исключен из IPsec и продолжать использоваться устройствами EAS, или клиент IPsec третьих фирм мог бы быть установлен на мобильное устройство.
• Это решение имеет некоторые сложности в развертывании не только потому, что оно не очень хорошо документировано, но также потому, что оно зависит от PKI и IPSec – технологий, не имеющих широкого понимания. Но теперь вы имеете Руководство, которое даст вам такое понимание, что вы сможете сказать, что знаете об IPSec все!

Системные требования:

• Все клиентские системы Windows, начиная с Windows XP SP2, поддерживают  IPsec и NAT-T.
• Рекомендуется разместить TMG на границе сети, хотя трафик может быть полностью передан на CAS, если это требуется (в этом случае политика должна делить сеть на диапазоны внутреннего, где нет IPsec, и внешнего трафика, где IPsec есть, или одна и та же политика должна применяться всюду).
• PKI для выпуска сертификатов – легче всего раздавать сертификаты на клиентские машины, когда PKI интегрирован в AD, но можно использовать любой PKI. Пока клиент и сервер доверяют одному и тому же центру сертификации, могут построить и проверить всю цепочку сертификатов и проверить отзыв сертификата – PKI будет работать.

Exchange ActiveSync и сертификаты

Второе руководство посвящено использованию сертификатов для аутентификации на Exchange с точки зрения пользователя, а не компьютера, особенно когда используется Exchange ActiveSync или OWA. Руководство доступно здесь.

Это руководство рассматривает вопросы, которые вам необходимо решить, когда вы разворачиваете аутентификацию на основе сертификатов, а также как ее настроить в случае использования Forefront TMG и UAG, плюс содержит рекомендации по поиску и исправлению ошибок. Я надеюсь, что руководство будет вам полезным. Еще один раздел в руководстве  касается конфигурации KCD (Kerberos Constrained Delegation) для фермы веб-серверов: он не раз спас меня, когда мне надо было помочь клиентам настроить этот сценарий, так что обязательно ознакомитесь с ним.

Что дальше?

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

Удачи!

Грег Тейлор

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