none
Возможность шифрования почтового трафика между организациями MS Exchange.

    Вопрос

  • Доброго времени суток Уважаемые коллеги!

    Стоит задача организовать или рассмотреть несколько решений шифрования почтового трафика между двумя смежными лесами. В одном лесу стоит MS Exchange 2010, в другом 2013. Слышал что есть одно из решений по шифрованию SMTP трафика - использование TLS в коннекторах отправки и приема. Но ни разу такого еще не реализовывал.В связи с этим есть несколько вопросов:

    - Нужны ли сертификаты и если нужны, то что проще использовать- свой внутренний CA в каждом лесе или использовать публичный PKI ?

    - На какие службы необходимо назначать сертификаты ?

    - есть ли еще какие ни будь решения и можно ли где ни будь почитать о таких внедрениях ?

    Спасибо!

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 февраля 2018 г. 7:54

Ответы

  • TLS и так работает по факту у любого MTA. А Вы можете явно сказать, что не просто если он не поставится гнать открытый SMTP, а жестко только его использовать. IPsec бывает транспортный и туннельный- им другие задачи закрываются. В библиотеке технет есть раздел Understanding  Exchange certificates если что.

    Проще TLS. Сказали на отдельном коннекторе- только так отправляем почту, и она только так и отправляется.


    • Изменено Dima RazbornovMVP 8 февраля 2018 г. 12:50
    • Помечено в качестве ответа rеstless 9 февраля 2018 г. 9:20
    8 февраля 2018 г. 12:49
  • Статьи выше не рассматривают эдж сценарий, а ограничиваются хабом. 

    Суть от этого не меняется никак- если есть оконечник (эдж), то сессия ставится на него и омень доверие к корневику должен он.

    Во втором случаем где используется смарт хост- я импортирую на IMSVA  ТОЛЬКО рутовый сертификат, а на CAS я уже создаю так же коннекторы отправки и получения. Но именно на них то же надо будет запрашивать сертификат по имени нового коннектора (MX записи) и так же назначить его на SMTP службу. И так же есть вероятность что смени основной сертификат и может быть причиной сбоя маршрутизации почты. ?

    Ничего дополнительно делать не нужно. Если (см выше) эдж принял письмо, то он его отдаст внутрь организации по уже созданному коннектору. Точка. Ничего на этом коннекторе не надо "донастраивать" для 100500 таких организаций, с которыми Вы вдруг решили почту шифровать.

    • Помечено в качестве ответа rеstless 14 февраля 2018 г. 5:45
    13 февраля 2018 г. 19:11

Все ответы

  • Почитать можно здесь и здесь.

    Ну а так как пятница, то вот здесь с картинками.

    • Предложено в качестве ответа Dmitriy Razbornov 2 февраля 2018 г. 10:05
    2 февраля 2018 г. 8:37
  • Ну на счет пятницы я уже читал.:-)

    Вопросы относительно сертификатов. В одной организации стоит свой внутренний CA, в другой его нет. Если я правильно понял то нужно  будет либо поставить CA в другой конторе ,а далее обменяться корневыми сертификатами на транспортные сервера ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 2 февраля 2018 г. 9:51
    2 февраля 2018 г. 9:51
  • Разумеется, да. Обмениваетесь корневиками или просто используете публичные сертификаты.
    2 февраля 2018 г. 10:05
  • Немного непонятно различие между обычным TLS шифрованием, Domain Security и ipSec.

    Что проще в настройке для совокупности всех настроек и издержек ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    8 февраля 2018 г. 11:56
  • TLS и так работает по факту у любого MTA. А Вы можете явно сказать, что не просто если он не поставится гнать открытый SMTP, а жестко только его использовать. IPsec бывает транспортный и туннельный- им другие задачи закрываются. В библиотеке технет есть раздел Understanding  Exchange certificates если что.

    Проще TLS. Сказали на отдельном коннекторе- только так отправляем почту, и она только так и отправляется.


    • Изменено Dima RazbornovMVP 8 февраля 2018 г. 12:50
    • Помечено в качестве ответа rеstless 9 февраля 2018 г. 9:20
    8 февраля 2018 г. 12:49
  • Спасибо Дмитрий.

    Тогда последний уточняющий вопрос. Сервера Exchange сейчас находятся в продакшине и к сожалению нет возможности организовать некоторую "песочницу". Подскажите пожалуйста, мы можем как то протестировать на живую ? Либо это не затронет существующих коннекторов, потому как мы же будет рядом создавать новые коннекторы для использования TLS Domain Security, или на тех же самых включать все функции ?



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 8 февраля 2018 г. 15:04
    8 февраля 2018 г. 15:02
  • Не затронет. Вы же создадите отдельный коннектор для отправки писем для этого домена. И тестируйте, только те письма, которые пойдут на этот домен либо уйдут, либо вернуться если настройки не верны, либо в очереди будут болтаться. И тестируйте себе.

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

    8 февраля 2018 г. 16:35
  • Не затронет. Вы же создадите отдельный коннектор для отправки писем для этого домена. И тестируйте, только те письма, которые пойдут на этот домен либо уйдут, либо вернуться если настройки не верны, либо в очереди будут болтаться. И тестируйте себе.

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

    Дмитрий я так понимаю даже если у меня коннектор отправки по умолчанию на все пространство адресов, то создав рядом второй коннектор и указав в нем именно тот домен которому буду адресованы письма, то поток пойдет именно через второй коннектор ?

    И еще один момент, у нас за место EDGE взаимодействие с внешними почтовыми системами осуществляется через смарт хост TrendMicro InterScan Messaging Security Virtual Appliance . Сертификаты нужно ставить все равно на CAS /HUB сервера (Exch 2013 у нас и Exch 2010 у партнера соответственно) ?

     Заранее благодарен.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 9 февраля 2018 г. 6:18
    9 февраля 2018 г. 6:18
  • Правильно понимаете, только это надо знать крепко.

    Почитайте, как работает маршрутизация, там фокусов-то нет, а знать как именно она работает просто необходимо.

    Сертификаты нужны будут только на Edge, он будет ставить TLS сессию, а внутрь уже отдаст "по своим каналам". Значит придется кормить сертификат Трендмайкро.

    9 февраля 2018 г. 6:26
  • Да все верно:

    When the Microsoft Exchange Transport service selects a connector for routing, it only considers connectors that have a matching address space for the destination domain. You can use the wildcard character * in an address space to indicate all domains, all domains that have a particular top-level domain, such as *.com, or a second-level domain and all its subdomains, such as *.contoso.com. When you configure a connector for a particular domain, e-mail sent to that domain is always routed through that connector.

    If more than one connector matches the address space for the destination recipient domain, the connector with the more precise address match is selected. For example, if Send connector C1 is configured to have the address space *.contoso.com and Send connector C2 is configured to have the address space northamerica.contoso.com, e-mail addressed to user@europe.subdomain.contoso.com is routed to Send connector C1 and e-mail addressed to user@northamerica.contoso.com is routed to Send connector C2. Even though the latter address matches the address spaces on both connectors, the address space of C2 is a better match.

    Спасибо.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    9 февраля 2018 г. 9:20
  • Правильно понимаете, только это надо знать крепко.

    Почитайте, как работает маршрутизация, там фокусов-то нет, а знать как именно она работает просто необходимо.

    Сертификаты нужны будут только на Edge, он будет ставить TLS сессию, а внутрь уже отдаст "по своим каналам". Значит придется кормить сертификат Трендмайкро.

    Дмитрий, на смарт хосте ISMVA трендмикро через который ходит почта, имеются свои настройка TLS для SMTP. Все таки хотел уточнить- мне на трендмикро копировать оба сертификата-  рутовый и подписанный назначать на SMTP ?

    Потому что коннектор на CAS настроен на прием и отправку через смартхост трендмикро. Либо все равно обязательно создавать новые коннекторы  на них назначать подписанный сертификат на SMTP службу, а рутовый скопировать на трендмикро. А в самих коннекторах просто указать использовать смартхост для определенного адресного пространстваю


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    13 февраля 2018 г. 15:03
  • Все таки хотел уточнить- мне на трендмикро копировать оба сертификата-  рутовый и подписанный назначать на SMTP ?

    Только рутовый. Имея его и доверяя он спокойно любой другой сертификат проверит на доверие и построит цепочку. Вы же понимаете, как это работает? Если нет, надо подтянуть матчасть в этом вопросе разово, там все просто.

    13 февраля 2018 г. 17:12
  • Все таки хотел уточнить- мне на трендмикро копировать оба сертификата-  рутовый и подписанный назначать на SMTP ?

    Только рутовый. Имея его и доверяя он спокойно любой другой сертификат проверит на доверие и построит цепочку. Вы же понимаете, как это работает? Если нет, надо подтянуть матчасть в этом вопросе разово, там все просто.

    Дмитрий, как работает цепочка сертификатов и вообще PKI мне понятно. Меня смутило то, где назначать сертификат на службу SMTP.Еще раз по порядку. 

    Как пример два домена 2010.ru в котором стандартные три роли и маршрутизацию выполняет Hub, и 2013.ru где вместо EDGE стоит IMSVA.По статьям которые были даны выше, я вижу что там где обычный хаб, нужно импортировать корневой сертификат домена 2013.ru, Далее нужно еще запросить сертификат на имя нового коннектора и назначить его на SMTP. Тут есть еще опасение , что может отвалится почта, так как основной SMTP сертификат может слететь.

    Во втором случаем где используется смарт хост- я импортирую на IMSVA  ТОЛЬКО рутовый сертификат, а на CAS я уже создаю так же коннекторы отправки и получения. Но именно на них то же надо будет запрашивать сертификат по имени нового коннектора (MX записи) и так же назначить его на SMTP службу. И так же есть вероятность что смени основной сертификат и может быть причиной сбоя маршрутизации почты. ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    13 февраля 2018 г. 18:12
  • Статьи выше не рассматривают эдж сценарий, а ограничиваются хабом. 

    Суть от этого не меняется никак- если есть оконечник (эдж), то сессия ставится на него и омень доверие к корневику должен он.

    Во втором случаем где используется смарт хост- я импортирую на IMSVA  ТОЛЬКО рутовый сертификат, а на CAS я уже создаю так же коннекторы отправки и получения. Но именно на них то же надо будет запрашивать сертификат по имени нового коннектора (MX записи) и так же назначить его на SMTP службу. И так же есть вероятность что смени основной сертификат и может быть причиной сбоя маршрутизации почты. ?

    Ничего дополнительно делать не нужно. Если (см выше) эдж принял письмо, то он его отдаст внутрь организации по уже созданному коннектору. Точка. Ничего на этом коннекторе не надо "донастраивать" для 100500 таких организаций, с которыми Вы вдруг решили почту шифровать.

    • Помечено в качестве ответа rеstless 14 февраля 2018 г. 5:45
    13 февраля 2018 г. 19:11
  • Дмитрий, спасибо. В принципе я тут еще почитал, посмотрел. Да действительно, все что надо сделать, так это создать коннекторы отправки и получения с адресным пространством партнера домена и импортировать root сертификат партнера на HUB- в случае , что только он и есть, а в случае же пограничника (эдж, либо другого продукта) рутовый сертификат партнера надо тащить на него, в остальном же все манипуляции те же.

    Логично, что нет смысла привязывать сертификат на службу SMTP, если он уже привязан изначально для отправки на все адресное пространство.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 14 февраля 2018 г. 5:50
    14 февраля 2018 г. 5:49
  • Статьи выше не рассматривают эдж сценарий, а ограничиваются хабом. 

    Суть от этого не меняется никак- если есть оконечник (эдж), то сессия ставится на него и омень доверие к корневику должен он.

    Во втором случаем где используется смарт хост- я импортирую на IMSVA  ТОЛЬКО рутовый сертификат, а на CAS я уже создаю так же коннекторы отправки и получения. Но именно на них то же надо будет запрашивать сертификат по имени нового коннектора (MX записи) и так же назначить его на SMTP службу. И так же есть вероятность что смени основной сертификат и может быть причиной сбоя маршрутизации почты. ?

    Ничего дополнительно делать не нужно. Если (см выше) эдж принял письмо, то он его отдаст внутрь организации по уже созданному коннектору. Точка. Ничего на этом коннекторе не надо "донастраивать" для 100500 таких организаций, с которыми Вы вдруг решили почту шифровать.

    Дмитрий, кстати у нас уже используются Public CA на коннекторах и я так понимаю, что можно импортировать Rott Public CA на IMSVA и HUB соответственно ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    14 февраля 2018 г. 7:15
  • Нет, это тоже лишнее.
    14 февраля 2018 г. 11:22