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

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

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

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

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

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

Развертывание пары Expressway-C и Expressway-E позволяет использовать технологию обхода брандмауэра для входящих и исходящих интернет-вызовов. Это развертывание обеспечивает безопасное локальное управление вызовами и связывает их в Cisco 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.example.com SRV service location:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

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, значит, используется SIP TLS.

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

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

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

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

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

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

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

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

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

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

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

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

    • Затребовать домен

    • домен DNS Expressway-E;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • К примеру, при необходимости использования служб гибридного типа Cisco Webex в своем домене администратор должен подтвердить право собственности на домен "example.com".

    • На веб-сайте https://admin.webex.com администратор запускает процесс проверки посредством создания записи TXT для соответствия маркеру, созданному облаком Cisco Webex.
    • Затем администратор DNS создает запись TXT для этого домена, указав значение 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, как показано в следующем примере.
    • На данном этапе облако может проверить, соответствует ли маркеру запись TXT для домена example.com.

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

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

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

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

Узел соединителя Expressway-C должен быть зарегистрирован в Cisco Webex для работы служб гибридного типа.

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

Регистрация и связь с облаком Cisco Webex осуществляется с помощью TLS. Expressway-C является клиентом TLS, а облако Cisco Webex – сервером TLS. Соответственно, Expressway-C выполняет проверку сертификата сервера.

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

Если Expressway-C выполняет проверку сертификата, предоставленного облаком, для расшифровки подписи должен использоваться открытый ключ центра сертификации, подписавшего этот сертификат. Открытый ключ содержится в сертификате центра сертификации. Чтобы установить доверие центру сертификации, который используется облаком, список сертификатов этого доверенного центра сертификации должен находиться в зоне доверия Expressway. Таким образом Expressway может проверить, действительно ли вызов поступает из облака Cisco Webex.

Все соответствующие сертификаты центра сертификации можно вручную загрузить в зоне доверия Expressway-C.

При выборе автоматической загрузки облако самостоятельно загружает эти сертификаты в зону доверия Expressway-C. Рекомендуется выполнять автоматическую загрузку. Список сертификатов может изменяться, поэтому при автоматической загрузке вы гарантированно получите список со всеми обновлениями.

В случае разрешения автоматической установки сертификата центра сертификации вы будете перенаправлены на веб-сайт https://admin.webex.com (портал управления). Expressway-C осуществляет перенаправление без участия пользователя. Администратор Cisco Webex должен выполнить аутентификацию посредством соединения HTTPS. После этого облако отправляет сертификат ЦС в Expressway-C.

Пока сертификаты не будут загружены в зону доверия Expressway-C, соединение HTTPS не может быть установлено.

Во избежание этой проблемы в Expressway-C осуществляется предварительная установка сертификатов ЦС, которым установлено доверие Cisco Webex. Эти сертификаты используются только для настройки и проверки предварительного соединения HTTPS. Они не отображаются в списке доверия Expressway-C. Когда сертификаты доверенного центра сертификации будут получены из облака посредством этого предварительного соединения HTTPS, эти сертификаты становятся доступными для общеплатформенного использования, а затем отображаются в списке доверия Expressway-C.

Этот процесс безопасен в силу следующих причин.
  • Требуется административный доступ в Expressway-C и на веб-сайт https://admin.webex.com. Эти соединения используют HTTPS и зашифрованы.

  • Сертификаты отправляются из облака в Expressway с помощью того же зашифрованного соединения.

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

  • C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

  • C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

  • C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

  • C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

  • C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

  • C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

  • C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

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

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

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