Microsoft Exchange Server обеспечивает несколько вариантов защиты данных в сообщениях электронной почты. Эти способы делятся на две категории: шифрование транспорта — защита соединения между двумя компьютерами и, следовательно, содержимого сообщений данного сеанса связи; шифрование самих сообщений, независимо от каналов, по которым они передаются, чтобы прочитать послания мог только получатель.

Шифрование транспорта

Шифрование транспорта, также известное как шифрование сеанса, защищает протокол передачи данных сообщения. Три основных вида шифрования транспорта: Encrypted Messaging API (MAPI), Secure Sockets Layer (SSL) или Transport Layer Security (TLS), и IPsec.
Чтобы защитить сеансы между Microsoft Outlook и Exchange, следует разрешить шифрование протокола MAPI. В MAPI используется удаленный вызов процедур (RPC) между клиентом и сервером. По умолчанию потоки RPC не зашифрованы, но можно включить 128-разрядное шифрование RPC в профиле пользователя Outlook. Надежность такого шифра сравнительно невелика, он защищает только трафик MAPI между Exchange и Outlook. Сообщения электронной почты, пересылаемые за пределы почтового сервера отправителя, не защищены.
Протоколы SSL и TLS также обеспечивают шифрование на прикладном уровне. Главное различие между ними заключается в том, что SSL-соединения необходимо установить по иному порту, нежели в незашифрованном сеансе, а соединение TLS можно организовать через первоначально незащищенное соединение. На сегодня Exchange поддерживает TLS только в соединениях SMTP, а SSL — в соединениях POP3, IMAP, Network News Transfer Protocol (NNTP) и HTTP. Реализация TLS в Exchange годится не для всех случаев; нельзя обслуживать как защищенные, так и незащищенные соединения из одного виртуального сервера.
IPsec — набор IP-расширений, который обеспечивает проверку подлинности и шифрование IP-соединений. IPsec стал составной частью Windows начиная с версии Windows 2000. Активизировать IPsec и управлять им сложнее, чем другими протоколами, зато он отличается повышенной гибкостью. Так как IPsec — компонент операционной системы, он обеспечивает защиту любого приложения (в отличие от SSL и TLS, для которых требуются стандартные приложения). Для использования IPsec с Windows нужно лишь подготовить соответствующие объекты групповой политики (GPO) и присоединить их к соответствующим контейнерам в Active Directory (AD), чтобы задать необходимые фильтры и определить поведение протокола. Поэтому IPsec пригоден для защиты соединений между внешними и внутренними серверами.
Если маршрут данных почтового сообщения состоит из нескольких последовательных сегментов, необходимо защитить каждый из них, иначе данные будут потенциально доступны посторонним лицам. Если защищен каждый сегмент маршрута, то сообщение неуязвимо при передаче по проводам, но не зашифровано в каждом из промежуточных компьютеров между отправителем и получателем.
Дополнительные сведения о защите различных протоколов в Exchange (и области их использования) приведены во врезке «Учебные материалы», в том числе в руководстве «Front-End and Back-End Server Topology Guide for Exchange Server 2003 and Exchange 2000 Server» в библиотеке технической документации Exchange Server 2003 по адресу http://www.microsoft.com/exchange/library.

Шифрование сообщений

По сравнению с защитой транспорта шифрование сообщения кажется простым: нужно зашифровать данные сообщения с помощью ключа, известного только получателю. Независимо от способа доставки сообщения, прочитать его сможет только получатель. Два наиболее известных стандарта шифрования на уровне сообщений — Pretty Good Privacy (PGP) и Secure MIME (S/MIME).
PGP. PGP и его открытая альтернатива GNU Privacy Guard (GPG) обеспечивают иной подход к защите сообщений, нежели S/MIME. В отличие от S/MIME, для PGP и GPG не требуется централизованной инфраструктуры открытого ключа (PKI); пользователи управляют собственным списком цифровых сертификатов (известных как «связка ключей» — keyring). Поэтому пользователям необходим независимый модуль расширения, чтобы задействовать PGP вместе с Outlook. Насколько мне известно, в Microsoft Outlook Web Access (OWA) нельзя оценить корректность PGP-подписанных сообщений (или просмотреть PGP-зашифрованные сообщения). По моему опыту, PGP — отличный метод для индивидуальных пользователей, но он плохо масштабируется на уровне предприятия.
S/MIME. S/MIME — одобренный комитетом IETF метод форматирования и обмена зашифрованными электронными сообщениями с цифровой подписью. Для применения S/MIME требуется правильно организованная инфраструктура PKI. Реализация Exchange/Outlook функционирует совместно с удостоверяющим центром (CA) и AD в Windows, чтобы пользователи могли без труда зарегистрироваться и получить собственные сертификаты для защиты сообщений электронной почты. Затем Outlook извлекает нужные сертификаты получателя для других пользователей компании. Если требуется применить S/MIME для связи с пользователями вне предприятия, необходимо убедиться в корректной настройке PKI (эта задача выходит за рамки данной статьи). S/MIME функционирует следующим образом (PGP работает аналогично):

  1. Отправитель составляет сообщение электронной почты в своем почтовом клиенте.
  2. Почтовое сообщение, представленное для отправки, шифруется и подписывается в соответствии с определенным набором открытых и частных ключей (открытый ключ получателя и частный ключ отправителя).
  3. Сообщение маршрутизируется через промежуточные компьютеры. Его не могут просмотреть посторонние лица; при попытках вскрыть или изменить сообщение цифровая подпись становится недействительной.
  4. Почтовое сообщение поступает получателю. Клиент получателя автоматически проверяет цифровую подпись, чтобы убедиться в ее целостности, а затем сообщение расшифровывается с помощью частного ключа.

На первый взгляд процедура очень надежна, но у S/MIME есть два серьезных недостатка. Во-первых, как отмечалось выше, S/MIME требует наличия действующей инфраструктуры PKI для управления открытыми и частными ключами получателей и отправителей. Exchange 2003 и Exchange 2000 обеспечивают, в сочетании с Windows 2003 и Windows 2000, необходимую функциональность для построения инфраструктуры цифровых сертификатов PKI, пригодной для S/77MIME. Эта инфраструктура PKI интегрируется с AD, позволяя без труда управлять собственными частными ключами и извлекать открытые ключи для других пользователей компании. Клиент Outlook поддерживает S/MIME, а версия OWA для Exchange 2003 расширяет поддержку S/MIME на пользователей OWA.
Во-вторых, сообщения электронной почты шифруются до того, как передаются в службу хранения сообщений Exchange. Другими словами, они пересылаются по каналам связи, через все промежуточные серверы и хранятся в почтовом ящике в зашифрованном виде. При таком подходе блокируются разнообразные полезные функции, в частности возможность проверить содержимое тела сообщения на соответствие правилам серверной стороны. Кроме того, S/MIME влияет на применение мер гигиены сообщений и политики их сохранения и архивирования. Сообщение шифруется, прежде чем попадает на сервер Exchange, поэтому в организации Exchange нельзя расшифровать сообщение, чтобы проанализировать его.
Чтобы использовать S/MIME, необходимо S/MIME-совместимое программное решение. Обычно эти приложения могут обращаться ко всем сертификатам пользователя. Они проверяют сообщения электронной почты, прежде чем те покинут компанию, и используют соответствующий сертификат, чтобы надежно защитить их.
Требуется возможность аудита процесса шифрования электронной почты S/MIME. Кроме того, необходимо иметь мощные средства управления доступом к репозитарию сертификатов, который будет естественной мишенью взломщиков. Наконец, важно убедиться, что процессы резервного копирования, восстановления и архивирования не будут нарушены из-за проблем, вызванных мерами защиты сообщений. Например, компании требуются резервные копии сертификатов, возможность перестроить PKI и архивировать старые и истекшие сертификаты для сообщений, все еще находящихся в архиве.
Дополнительные сведения о развертывании S/MIME приведены во врезке «Учебные материалы», в частности в руководстве «Message Security Guide for Exchange Server 2003» в библиотеке технической документации Exchange Server 2003.

Девин Генджер (deving@3sharp.com) имеет 15-летний опыт управления системами Windows, Unix и обмена сообщениями. Соавтор книги The Exchange Server Cookbook (издательство O’Reilly and Associates) и Web-дневников по проблемам обмена сообщениями и безопасности на сайте (e)Mail Insecurity (http://blogs.3sharp.com/blog/deving).

Дополнительные материалы

Ресурсы WINDOWS IT PRO

Об использовании RPC over HTTP с SSL в Outlook 2003, Exchange 2003 и Windows 2003:
Безопасные альтернативы VPN, http://www.osp.ru/win2000/2007/02/4108237/
Удаленный доступ к Exchange 2003 по каналам http,
http://www.osp.ru/win2000/2003/07/176435/
О применении SMTP over SSL в Exchange 2003:
Электронная книга Understanding and Leveraging SSL-TLS for Secure Communications,
http://www.windowsitpro.com/eBooks