Общие сведения о безопасности VoIP единой системы обмена сообщениями

Применимо к: Exchange Server 2010

Последнее изменение раздела: 2009-11-04

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

1. установить роль сервера единой системы обмена сообщениями;
2. создать новый самозаверяющий или общедоступный сертификат для использования Mutual TLS;
3. связать сертификат с сервером единой системы обмена сообщениями;
4. настроить абонентскую группу единой системы обмена сообщениями для работы в режиме в «С защитой SIP» или «Защищенный»;
5. настроить режим запуска на сервере единой системы обмена сообщениями;
6. связать серверы единой системы обмена сообщениями с телефонной группой единой системы обмена сообщениями;
7. настроить для используемых шлюзов IP единой системы обмена сообщениями полные доменные имена и использование TCP-порта 5061;
8. экспортировать и импортировать сертификаты, необходимые, чтобы серверами единой системы обмена сообщениями, шлюзами IP и УАТС на базе IP и остальными серверами, на которых запущен Microsoft Exchange Server 2010, мог использоваться протокол Mutual TLS.

Содержание

Защита единой системы обмена сообщениями

Типы сертификатов

Настройка протокола MTLS

Протокол IPsec

Абонентские группы единой системы обмена сообщениями и безопасность VoIP

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

Защита единой системы обмена сообщениями

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

Защита единой системы обмена сообщениями

Возможные угрозы	Возможные методы защиты
Отслеживание голосового трафика	Использовать протокол IPsec. Шлюз IP или УАТС на базе протокола IP должны поддерживать протокол IPsec. Использовать протокол SRTP.
Атака на шлюз IP или IP-АТС	Использовать надежные методы проверки подлинности. Использовать стойкие пароли для администраторов. Использовать для защиты учетных данных администраторов протокол SSL (Secure Sockets Layer). Шлюз IP или IP-АТС должны поддерживать протокол SSL. Использовать протокол Secure Shell (SSH), а не протокол Telnet.
Несанкционированные междугородные звонки	Использовать правила и ограничения набора номера телефонных групп единой системы обмена сообщениями. Они могут настраиваться через телефонные группы и политики почтовых ящиков единой системы обмена сообщениями. Дополнительно можно ввести в действие другие ограничения набора номера, соответствующим образом настроив коммутатор PBX.
Атака типа «отказ в обслуживании»	Сервер единой системы обмена сообщениями взаимодействует только с теми шлюзами IP и УАТС на базе протокола IP, которые включены в список доверенных устройств или серверов VoIP. Список доверенных устройств или серверов VoIP создается при создании шлюза IP единой системы обмена сообщениями в службе каталогов Active Directory. Использовать протокол MTLS.
Олицетворение роли прокси-сервера SIP	Использовать протокол MTLS. Использовать протокол IPsec. Шлюз IP или УАТС на базе протокола IP должны поддерживать протокол IPsec. Настроить доверенные локальные сети, например виртуальные локальные сети, выделенные глобальные сети или виртуальные частные сети.
Перехват информации и перехват сеанса	Использовать протокол Mutual TLS для затруднения перехвата сигналов. Использовать протокол IPsec. Шлюз IP или УАТС на базе протокола IP должны поддерживать протокол IPsec. Настроить доверенные локальные сети, например, виртуальные локальные сети, выделенные глобальные сети или виртуальные частные сети.

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

Протокол Mutual TLS можно использовать для шифрования трафика VoIP, проходящего в сети между шлюзами IP, УАТС на базе протокола IP и другими серверами Exchange 2010 и серверами единой системы обмена сообщениями. Лучший способ защиты в данном случае — это шифрование данных VoIP с помощью протокола Mutual TLS.

Однако в зависимости от конкретной угрозы безопасности можно также настроить политики IPsec таким образом, чтобы включить шифрование данных между шлюзами IP или УАТС на базе протокола IP и сервером единой системы обмена сообщениями и остальными серверами Exchange 2010 в сети. В некоторых средах использование протокола IPsec может оказаться невозможным, потому что протокол IPsec недоступен или не поддерживается шлюзами IP и УАТС на базе протокола IP. Кроме того, использование протокола IPsec вызывает дополнительную нагрузку на системные ресурсы серверов единой системы обмена сообщениями. С учетом этих факторов протокол Mutual TLS — лучший выбор для защиты сетевого трафика VoIP в среде единой системы обмена сообщениями.

После правильной реализации и настройки протокола Mutual TLS VoIP-трафик между шлюзами IP, УАТС на базе протокола IP и остальными серверами Exchange и серверами единой системы обмена сообщениями шифруется. Однако если нельзя использовать протокол Mutual TLS для защиты трафика от сервера единой системы обмена сообщениями или принимаемого им трафика (например, если сервер единой системы обмена сообщениями взаимодействует с еще одним сервером в сети, таким как контроллер домена Active Directory или сервер почтовых ящиков Exchange 2010), для защиты данных используются другие типы шифрования. На следующем рисунке показаны методы шифрования, которые можно использовать для защиты единой системы обмена сообщениями.

Безопасность данных VoIP в единой системе обмена сообщениями

В начало

Типы сертификатов

Цифровые сертификаты представляют собой файлы, которые играют роль «оперативного паспорта» для проверки удостоверения пользователя или компьютера и используются для создания зашифрованного канала, в свою очередь используемого для защиты данных. Сертификат — это цифровой документ, выпускаемый центром сертификации, подтверждающий личность владельца сертификата и позволяющий сторонам взаимодействовать безопасным образом, используя шифрование. Сертификаты могут выпускаться доверенными сторонними центрами сертификации, например с помощью служб сертификации, или могут быть самозаверяющими. У каждого типа сертификатов есть свои преимущества и недостатки. Однако в любом случае сертификаты защищены от несанкционированного изменения, и их нельзя подделать. Сертификаты могут выпускаться для разных целей, например для проверки подлинности веб-пользователя или веб-сервера, а также для подписывания протоколов S/MIME, IPsec, TLS и кода.

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

Цифровые сертификаты выполняют следующие функции:

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

Традиционно существует три варианта или типа сертификатов, которые могут использоваться единой системой обмена сообщениями и шлюзами IP и IP-АТС. При всех трех подходах или вариантах частью сертификата является открытый ключ владельца сертификата, так что сообщения могут быть расшифрованы сервером, пользователем, веб-сайтом или другим ресурсом на другом конце канала связи. Закрытый ключ известен только подписавшему сертификат. Каждый сертификат имеет атрибут EnhancedKeyUsage, устанавливаемый для указания конкретной цели использования данного сертификата. Например, может быть указано использование только для проверки подлинности серверов или для работы с шифрованной файловой системой. Единой системой обмена сообщениями сертификаты используются для проверки подлинности серверов и шифрования данных.

Самозаверяющие сертификаты

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

В случае недоступности стороннего сертификата или сертификата на основе инфраструктуры открытых ключей сервер единой системы обмена сообщениями выполняет поиск самозаверяющего сертификата в локальном хранилище данных. Если серверу не удается найти сторонний сертификат или сертификат на основе инфраструктуры открытых ключей, им будет создан самозаверяющий сертификат для протокола MTLS. Однако поскольку это самозаверяющий сертификат, он не будет доверенным для шлюзов IP, УАТС на базе протокола IP и остальных серверов в сети. Чтобы обеспечить доверие к самозаверяющему сертификату со стороны шлюзов IP, IP-АТС и остальных серверов, необходимо импортировать такой сертификат в локальное доверенное корневое хранилище сертификатов всех устройств и серверов. После этого, когда сервер единой системы обмена сообщениями предоставляет такой самозаверяющий сертификат шлюзу IP, УАТС на базе протокола IP или серверу, они смогут проверить, что сертификат был выпущен надежным центром сертификации, потому что поставщик будет совпадать с получателем, определенным в самозаверяющем сертификате.

Если используются только самозаверяющие сертификаты, то необходимо импортировать отдельный самозаверяющий сертификат на каждый шлюз IP, УАТС на базе протокола IP или сервер. В больших сетях со многими устройствами или компьютерами это может оказаться не самым лучшим способом реализации протокола MTLS. Использование самозаверяющих сертификатов в больших корпоративных сетях плохо масштабируется из-за дополнительных административных накладных расходов. Однако административные накладные расходы не являются проблемой при наличии большого числа устройств и использовании инфраструктуры открытых ключей или коммерческих сторонних сертификатов. Причина этого в том, что у каждого устройства есть сертификат, выпущенный одним и тем же доверенным корневым центром. Наличие сертификата от одного и того же доверенного корневого центра обеспечивает отношения доверия между сервером единой системы обмена сообщениями и шлюзами IP, IP-АТС и другими серверами.

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

1. импортировать самозаверяющий сертификат сервера единой системы обмена сообщениями в доверенное корневое хранилище сертификатов каждого шлюза IP, УАТС на базе протокола IP или сервера, с которыми сервер единой системы обмена сообщениями будет взаимодействовать, используя протокол Mutual TLS;
2. получить самозаверяющий сертификат для каждого шлюза IP, IP-АТС или другого сервера и импортировать его в доверенное корневое хранилище сертификатов сервера единой системы обмена сообщениями; Импортировать сертификат центра сертификации в доверенное корневое хранилище сертификатов всех устройств и серверов в случае использования стороннего сертификата или сертификата на основе инфраструктуры открытых ключей.

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

В начало

Инфраструктура открытых ключей

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

Службы сертификации можно установить на любом сервере в домене. Если сертификаты доставляются из центра сертификации в домене Windows, можно использовать данный центр сертификации для запросов или подписи сертификатов, которые необходимо выпустить для серверов или компьютеров в своей сети. Это позволяет использовать инфраструктуру открытых ключей, аналогичную той, которую используют сторонние поставщики сертификатов, но менее дорогую. Хотя такие инфраструктуры открытых ключей не могут разворачиваться для открытого использования, в отличие от других типов сертификатов при использовании инфраструктура открытых ключей центр сертификации подписывает сертификат запросившей стороны с помощью закрытого ключа, а затем выполняется проверка запросившей стороны. Открытый ключ центра сертификации включается в выдаваемый этим центром сертификат. Любой объект, имеющий такой сертификат центра сертификации в качестве корневого сертификата, может использовать этот открытый ключ для расшифровки сертификата запросившей стороны и проверки подлинности запросившей стороны.

При использовании для реализации протокола MTLS сертификата инфраструктуры открытых ключей необходимо скопировать требуемые сертификаты на шлюзы IP и IP-АТС. Затем необходимо скопировать сертификаты шлюзов IP и УАТС на базе протокола IP на серверы единой системы обмена сообщениями, связанные с абонентской группой единой системы обмена сообщениями, которая настроена для функционирования в режиме безопасности.

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

Для развертывания протокола Mutual TLS при наличии уже развернутой инфраструктуры открытых ключей необходимо:

1. создать запрос сертификата для каждого шлюза IP или АТС;
2. создать копию запроса сертификата, чтобы использовать ее для запроса сертификата у центра сертификации;
3. запросить сертификат у центра сертификации с помощью запроса сертификата; сохранить сертификат;
4. импортировать сохраненный сертификат на каждое устройство или компьютер;
5. загрузить доверенный корневой сертификат для своей инфраструктуры открытых ключей;
6. импортировать доверенный корневой сертификат из инфраструктуры открытых ключей на каждое устройство. При импорте доверенного корневого сертификата на компьютер Exchange 2010 с ролью сервера единой системы обмена сообщениями можно также с помощью групповой политики импортировать доверенный корневой сертификат в доверенное корневое хранилище сертификатов на сервере единой системы обмена сообщениями или на других серверах Exchange 2010. Вместе с тем, данный процесс используется также при настройке сервера, выполняющего роль сервера единой системы обмена сообщениями.

   Примечание.
   При использовании коммерческих сторонних сертификатов протокол Mutual TLS реализуется таким же образом.

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

• Дополнительные сведения о сертификатах см. в статье Инфраструктура открытого ключа для Windows Server 2003 (на английском языке).
• Советы и рекомендации по внедрению инфраструктуры открытых ключей Windows Server 2003 см. в статье Советы по внедрению инфраструктуры открытых ключей Microsoft Windows Server 2003 (на английском языке).
• Дополнительные сведения о способах развертывания инфраструктуры открытых ключей на базе Windows Server 2008 см. в статье Пример пошагового развертывания сертификатов инфраструктуры открытых ключей, необходимых для основного режима Configuration Manager: центр сертификации Windows Server 2008 (на английском языке).
• Дополнительные сведения о службах сертификации Windows Server 2008 для инфраструктуры открытых ключей на базе Windows Server 2008 см. в статье Обзор служб сертификатов Active Directory (на английском языке).

Сторонние центры сертификации

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

Для крупных организаций или для организаций, которым необходимо развертывать сертификаты для общего использования, применение сторонних (коммерческих) сертификатов — наилучшее решение, несмотря на связанные с этим расходы. Коммерческие сертификаты могут оказаться не лучшим решением для организаций малого и среднего размера, и может возникнуть необходимость в выборе другого доступного варианта использования сертификатов.

В зависимости от настройки шлюза IP или IP-АТС может сохраниться необходимость импорта стороннего или коммерческого сертификата в доверенное хранилище сертификатов на шлюзах IP и IP-АТС, чтобы получить возможность использования стороннего сертификата для протокола MTLS. Однако в некоторых случаях сторонний сертификат должен помещаться в доверенное корневое хранилище сертификатов на сервере единой системы обмена сообщениями и других компьютерах Exchange 2010 организации.

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

В начало

Настройка протокола MTLS

По умолчанию при получении входящего звонка из шлюза IP VoIP-трафик не шифруется, и для него не используется протокол Mutual TLS. Однако параметры безопасности для сервера единой системы обмена сообщениями настраиваются для абонентской группы единой системы обмена сообщениями, связанной с сервером единой системы обмена сообщениями. Чтобы настроить сервер единой системы обмена сообщениями для безопасного взаимодействия со шлюзами IP, УАТС на базе протокола IP и остальными серверами Exchange 2010, необходимо использовать командлет Set-UMDialPlan для настройки безопасности VoIP для абонентской группы единой системы обмена сообщениями, а затем включить протокол Mutual TLS для серверов единой системы обмена сообщениями, связанных с данной абонентской группой.

После включения безопасности VoIP для абонентской группы единой системы обмена сообщениями все серверы единой системы обмена сообщения, связанные с этой абонентской группой, могут взаимодействовать безопасным образом. Однако в зависимости от типа сертификата, используемого для протокола MTLS, необходимо сначала импортировать и экспортировать требуемые сертификаты и на серверы единой системы обмена сообщениями, и на шлюзы IP и IP-АТС. После импорта требуемого сертификата или сертификатов на сервер единой системы обмена сообщениями необходимо перезапустить службу единой системы обмена сообщениями Microsoft Exchange, чтобы появилась возможность использовать импортированные сертификаты для установления шифрованного канала со шлюзами IP или УАТС на базе протокола IP. Дополнительные сведения об импорте и экспорте сертификатов см. в статье Импорт и экспорт сертификатов (на английском языке).

После успешного импорта и экспорта необходимых доверенных сертификатов шлюз IP запрашивает сертификат у сервера единой системы обмена сообщениями, а затем запрашивается сертификат у шлюза IP. Обмен доверенными сертификатами между шлюзом IP и сервером единой системы обмена сообщениями позволяет обоим устройствам взаимодействовать по безопасному каналу с помощью протокола Mutual TLS. При получении шлюзом IP или УАТС на базе протокола IP входящего звонка инициируется обмен сертификатами и согласование безопасности с сервером единой системы обмена сообщениями по протоколу Mutual TLS. Служба единой системы обмена сообщениями Microsoft Exchange не участвует в процессе обмена сертификатами или в определении действительности сертификата. Однако если на сервере единой системы обмена сообщениями доверенный сертификат не обнаруживается или обнаруживается, но не является действительным, или звонок отклоняется по причине ошибки согласования по протоколу Mutual TLS, сервером единой системы обмена сообщениями будет получено уведомление от службы единой системы обмена сообщениями Microsoft Exchange.

Хотя служба единой системы обмена сообщениями Microsoft Exchange не участвует в обмене сертификатами между сервером единой системы обмена сообщениями и шлюзами IP, службой единой системы обмена сообщениями Microsoft Exchange выполняются следующие операции:

• Предоставление списка полных доменных имен службе речевого модуля Microsoft Exchange, чтобы принимались звонки только от тех шлюзов IP или УАТС на базе протокола IP, которые включены в данный список.
• Передача атрибутов issuerName и SerialNumber сертификата в службу речевого модуля Microsoft Exchange. Данные атрибуты однозначно идентифицируют сертификат, используемый сервером единой системы обмена сообщениями, когда шлюз IP или УАТС на базе протокола IP запрашивает сертификат.

После того как сервер единой системы обмена сообщениями и шлюзы IP или УАТС на базе протокола IP выполнили обмен ключами для установления шифрованного с помощью протокола Mutual TLS канала, серверы единой системы обмена сообщениями взаимодействуют со шлюзами IP и УАТС на базе протокола IP по шифрованному каналу. Серверы единой системы обмена сообщениями также взаимодействуют по шифрованному с помощью протокола Mutual TLS каналу и с другими серверами Exchange 2010, например серверами клиентского доступа и транспортными серверами-концентраторами. Однако протокол Mutual TLS используется только для шифрования трафика или сообщений, передаваемых с сервера единой системы обмена сообщениями на транспортный сервер-концентратор.

Важно!

Чтобы использовать протокол Mutual TLS при взаимодействии между шлюзом IP единой системы обмена сообщениями и абонентской группой, находящейся в безопасном режиме, необходимо сначала указать полное доменное имя шлюза IP единой системы обмена сообщениями и настроить его на прослушивание порта 5061. Чтобы настроить шлюз IP единой системы обмена сообщениями, выполните следующую команду: Set-UMIPGateway -Identity MyUMIPGateway -Port 5061.

В начало

Протокол IPsec

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

Применением протокола IPsec достигаются следующие цели:

• защита содержимого пакетов IP;
• защита от сетевых атак за счет фильтрации пакетов и применения доверенного взаимодействия.

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

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

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

• Локальная сеть   Клиент-сервер, сервер-сервер и сервер-устройство VoIP
• Глобальная сеть   Маршрутизатор-маршрутизатор и шлюз-шлюз
• Удаленный доступ   Клиенты удаленного доступа и доступ в Интернет из частных сетей

Обычно на обеих сторонах необходимо настроить протокол IPsec, чтобы установить такие значения параметров безопасности, которые позволят обеим системам согласовать защиту передаваемого между ними трафика. Это называется политикой IPsec. Реализации протокола IPsec на платформах Microsoft Windows 2000 Server, Windows XP, Windows Server 2003 и Windows Server 2008 основаны на отраслевых стандартах, разработанных рабочей группой по протоколу IPsec комитета Internet Engineering Task Force (IETF). Компоненты связанных с протоколом IPsec служб разработаны корпорацией Microsoft в сотрудничестве с корпорацией Cisco Systems, Inc. Дополнительные сведения о настройке политик IPsec см. в статье Создание, изменение и назначение политик IPsec (на английском языке).

Дополнительные сведения о протоколе IPsec см. в описании основных понятий IPSec.

Предупреждение

Если в настоящее время в сети реализованы политики IPsec, необходимо исключить из политики IPsec шлюзы IP и IP-АТС. Если этого не сделать, то каждые три секунды использования голосовой почты будет происходить односекундный обрыв передачи голоса. Это известная проблема, и в целях ее устранения выпущено исправление для Windows Server 2003. Дополнительные сведения о данном исправлении см. в описании инструкций по упрощению создания и поддержке фильтров безопасности Internet Protocol (IPsec) в Windows Server 2003 и Windows XP.

Абонентские группы единой системы обмена сообщениями и безопасность VoIP

В зависимости от конфигурации абонентской группы серверы единой системы обмена сообщениями могут взаимодействовать со шлюзами IP, УАТС на базе протокола IP и другими компьютерами Exchange 2010 в одном из трех режимов — небезопасном режиме, режиме с защитой SIP и безопасном режиме. Сервер единой системы обмена сообщениями может работать в любом из режимов, настроенных для абонентской группы, поскольку он настроен на одновременное прослушивание TCP-порта 5060 для незащищенных запросов и TCP-порта 5061 для защищенных запросов. Сервер единой системы обмена сообщениями можно связать с одной или несколькими телефонными группами единой системы обмена сообщениями, а также с телефонными группами, для которых установлены другие параметры безопасности VoIP. Один сервер единой системы обмена сообщениями можно связать с абонентскими группами, настроенными на использование сочетания безопасного режима, небезопасного режима и режима с защитой SIP.

При создании абонентской группы единой системы обмена сообщениями все данные по умолчанию передаются в небезопасном режиме, и все серверы единой системы обмена сообщениями, связанные с этой абонентской группой, обмениваются данными со шлюзами IP, УАТС на базе протокола IP и другими компьютерами Exchange 2010 без шифрования. В небезопасном режиме каналы данных протокола RTP и сигнальная информация протокола SIP передаются в незашифрованном виде.

Сервер единой системы обмена сообщениями можно настроить на использование протокола Mutual TLS, чтобы шифровать трафик SIP и RTP, передаваемый другим устройствам и серверам и получаемый от них. Когда сервер единой системы обмена сообщениями добавляется к абонентской группе этой системы и группа настраивается на использование режима с защитой SIP, будет шифроваться только сигнальный трафик SIP, а каналы данных протокола RTP по-прежнему будут использовать протокол TCP. TCP-трафик не шифруется. Однако когда сервер единой системы обмена сообщениями добавляется к абонентской группе этой системы и группа настраивается на использование безопасного режима, шифруются как сигнальный трафик SIP, так и каналы данных протокола RTP. Безопасный сигнальный канал данных, использующий протокол SRTP, также использует протокол MTLS для шифрования данных VoIP.

Режим безопасности VoIP можно настроить при создании абонентской группы или позднее с помощью консоли управления Exchange или командлета Set-UMDialPlan. Когда для абонентской группы единой системы обмена сообщениями включается безопасный режим или режим с защитой SIP, связанные с этой абонентской группой серверы единой системы обмена сообщениями будут шифровать сигнальный трафик SIP, трафик RTP или оба вида трафика. Однако чтобы иметь возможность обмена шифрованными данными с сервером единой системы обмена сообщениями, необходимо правильно настроить абонентскую группу этой системы, а устройства, такие как шлюзы IP и УАТС на базе протокола IP, должны поддерживать протокол Mutual TLS.

Чтобы определить параметры безопасности, заданные для конкретной абонентской группы единой системы обмена сообщениями, можно использовать командлет Get-UMDialPlan в командной консоли Exchange. Если включен параметр безопасности VoIP, можно убедиться, что служба единой системы обмена сообщениями Microsoft Exchange запущена в режиме безопасности, проверив наличие в журнале событий приложений событий с номерами 1114 и 1112.

Важно!

При настройке Mutual TLS для шифрования данных, которые передаются между шлюзом IP Dialogic 2000 или 4000, необходимо использовать шаблон сертификатов Computer V3, который поддерживает проверку подлинности серверов и клиентов. Шаблон сертификатов веб-сервера, который поддерживает проверку подлинности серверов, будет правильно работать только с шлюзами IP Dialogic 1000 и 3000, шлюзами IP AudioCodes и Microsoft Office Communications Server 2007.

В начало

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

При запуске службы единой системы обмена сообщениями Microsoft Exchange она проверяет связанные абонентские группы единой системы обмена сообщениями и настройку параметра VoipSecurity и определяет режим запуска — безопасный или небезопасный. Если служба определяет, что необходим запуск в безопасном режиме, выполняется проверка наличия доступа к необходимым сертификатам. Если сервер единой системы обмена сообщениями не связан ни с какими абонентскими группами единой системы обмена сообщениями, режим запуска определяется на основании значения параметра StartSecured в файле Msexchangeum.config. Параметр может принимать значение 0 или 1. Если установлено значение 1, то сервер единой системы обмена сообщениями будет выполнять шифрование VoIP-трафика. Если установлено значение 0, то сервер будет запущен, но VoIP-шифрование трафика выполняться не будет. Если необходимо изменить режим запуска сервера единой системы обмена сообщениями с безопасного на небезопасный или наоборот, можно связать данный сервер с соответствующими абонентскими группами единой системы обмена сообщениями и затем перезапустить его. Можно также изменить параметр настройки в файле конфигурации Msexchangeum.config и перезапустить службу единой системы обмена сообщениями Microsoft Exchange.

Если служба единой системы обмена сообщениями Microsoft Exchange запускается в небезопасном режиме, она запустится как обычно. Однако необходимо проверить, что шлюзы IP и УАТС на базе протокола IP также работают в небезопасном режиме. Кроме того, для проверки работоспособности сервера единой системы обмена сообщениями в небезопасном режиме следует использовать командлет Test-UMConnectivity с параметром -Secured:false. 

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

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

• имя поставщика;
• серийный номер;
• отпечаток.

Отпечаток представляет собой хэш SHA1 и может использоваться для однозначной идентификации используемого сертификата. После этого сертификат, используемый службой единой системы обмена сообщениями Microsoft Exchange для запуска в безопасном режиме, можно экспортировать из локального хранилища сертификатов и импортировать его в доверенное хранилище сертификатов шлюзов IP и УАТС на базе протокола IP.

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

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

1. сертификаты инфраструктуры открытых ключей или коммерческие сертификаты с максимальным сроком действия;

2. сертификаты инфраструктуры открытых ключей или коммерческие сертификаты с минимальным сроком действия;

3. самозаверяющие сертификаты с максимальным сроком действия;

4. самозаверяющие сертификаты с минимальным сроком действия. Требуется действующий коммерческий сертификат, самозаверяющий сертификат или сертификат на основе инфраструктуры открытых ключей. Если действующий сертификат найти не удается, сервер единой системы обмена сообщениями создает самозаверяющий сертификат. Сертификат нужен серверу единой системы обмена сообщениями для шифрования VoIP-трафика при работе в режиме с защитой SIP или безопасном режиме.

   Важно!

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

В начало