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

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

Укрепите Windows и установите брандмауэры

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

Exchange Server во всем полагается на Windows. Если Windows на вашей системе защищена плохо, у сервера Exchange тоже будут проблемы с безопасностью. Поэтому исключительно важно предварительно выполнить следующие действия: удалить все необязательные компоненты и службы Windows, установить все новейшие модули оперативной коррекции Windows, а также следовать различным рекомендациям, относящимся к категории «передовая практика работы с Windows». Более конкретные сведения можно почерпнуть из руководства Windows Server 2003 Security Guide, которое можно загрузить по адресу www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx. Кроме того, можно воспользоваться мастером Security Configuration Wizard, который укрепит серверы и сократит потенциальную площадь атаки на них. Этот мастер можно загрузить по адресу www.microsoft.com/downloads/details.aspx?familyid=903fd496–9eb9–4a45-aa00–3f2f20fd6171&displaylang=en.

Помимо прочего, весьма важно применять в организации надежные настройки конфигурации брандмауэров. Лично я рекомендую организовывать защиту средствами брандмауэров уровень за уровнем. Сетевой периметр следует защищать с помощью аппаратно реализованного сетевого экрана, но я рекомендую также размещать внутри демилитаризованной зоны систему Microsoft ISA Server. Она была разработана для возможного использования с Exchange Server и является эффективным брандмауэром приложений. Но даже при установленной системе ISA Server необходимо использовать брандмауэры Windows на всех серверах как средство предотвращения атак, которые могут осуществляться изнутри организации.

Используйте только одну версию Exchange

Если вы хотите создать защищенную организацию Exchange Server, следует жестко контролировать номера версий как серверов Exchange, так и серверов Windows. К примеру, если вы готовитесь к переходу на систему Exchange Server 2007, лучше всего с точки зрения безопасности (и, разумеется, с точки зрения управления) развертывать на всех серверах Exchange системы Exchange 2007, а не смешивать продукты Exchange 2007 и Exchange Server 2003.

Боюсь, что, прочитав последнее предложение, многие читатели были удивлены. Ведь широко известно, что Microsoft полностью поддерживает сосуществование систем Exchange 2007, Exchange 2003 и Exchange 2000 Server. Но не будем забегать вперед.

Одна из причин, побуждающая меня рекомендовать читателям ограничиваться одной версией Exchange в организации, состоит в том, что таким образом вы снизите сложность управления. Проиллюстрирую сказанное примером. Как известно, при эксплуатации Exchange 2003 необходимо использовать узлы, группы маршрутизации и административные группы. В Exchange 2007 такие объекты не применяются, но эта версия дает возможность эмулировать упомянутые объекты для обеспечения обратной совместимости с более ранней версией. Так вот, удалив системы Exchange 2003 из вашей организации, вы устраняете необходимость эмуляции данных объектов средствами Exchange Server 2007. В результате сложность выполняемого кода снижается.

При проектировании организаций Exchange Server я руководствуюсь следующим эмпирическим правилом: понижать уровень сложности везде, где только возможно. Таким образом я укрепляю безопасность системы и облегчаю процедуру выяснения причин неполадок.

Еще одно обстоятельство, с учетом которого я заключаю, что важно ограничиваться одной версией Exchange, сводится к тому, что при такой организации дела устраняется фактор «что, если». Представьте себе, к примеру, что у вас функционируют системы Exchange 2007 и Exchange 2003. Допустим теперь, что кто-то обнаружил изъян в системе безопасности, имеющий отношение к тому, как Exchange 2007 взаимодействует с транспортным стеком сервера. Мы говорим не о реальной проблеме, а о гипотетической ситуации.

В таком случае логично задать вопрос: характерно ли это слабое звено только для Exchange 2007 или оно существует и в системах 2003? Если бы на всех серверах Exchange вашей компании выполнялись только версии Exchange 2007, вы смогли бы сосредоточить внимание на исправлении известной ошибки, а не стали бы выяснять, имеется ли такая же ошибка в другой версии Exchange.

На одном сервере должна быть только одна серверная роль

Концепция серверных ролей была реализована до появления Exchange 2007, но в этой версии данная концепция получила весьма значительное развитие по сравнению с уровнем Exchange 2003. В этой последней системе официально существуют только две роли — роли внешних серверов и внутренних серверов Microsoft Outlook Web Access (OWA). Между тем, многие администраторы «определяют» собственные роли Exchange 2003, такие, как серверы почтовых ящиков и серверы общих папок. Кстати, в руководстве Microsoft Exchange Server 2003 Security Hardening Guide (www.microsoft.com/downloads/details.aspx?familyid=6A80711F-E5C9–4AEF-9A44–504DB09B9065&displaylang=en) специалисты корпорации ввели и другие роли, но собственно в продукте Exchange 2003 эти роли реализованы не были.

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

Пять упомянутых ролей — это Mailbox, Client Access, Hub Transport, Edge Transport и Unified Messaging. На одном сервере может быть реализовано несколько ролей. Существует только две роли, которые не могут взаимодействовать с другими ролями: это роль Edge Transport и роль Mailbox (в случае, если сервер входит в состав кластера). Роль Edge Transport будет более подробно рассмотрена ниже. А сейчас я хотел бы привлечь внимание читателей к другим четырем ролям, а также к вопросу о том, как спроектировать защищенную среду Exchange с использованием этих ролей.

Если отвлечься от роли Edge Transport, будет справедливо отметить, что на одном сервере Exchange можно выполнять различные серверные роли в любой комбинации. Более того, если вы не используете роль Edge Transport, то можете одновременно разместить на одной системе Exchange 2007 все серверные роли Exchange. Однако из соображений безопасности и производительности я рекомендую реализовывать на одном сервере Exchange только одну роль.

Серверы, на которых выполняется роль Mailbox, включают в себя базы данных почтовых ящиков и/или доступных папок. Очень часто для выполнения серверной роли Mailbox выделяется один или несколько серверов, но делается это, как правило, не для усиления безопасности, а для повышения производительности. Базы данных Exchange обычно бывают настоящими «пожирателями» ресурсов, так что во многих случаях выделение особого сервера вполне оправданно.

Тем, кто не может обойтись без консолидации серверных ролей, я рекомендую выполнять на одной системе роли Mailbox и Hub Transport (я исхожу из того, что аппаратные средства позволяют осуществить такую консолидацию). При одновременном использовании на одной машине этих двух ролей возможность возникновения проблем в плане безопасности менее вероятна.

Серверы Hub Transport ответственны за весь внутренний поток почтовых сообщений, за их маршрутизацию и применение к ним средств фильтрации. Поскольку эта роль, как и роль Mailbox, размещается во внутренней сети, риски в области безопасности, связанные с выполнением обеих ролей на одной машине, минимальны.

Роль Client Access всегда должна выполняться на выделенном сервере. В системе Exchange 2003 эта роль соответствует внешнему серверу в том смысле, что она получает запросы из Internet и передает их на почтовый сервер. Понятно, что перед сервером Client Access следует устанавливать брандмауэр, задача которого — блокировать передачу любых данных, кроме передаваемого через порты 80 и 443 трафика по протоколам HTTP и HTTP Secure (HTTPS). Но как бы то ни было, роль Client Access подразумевает получение трафика из Internet, так что лучше всего не размещать на сервере Client Access другие роли, которые потенциально могут стать объектами посягательств со стороны хакеров.

До появления Exchange 2007 ничего подобного роли Unified Messaging в почтовых серверах не применялось. Для тех, кому не приходилось сталкиваться с термином unified messaging, поясняем, что это новая технология, обеспечивающая передачу и хранение голосовой почты и факсов наряду с сообщениями электронной почты. Серверы Unified Messaging имеют новый тип интерфейса, именуемый Outlook Voice Access (OVA). Он дает пользователям возможность взаимодействовать с организацией Exchange с помощью голоса или телефонного аппарата с тоновым набором.

На мой взгляд, с точки зрения защиты данных, OVA гораздо надежнее, чем OWA, т. к. при использовании OVA серверы Unified Messaging не имеют выхода в Internet, а пользователи Unified Messaging не применяют компьютеры для подключения к серверам.

Однако OVA оставляет серверы Unified Messaging открытыми для доступа из телефонной сети общего пользования Public Switched Telephone Network (PSTN), которая, как утверждается, хуже защищена и подключена к большему числу устройств, нежели Internet. Поэтому я рекомендую изолировать серверы Unified Messaging от остальных компонентов организации серверов Exchange с помощью брандмауэра. Помимо прочего, серверы Unified Messaging исключительно интенсивно потребляют ресурсы, и это обстоятельство само по себе уже оправдывает применение выделенного сервера.

Используйте сервер Edge Transport Server

Серверная роль Edge Transport впервые реализована в продукте Exchange 2007. О ней я хочу поговорить особо, ибо ее назначение как раз и состоит в том, чтобы обеспечить защиту организации Exchange. Я рекомендую в каждой сети Exchange использовать сервер пограничного транспорта в качестве важного элемента плана защиты сети.

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

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

Дабы избежать контакта AD с внешним миром, разработчики поставили функционирование сервера Edge Transport в зависимость от прикладной версии AD (AD Application Mode, ADAM). ADAM — это раздел каталога AD, где хранятся данные, касающиеся конкретных приложений (а не копия всей базы данных AD). При установке роли Edge Transport Exchange создает на сервере Edge Transport базу данных ADAM. Далее из каталога AD в базу данных ADAM передается минимальный объем информации с тем, чтобы сервер Edge Transport получил необходимые сведения о конфигурации без вовлечения в этот процесс всех данных AD.

Мало того, стремясь гарантировать изоляцию баз данных AD, специалисты Microsoft разработали процесс репликации Edge Transport. Таким образом, сервер Edge Transport никогда не вступает в контакт с остальными компонентами организации Exchange. В процессе установки на сервере Edge Transport создается специальный XML-файл, именуемый файлом пограничной подписки (edge subscription file). Этот файл предписывает организации Exchange реплицировать сведения о получателе и конфигурации из AD на раздел ADAM сервера Edge Transport. Администратор копирует этот файл на сервер Hub Transport и затем вручную удаляет его с сервера Edge Transport с тем, чтобы сделать файл недоступным для хакеров, пытающихся вмешаться в процесс репликации.

С учетом той роли, которую сервер Edge Transport играет в организации, его разработчики позаботились о том, чтобы этот сервер был безопасным по умолчанию. Поэтому администратору нет нужды принимать какие-то особые меры для защиты сервера Edge Transport; единственное, что необходимо сделать, — удостовериться в том, что система Windows установлена с соблюдением мер безопасности, удалить файл пограничной подписки и следовать обычным методам «передовой практики», общим для всех серверов Exchange.

Пусть фильтрацией занимается подрядчик

Я убежденный сторонник аутсорсинга функции фильтрации почты, когда вылавливанием вирусов и спама еще до того, как сообщения поступают в организацию Exchange, занимается внешний подрядчик, например поставщик услуг Internet. В таких ситуациях MX-запись для домена указывает не на почтовый сервер, а на выделенный IP-адрес, принадлежащий серверу, который осуществляет фильтрацию контента. Это значит, что электронная почта не поступает непосредственно в организацию, а сначала направляется в осуществляющую фильтрацию компанию. Последняя проверяет сообщения на наличие вирусов и спама, удаляет найденные объекты и затем передает легитимные сообщения в организацию Exchange.

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

Второе достоинство стратегии аутсорсинга фильтрации почты в том, что таким образом вы сохраняете полосу пропускания сети. Наверное, не будет преувеличением сказать, что в большинстве организаций спам составляет от 60 до 90% от всего объема входящей электронной почты. Если вы сможете отфильтровать подавляющую часть этого спама еще до того, как он поступит в вашу организацию, вы в конце концов сможете избежать существенного сокращения полосы пропускания на соединении с Internet — ведь вашим серверам не придется загружать весь этот «мусор». Но и это еще не все. Таким образом вы сможете снизить нагрузку на память, процессоры и диски своих почтовых серверов.

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

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

Брайен Поуси (http://www.brienposey.com) — вице-президент по исследованиям компании Relevant Technologies. Автор статей на технические темы для различных изданий и Web-сайтов