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

Эти моменты имеют решающее значение для успешного развертывания службы вызовов гибридного типа для устройств Webex. Этим вопросам уделяется особое внимание по следующим причинам.

• Мы хотим дать им объяснение, чтобы обеспечить понимание их роли в развертывании гибридного типа.

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

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

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

Развертывание пары Expressway-C и Expressway-E позволяет совершать вызовы в Интернет и из Интернета с помощью технологий обхода брандмауэра. Это развертывание обеспечивает безопасное локальное управление вызовами и связывает их с Webex.

Для Expressway-C и Expressway-E не требуется какой-либо открытый порт для входящих соединений в демилитаризованной зоне (ДМЗ) брандмауэра вследствие архитектуры обхода брандмауэра. Однако порты сигналов SIP TCP и порты мультимедиа UDP должны быть открыты для входящих соединений в брандмауэре Интернета, чтобы обеспечить поступление входящих вызовов. Необходимо предоставить время для открытия соответствующего порта в брандмауэре компании.

Архитектура обхода брандмауэра представлена на следующей диаграмме.

Например, для входящих вызовов "бизнес для бизнеса" (B2B) с использованием протокола SIP порты TCP 5060 и 5061 (5061 используется для SIP TLS) должны быть открыты во внешнем брандмауэре вместе с портами мультимедиа UDP, которые используются для таких служб, как голосовая связь, видео, совместный доступ к контенту, двойное видео и т. д. Необходимость открытия определенного порта обуславливается количеством параллельных вызовов и количеством служб.

Для порта прослушивания SIP на Expressway можно указать любое значение в диапазоне от 1024 до 65534. В то же время это значение и тип протокола должны быть объявлены в общедоступных записях SRV DNS, и это же значение должно быть открыто в брандмауэре Интернета.

Несмотря на то, что для SIP TCP стандартным является порт 5060, а для SIP TLS – порт 5061, ограничения на использование других портов отсутствуют (см. следующий пример).

Пример

На этом примере подразумевается, что порт 5062 используется для входящих вызовов SIP TLS.

Запись SRV DNS для кластера двух серверов Expressway выглядит следующим образом:

_sips._tcp.пример.com местоположение службы SRV:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.пример.com местоположение службы SRV:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

Эти записи означают, что вызовы перенаправляются на us-expe1.example.com и us-expe2.example.com с равномерным распределением нагрузки (priority и weight) с помощью TLS в качестве типа передачи данных и 5062 в качестве номера порта прослушивания.

Устройство, которое находится за пределами сети (в Интернете) и совершает вызов SIP пользователю корпоративного домена (user1@example.com), должно запрашивать DNS, чтобы определить, какой тип передачи данных следует использовать, номер порта, условия распределения нагрузки трафика, а также на какие серверы SIP следует отправить вызов.

Если запись DNS включает _sips._tcp, запись указывает TLS SIP.

TLS является протоколом соединения "клиент-сервер" и в наиболее распространенных решениях для аутентификации использует сертификаты. В сценариях вызова "бизнес для бизнеса" клиентом TLS является вызывающее устройство, а сервером TLS – вызываемое устройство. При использовании TLS клиент проверяет сертификат сервера, и если проверка сертификата не удалась, происходит завершение вызова. Для клиента сертификат не требуется.

Подтверждение TLS представлено на следующей схеме.

Однако спецификацией TLS установлено, что сервер также может выполнить проверку сертификата клиента, отправив клиенту сообщение с запросом сертификата во время протокола подтверждения TLS. Это сообщение полезно при подключении между сервером, например во время вызова, установленного между Expressway-E и облаком Webex. Эта концепция называется TLS с взаимной аутентификацией и является обязательной при интеграции с Webex.

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

Облако выполняет проверку удостоверения Expressway, а Expressway проверяет удостоверение облака. Например, если удостоверение облака в сертификате (стандартное или альтернативное имя) не соответствует настройкам Expressway, соединение будет разорвано.

Если взаимная аутентификация включена, Expressway-E всегда будет запрашивать сертификат клиента. В результате доступ с мобильных устройств и удаленный доступ (MRA) не будет работать, поскольку в большинстве случаев для клиентов Jabber развертывание сертификатов не производится. Если в сценариях вызова "бизнес для бизнеса" вызывающий объект не может предоставить сертификат, вызов будет отключен.

Рекомендуется не использовать значение порта 5061 для TLS с взаимной аутентификацией, а использовать другое значение, например 5062. Гибридные службы Webex используют ту же запись TLS SIP, которая используется для B2B. В случае использования порта 5061 некоторые службы, которые не могут предоставить сертификат клиента TLS, не будут работать.

Если существующая запись уже используется для взаимодействия "бизнес для бизнеса", рекомендуется указать поддомен корпоративного домена в качестве назначения SIP в Control Hub и, следовательно, общедоступную запись SRV DNS, как указано ниже.

 Служба и протокол: _sips._tcp.mtls.example.com Приоритет: 1 Вес: 10 Номер порта: 5062 Цель: us-expe1.example.com 

Доступ "бизнес для бизнеса", доступ с мобильных устройств и удаленный доступ, а также трафик Webex на одной и той же паре Expressway

При вызовах "бизнес для бизнеса" (B2B), а также доступе с мобильных устройств и удаленном доступе (MRA) для SIP TLS используется порт 5061, а трафик Webex для SIP TLS с взаимной аутентификацией используется порт 5062.

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

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

1. Проверка права собственности на домен. Этот этап выполняется один раз и включает проверку доменов трех типов:

   • домен электронной почты;

   • домен DNS Expressway-E;

   • домен URI каталога.

2. Проверка права собственности на имя DNS Expressway-E. Этот этап выполняется посредством реализации TLS с взаимной аутентификацией и использования общедоступных сертификатов в облаке и Expressway. В отличие от проверки удостоверения домена, этот этап выполняется во время всех входящих и исходящих вызовов в облаке.

Важность проверки права собственности на домен

Для обеспечения безопасности облако Webex выполняет проверку права собственности на домен. Одна из возможных угроз при отсутствии такой проверки – кража удостоверения.

Ниже описываются возможные последствия, если проверка права собственности на домен не будет выполнена.

Компания, у которой установлен домен DNS "hacker.com", приобретает службы гибридного типа Webex. Другая компания, владеющая собственным доменом "example.com", также пользуется службами гибридного типа. Один из руководителей компании Example.com по имени Джейн Роу является владельцем URI каталога jane.roe@example.com.

Администратор компании Hacker.com настраивает в одном из своих URI каталога значение "jane.roe@example.com" и адрес электронной почты jane.roe@hacker.com. Это можно сделать, поскольку в этом примере облако не проверяет домен URI SIP.

Затем она входит в приложение Webex с помощью jane.roe@hacker.com. Так как ей принадлежит право собственности на домен, электронное сообщение для проверки прочтено и ответ получен; можно выполнить вход. Наконец, она звонит коллеге Джону Доу, набрав john.doe@example.com из своего приложения Webex. Джон сидит в своем офисе и видит на своем видеоустройстве вызов, поступивший от jane.roe@example.com. Это URI каталога, связанный с этой учетной записью электронной почты.

"Она за границей, – подумал Джон, – возможно, у нее важное дело." Он отвечает на звонок, и фиктивная Джейн Роу просит переслать ей важные документы. Она объясняет, что ее устройство сломалось. А поскольку она путешествует, то просит отправить документы на ее личный адрес электронной почты jane.roe@hacker.com. О том, что произошла утечка важной информации, компания осознает только после возвращения Джейн Роу.

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

Для проверки удостоверения Webex требует, чтобы компания подтвердила право собственности на домены, используемые в вызовах гибридного типа. В противном случае службы гибридного типа не будут работать.

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

1. Подтверждение права собственности компании на домены электронной почты, Expressway-E и URI каталога.

   • Все эти домены должны быть маршрутизируемыми и известными посредством общедоступных серверов DNS.

   • Чтобы подтвердить право собственности, администратор DNS должен ввести текстовую запись DNS (запись TXT). Запись TXT является типом записи ресурса в DNS, который предоставляет возможность связывания произвольного неформатированного текста с узлом или другим именем.

   • Администратор DNS должен ввести эту запись TXT в зоне, чье право собственности должно быть подтверждено. После этого облако Webex выполнит запрос записи TXT для этого домена.

   • Если запрос TXT успешно выполнен и результат соответствует маркеру, созданному в облаке Webex, домен будет подтвержден.

   • Например, если необходимо, чтобы службы гибридного типа Webex работали в своем домене, администратор должен подтвердить право собственности на домен "example.com".

   • С помощью https://admin.webex.com она начинает процесс проверки, создав запись TXT для соответствия маркеру, созданному облаком Webex.

     

   • Затем администратор DNS создает запись TXT для этого домена со значением 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, как показано в следующем примере:

     

   • На данном этапе облако может проверить, соответствует ли маркеру запись TXT для домена example.com.

   • Облако выполнит поиск TXT в DNS.

     

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

2. Проверка права собственности на имя DNS Expressway-E.

   • Облако должно проверить наличие у Expressway-E удостоверения, подтвержденного одним из центров сертификации, которому установлено доверие в облаке. Администратор Expressway-E должен подать запрос на общедоступный сертификат для Expressway-E в один из этих центров сертификации. Чтобы издать сертификат, центр сертификации выполняет процесс проверки удостоверения на основе проверки достоверности домена (для сертификатов проверки домена) или проверки достоверности организации (для сертификатов проверки организации).

   • Входящие и исходящие вызовы в облаке зависят от сертификата, который был выдан для Expressway-E. Если сертификат недействителен, вызов будет прерван.

Чтобы вызовы гибридного типа работали, соединитель Webex Device должен взаимодействовать с Webex.

Соединитель Webex Device развернут во внутренней сети, а способ связи с облаком осуществляется посредством исходящего соединения HTTPS – того же типа, который используется для любого браузера, подключающегося к веб-серверу.

Для связи с облаком Webex используется TLS. Соединитель Webex Device является клиентом TLS, а облако Webex – сервером TLS. Таким образом, соединитель Webex Device проверяет сертификат сервера.

Центр сертификации подписывает сертификат сервера с помощью собственного закрытого ключа. С помощью открытого ключа можно расшифровать эту подпись и подтвердить, что этот сертификат подписан тем же центром сертификации.

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

При взаимодействии с устройствами инструмент использует предоставленные вами доверенные сертификаты. В настоящее время это можно сделать, поместив их в [домашнюю папку]/.devicestool/certs.

Список сертификатов центра сертификации также требуется для Expressway-E, который используется в паре для обхода. Expressway-E взаимодействует с облаком Webex с помощью SIP и TLS, что обеспечивается взаимной аутентификацией. Expressway-E доверяет вызовам, поступающим из облака и поступающим в него, только если CN или SAN сертификата, представленного облаком во время настройки соединения TLS, совпадает с именем субъекта, настроенным для зоны DNS в Expressway ("callservice.webex.com"). Центр сертификации осуществляет выпуск сертификата только после проверки удостоверения. Для получения подписанного сертификата необходимо подтвердить право собственности на домен callservice.webex.com. Поскольку этот домен принадлежит нам (Cisco), DNS-имя callservice.webex.com напрямую доказывает, что удаленный одноранговый узел действительно является Webex.

соединитель календаря интегрирует Webex с Microsoft Exchange 2013, 2016, 2019 или Office 365 с помощью учетной записи от себя. Роль управления олицетворением приложения в Exchange позволяет приложениям выполнять олицетворение пользователей в организации для выполнения задач от имени определенного пользователя. Роль отстоятеля приложения должна быть настроена в Exchange и используется в соединителье календаря как часть конфигурации Exchange на Expressway-C.

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

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

Для обеспечения дополнительной безопасности выполните действия, следующие действия в Expressway соединители календаря для Microsoft Exchange , чтобы включить TLS для обеспечения безопасности проводных соединений EWS.