Функции безопасности в Outlook Web Access (часть 1)

В этом цикле статей я хочу рассмотреть функции безопасности, доступные в Outlook Web Access (OWA) в Exchange 2007. В OWA 2007 было добавлено множество усовершенствований в области безопасности по сравнению с предыдущими версиями Exchange, поэтому данные моменты безопасности необходимо тщательно рассмотреть во время стадии создания вашей установки Exchange 2007. Давайте перейдем непосредственно к делу и посмотрим, что этот продукт может нам предложить.

Расположение сервера клиентского доступа (Client Access Server)

Давайте начнем статью с рассмотрения фундаментальной части безопасности Exchange 2007 OWA, а именно с безопасности сервера, отвечающего за предоставление OWA, с сервера Client Access Server. В Exchange 2000 и Exchange 2003 роль сервера переднего плана немного схожа с ролью сервера Client Access Server в Exchange 2007. Иногда организации устанавливали роль сервера переднего плана в демилитаризованной зоне на основе того, что данная конкретная роль подходила для этого местоположения в сети, после чего сервер переднего плана осуществлял соединение с внутренним почтовым сервером. Однако такая конфигурация оказалась противоречивой, поскольку были те, кто считал, что расположение внешнего сервера в демилитаризованной зоне требовало того, что нужно было открывать много дополнительных портов на брандмауэре, отделяя демилитаризованную зону от внутренней сети, в которой находился внутренний почтовый сервер. В Exchange 2007 следует отметить, что Microsoft не поддерживает расположение сервера Client Access Server в демилитаризованной зоне, поэтому при планировании следует учитывать этот факт расположения сервера Client Access Servers.

Учитывая все вышесказанное, давайте перейдем к другим ключевым областям безопасности OWA, начиная с шифрования Secure Sockets Layer (SSL) и сертификатов, используемых для этой цели.

Secure Sockets Layer

Одним из основных изменений в безопасности OWA в Exchange 2007 стал тот факт, что SSL шифрование включено по умолчанию, и для применения шифрования через SSL Exchange 2007 использует цифровые сертификаты. Можно просто связывать термин цифровые сертификаты с сторонними центрами сертификации, такими как Verisign, или с внутренним центром сертификации, который интегрирован в среду Active Directory. Хотя это правильно, стандартный SSL сертификат, который генерируется Exchange 2007 во время установки на, самом деле, является самоподписным сертификатом (self-signed certificate). Это означает, что в то время как сторонние центры сертификации будут подписывать издаваемые ими сертификаты, самоподписные сертификаты, выпускаемые Exchange 2007, как предполагает их название, подписываются самим Exchange 2007.

На рисунке 1 показан самоподписной сертификат, который был выпущен сервером Exchange 2007 с NetBIOS именем CCR-SRV1. На рисунке 2 показан тот же сертификат, но здесь особое внимание уделено полю Subject Alternative Name сертификата.

Рисунок 1: Закладка общих свойств самоподписного сертификата Exchange 2007

Рисунок 2: Поле Subject Alternative Name сертификата Self-Signed Exchange 2007

Из рисунка 2 видно, что поле сертификата Subject Alternative Name заполнено не только NetBIOS именем сервера, но и Fully Qualified Domain Name (FQDN). Также на рисунке 1 видно, что самоподписной сертификат не является доверенным по умолчанию так, это бывает с сертификатами сторонних производителей. Другими словами, вам нужно скопировать этот сертификат в Хранилище доверенных корневых сертификатов (Trusted Root Certificate Store) каждого компьютера, с которых вы собираетесь подключаться к серверу Client Access Server, например, при использовании Outlook Web Access через браузер на ПК. Если этого не сделать, вы получите уведомление о сертификате, как показано на рисунке 3.

Рисунок 3: Сообщение о сертификате в браузере

Если вас не беспокоит появление вышеупомянутого предупреждения, можно использовать самоподписные сертификаты при использовании OWA для доступа к почтовым ящикам. Однако следует отметить, что другие методы клиентского доступа, такие как Outlook Anywhere, не работают с самоподписными сертификатами, поэтому, возможно, лучше будет установить сертификат из стороннего центра сертификации в самом начале, или из внутреннего центра сертификации. Более подобно опции центров сертификации мы рассмотрим в одной из следующих частей этого цикла. Еще одной из основных проблем с самоподписными сертификатами является тот факт, что ими в целом сложнее управлять. Например, самоподписные сертификаты действительны в течение всего одного года в Exchange 2007 Service Pack 1, после чего вам нужно обновлять сертификаты с помощью команды New-ExchangeCertificate. Администраторам бывает довольно проблематично запомнить, когда истекает срок действия этих сертификатов, хотя такие системы мониторинга как System Center Operations Manager (SCOM) могут помочь в решении этой проблемы. Сертификаты, предоставляемые сторонним центром сертификации или центром сертификации Active Directory, могут иметь более длительный срок действия, например, 3 года.

Тот факт, что SSL сертификат устанавливается по умолчанию на роль сервера Client Access Server, позволяет использовать SSL шифрование между клиентом и Client Access Server, когда используются протоколы, поддерживаемые сервером Client Access Server, например, HTTP, POP3 и т.п. Это достигается путем различных виртуальных каталогов, создаваемых в службе Internet Information Services (IIS) на сервере Client Access Server, требующем SSL шифрования. Это можно увидеть, если рассмотреть свойства различных виртуальных каталогов. Например, на рисунке 4 показаны свойства виртуального каталога /owa, запущенного в службе IIS6 на сервере Windows 2003.

Рисунок 4: SSL требования для /owa Virtual Directory

Центры сертификации (Certificate Authorities)

Хотя этот цикл статей посвящен безопасности OWA в Exchange 2007, мне кажется важным сделать паузу и обсудить центры сертификации. Как говорилось ранее, можно использовать самоподписные сертификаты, которые предоставляются по умолчанию в Exchange 2007, или использовать сертификаты из других источников. Эти другие источники включают внутренний центр сертификации Microsoft, внутренний центр сертификации, основанный не на технологии Microsoft, или центр сертификации сторонних производителей, например, Verisign, GoDaddy и т.д. Конечно, использование сторонних сертификатов в основном зависит от роли сервера, который необходимо защитить. Например, предположим, что организация использует URL https://webmail.neilhobson.com, который дает внешний доступ к OWA из удаленного места расположения, и что сервер Client Access Server, отвечающий за внешний доступ к OWA, защищен сервером ISA Server 2006. Лучше всего будет установить сертификат на сервере ISA Server для внешнего OWA URL из стороннего центра сертификации, чтобы убедиться в том, что независимо от того какие ПК и браузеры используются для доступа к OWA, у них не возникнет проблем с доверенностью сертификатов. Однако сертификат для сервера Client Access Server не нужно покупать у того же стороннего поставщика сертификатов, поскольку именно ISA Server будет взаимодействовать с сервером Client Access Server напрямую, а не внешние клиентские ПК. Таким образом, иногда можно использовать сертификаты, выпущенные внутренним центром сертификации для сервера Client Access Server.

Очевидно, приобретение сертификатов сторонних центров сертификации будет стоить определенных денег, в то время как сертификаты, выпущенные внутренним центром сертификации, абсолютно бесплатны, здесь расходы идут только на установку и настройку центра сертификации. К тому же, гораздо проще создать и назначить сертификаты из внутреннего центра сертификации, а затем переиздавать их в случае возникновения определенных проблем. К примеру, сертификат сервера Client Access Server требует множество дополнительных имен, перечисленных в поле Subject Alternate Name, и вполне вероятно, что вы могли забыть включить одно из этих имен в начальный запрос сертификата.

Существует множество организаций, особенно малых предприятий, которые не устанавливали внутренний центр сертификации Microsoft, интегрированный в среду Active Directory. В результате во время первой установки Exchange 2007 этим организациям необходимо решить, будут ли они продолжать использование самоподписных сертификатов Exchange 2007, или они будут получать свои цифровые сертификаты у сторонних поставщиков сертификатов. Еще одним вариантом может быть установка внутреннего центра сертификации, а самой очевидной опцией является установки центра сертификации, использующего службы Microsoft Certificate Services.

Установка Exchange 2007 инфраструктуры не является единственной причиной для того, чтобы обратить внимание на установку внутреннего центра сертификации на основе технологий Microsoft. Прочие продукты Microsoft, такие как Office Communications Server, System Center Operations Manager и System Center Configuration Manager также используют сертификаты. Поэтому, если у вас в настоящее время нет внутреннего центра сертификации, возможно, пришло время задуматься о преимуществах его установки и использования.

Заключение

На этом закончим первую часть цикла статей о безопасности OWA в Exchange 2007. Большую часть статьи мы посвятили рассмотрению SSL сертификатов, и это вполне оправдано, поскольку они жизненно необходимы для безопасности OWA 2007. В следующей части цикла мы рассмотрим способы аутентификации OWA, такие как проверка подлинности на основе форм, а также стандартные способы аутентификации, такие как интегрированная Windows аутентификация.