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

• Конфиденциальность канала   Неавторизованные стороны не могут получить доступ к полученным пакетам.
  
  
• Проверка подлинности получателя   Отправители защищены от олицетворения действительных получателей неавторизованными сторонами.
  
  
• Проверка подлинности отправителя   Получатели защищены от олицетворения действительных отправителей неавторизованными сторонами.
  
  

Конфиденциальность канала

Проверка подлинности получателя

Проверка подлинности отправителя

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

• Необходимо использовать общее или разделенное пространство имен?
  
  
• Требуется ли централизованное управление почтой?
  
  

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

Поток входящих сообщений с общим пространством имен

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

С другой стороны, при использовании разделенного пространства имен SMTP-адреса локальных пользователей будут отличаться от облачных пользователей. Для каждого домена могут использоваться разные записи MX, благодаря чему каждая организация сможет обрабатывать входящую почту независимо, как показано на следующем рисунке.

Поток входящих сообщений с разделенным пространством имен

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

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

Централизованное управление почтой

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

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

• При использовании Exchange 2007 см. раздел Общие сведения о параметрах транспорта в системе Exchange 2007.
  
  
• При использовании Exchange 2003 см. раздел Общие сведения о параметрах транспорта.
  
  

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

Если для соответствующих связей как локальной, так и облачной организации включена функция отчетов о доставке, пользователи могут отслеживать отправленные и полученные сообщения в сценарии совместной работы. По умолчанию данная функция включена в полнофункциональном развертывании совместной работы. Тем не менее следует помнить, что при использовании в локальном развертывании более ранних версий Exchange в отчетах о доставке будут отображаться не сведения об окончательной доставке получателям, размещенным на серверах прежних версий, а скорее, что данное сообщение было отправлено в систему Exchange прежней версии. Это не является ограничением развертывания совместной работы, а происходит в результате изменений в реализации отслеживания сообщений в Exchange 2010. Дополнительные сведения см. в подразделе «Отслеживание сообщений в различных версиях» в разделе Обновление от транспортного сервера Exchange 2007.

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

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

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

Как упоминалось ранее, подсказки по умолчанию настроены для бесперебойной работы в локальном сценарии совместной работы. Однако чтобы подсказки функционировали для локальных и облачных пользователей по-разному, можно настроить способ их обработки. Дополнительные сведения см. в подразделе «Архитектура подсказок» в разделеОбщие сведения о подсказках и в подразделе «Использование командной консоли для настройки подсказок для связей организации» в разделе Настройка параметров организации для подсказок.

Функциональные возможности управления сообщениями в среде совместной работы основываются на следующих требованиях.

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

При включении полнофункциональной совместной работы с Office 365, все вышеуказанные требования соблюдены и дополнительные действия для управления сообщениями в среде совместной работы не требуются.