Модель «Транспортные разрешения» в Exchange 2007

Безопасностью домена называется ряд функций Exchange
2007 и Microsoft Office Outlook, представляющих собой альтернативу
S/MIME и другим средствам безопасности уровня сообщений, требующую
достаточно малых затрат. Назначение безопасности домена состоит в
том, чтобы предоставить администраторам способ управлять
безопасными путями обмена сообщениями с деловыми партнерами через
Интернет. После того как эти безопасные пути настроены, сообщения,
успешно переданные по ним от отправителя, прошедшего проверку
подлинности, пользователи в Outlook и Outlook Web Access видят в
разделе защищенной почты домена.

Отправляющий соединитель проверяет, есть ли домен
назначения в списке отправляющих доменов, настроенных в функции
безопасности домена, если выполняются следующие условия:

• Отправляющий соединитель настроен так, чтобы направлять
  сообщения, используя записи ресурсов MX системы DNS.
• Отправляющий соединитель настроен как защищенный доменом.

Если домен назначения есть в списке, транспортный
сервер заставляет выполнять взаимную проверку подлинности TLS при
отправке электронной почты на домен.

Принимающий сервер отвечает командой SMTP QUIT, если
выполняются следующие условия:

• Exchange не может согласовать TLS
• Не удается выполнить проверку сертификата сервера или проверку
  CRL.

Затем сообщения помещаются в очередь на отправляющем
сервере. Очередь находится в состоянии повторной отправки. Так же
сервер действует, если не удается проверить имя.

Если получающ9ий соединитель защищен доменом,
транспортный сервер проверяет полученную почту. Затем транспортный
сервер заставляет выполнить взаимную проверку подлинности TLS, если
отправитель есть в списке получающих доменов, настроенных в функции
безопасности домена. Если все эти проверки выполняются успешно,
полученное сообщение помечается как защищенное доменом. Если
отправитель не может согласовать TLS, или если не выполняется
проверка сертификата сервера или проверка CRL, транспортный сервер
отклоняет сообщение про помощи команды REJECT протокола SMTP.
Неудачное завершение проверки имени также приводит к запуску
команды REJECT протокола SMTP. Затем сервер Exchange отправляет
сообщение с временной ошибкой SMTP (4xx) обратно на отправляющий
сервер. Это означает, что отправляющий сервер должен будет
повторить попытку позднее. Благодаря такому поведению временные
сбои проверки CRL не приводят к тому, что отправителю сразу
посылается NDR. Сбой лишь задерживает доставку сообщения.

Для получения дополнительных сведений см. раздел
Управление
безопасностью домена.

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

• Создан поток электронной почты между сервером транспорта
  Exchange 2007 и сервером Exchange более ранней версии или любым
  другим сервером SMTP.
• Использование обычной проверки подлинности нежелательно.

Соединители Exchange, для которых настроена внешняя
проверка, должны использовать выделенные отправляющие и получающие
соединители, поскольку все подключения к соединителям считаются
безопасными. Поэтому отправляющие соединители, для которых
настроена внешняя проверка, должны использовать интеллектуальный
узел для маршрутизации сообщений. Кроме того, для соединителя
должны быть настроены IP-адреса интеллектуальных узлов назначения.
На получающих соединителях, для которых настроена внешняя проверка,
в качестве значения параметра RemoteIPRanges должен быть
установлен диапазон IP-адресов отправляющих серверов. TLS может
использоваться в сочетании с внешней проверкой подлинности для
повышения конфиденциальности сеанса. Сделать это можно в командной
консоли Exchange: нужно установить для параметра RequireTLS
значение $True.

Протокол TLS описан в RFC 2246. TLS использует
сертификаты X.509. Это разновидность электронных учетных данных.
TLS может быть использован следующим образом:

• Только для обеспечения конфиденциальности.
• Для конфиденциальной проверки подлинности сервера, если
  сертификат сервера подтвержден.
• Для взаимной конфиденциальной проверки подлинности сервера и
  клиента, если подтверждены сертификаты и сервера, и клиента.

Во время передачи данных по протоколу SMTP клиент
запускает команду SMTP STARTTLS для запроса согласования TLS для
данного сеанса. Клиент получает от сервера сертификат X.509 как
часть согласования протокола TLS. Затем согласно политике проверки
подлинности клиента определяется, необходимо ли подтверждение
сертификата получающего сервера и необходимо ли применение
каких-либо критериев к сертификату, таких как сравнение имени.

Дополнительная часть согласования TLS позволяет
получающему серверу также запросить сертификат отправляющего
сервера. Если отправляющий сервер отправляет сертификат получающему
серверу, локальная политика получающего сервера определяет, как
проверяется сертификат и какие разрешения выдаются отправляющему
серверу на основании проверки подлинности.

Когда для проверки подлинности сервера используется
TLS, проверяется только сертификат получающего сервера. Если TLS
используется для взаимной проверки подлинности, должны проверяться
оба сертификата – и сертификат отправляющего сервера, и сертификат
получающего.

Если TLS настроен для получающего соединителя Exchange
2007, сервер должен иметь сертификат X.509. Сертификат может быть
подписан самим сервером или центром сертификации. Сервер Exchange
ищет в локальном каталоге сертификат, соответствующий полному
доменному имени соединителя. Отправляющий сервер выбирает, как
использовать протокол TLS. Если Exchange использует TLS только для
обеспечения конфиденциальности, клиент Exchange не проверяет
сертификат. Например, если Exchange использует TLS между серверами
центрального транспорта, применяя Kerberos по протоколу TLS,
Exchange создает конфиденциальный канал между серверами, а
сертификаты не проверяет. Проверка подлинности между серверами
выполняется при помощи Kerberos после завершения работы протокола
TLS.

Если требуется проверка подлинности TLS, Exchange
должен проверить сертификат. Проверить сертификат Exchange может
двумя способами: прямым доверием и проверкой X.509. Когда TLS
используется для передачи данных между пограничным транспортным
сервером и транспортным сервером-концентратором, Exchange для
проверки сертификата использует метод прямого доверия.

Прямое доверие означает, что Exchange использует
хранилище, которому доверяет, например, Active Directory или ADAM.
Прямое доверие означает, что наличие сертификата в этом хранилище
подтверждает сертификат. Когда используется прямое доверие, не
имеет значения, кем подписан сертификат, самим сервером или центром
сертификации. Когда сервер граничного транспорта вписывается в
организацию Exchange, сертификат пограничного транспортного сервера
публикуется в Active Directory, чтобы транспортные
серверы-концентраторы его подтвердили. Служба Microsoft Exchange
Edgesync обновляет ADAM, добавляя набор сертификатов транспортного
сервера-концентратора, чтобы пограничный транспортный сервер их
подтвердил.

Другой метод, используемый Exchange для проверки
сертификатов — это проверка X.509. Если используется проверка
X.509, сертификат должен быть подписан центром сертификации.
Exchange использует проверку X.509 при проверке подлинности
промежуточных узлов или при использовании безопасности домена. О
безопасности домена рассказано в следующем разделе.