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

Ці пункти мають вирішальне значення, якщо ви бажаєте успішно розгорнути Hybrid Calling для пристроїв Webex. Ми виділили ці пункти, зокрема, з таких причин:

• Ми хочемо пояснити їх, щоб ви зрозуміли їхню роль у гібридному розгортанні та відчули заспокоєння.

• Вони є обов'язковими передумовами, які забезпечують безпечне розгортання між нашою хмарою та вашим локальним середовищем.

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

• Після того як ці елементи буде вирішено у вашому середовищі, решта конфігурації гібридних служб буде працювати гладко.

Розгортання пари Expressway-C і Expressway-E дозволяє здійснювати виклики з Інтернету та з нього за допомогою технологій обходу брандмауера. Це розгортання забезпечує безпечне перенесення вашого локального керування викликами і зв’язує його з Webex.

Швидкісна автомагістраль C і Expressway-E не вимагають відкриття будь-якого вхідного порту в брандмауері демілітаризованої зони (DMZ) через архітектуру обходу брандмауера. Але сигнальні порти TCP SIP і медіапорти UDP повинні бути відкриті на вході в інтернет-брандмауер, щоб пропускати вхідні дзвінки. Ви повинні дати час, щоб відповідний порт був відкритий у корпоративному брандмауері.

Архітектура обходу брандмауера показана на наступній схемі:

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

Ви можете налаштувати порт прослуховування SIP на Expressway на будь-яке значення від 1024 до 65534. При цьому це значення і тип протоколу повинні рекламуватися в публічних записах DNS SRV, і це ж значення повинно бути відкрито в інтернет-брандмауері.

Хоча стандартом для SIP TCP є 5060, а для SIP TLS 5061, ніщо не перешкоджає використанню різних портів, як показує наступний приклад.

Приклад

У цьому прикладі ми припускаємо, що порт 5062 використовується для вхідних викликів SIP TLS.

Запис DNS SRV для кластера з двох серверів Expressway виглядає так:

_sips._tcp.example.com розташування служби SRV:

пріоритет = 10

вага = 10

порт = 5062

svr ім'я хоста = us-expe1.example.com

_sips._tcp.example.com розташування служби SRV:

пріоритет = 10

вага = 10

порт = 5062

svr ім'я хоста = us-expe2.example.com

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

Пристрій, який є зовнішнім по відношенню до мережі (в Інтернеті) і який здійснює SIP-виклик користувачеві корпоративного домену (user1@example.com), повинен запитати DNS, щоб зрозуміти, який тип транспорту використовувати, номер порту, як завантажувати-ділитися трафіком і на які SIP-сервери відправляти виклик.

Якщо запис DNS містить _sipsзначення ._tcp, у записі вказується SIP TLS.

TLS є клієнт-серверним протоколом і в найбільш поширених реалізаціях використовує сертифікати для аутентифікації. У сценарії дзвінків від бізнесу до бізнесу клієнт TLS є пристроєм виклику, а сервер TLS - пристроєм, який називається. За допомогою TLS клієнт перевіряє сертифікат сервера, і якщо перевірка сертифіката не вдається, він відключає виклик. Клієнту сертифікат не потрібен.

Рукостискання TLS показано на наступній схемі:

Однак у специфікації TLS зазначено, що сервер також може перевірити сертифікат клієнта, надіславши клієнту повідомлення про запит сертифіката під час протоколу рукостискання TLS. Це повідомлення є корисним у з’єднанні між сервером і сервером, наприклад під час виклику, що встановлюється між Expressway-E та хмарою Webex. Ця концепція називається TLS із взаємною автентифікацією, і вона є обов’язковою для інтеграції з Webex.

Як сторони, що телефонують, так і викликані сторони перевіряють сертифікат іншого однолітка, як показує наступна схема:

Хмара перевіряє ідентичність швидкісної дороги, а Expressway перевіряє ідентичність хмари. Наприклад, якщо хмарний ідентифікатор у сертифікаті (CN або SAN) не відповідає тому, що настроєно на швидкісній автомагістралі, з'єднання розривається.

Якщо взаємна аутентифікація ввімкнена, Expressway-E завжди запитує сертифікат клієнта. В результаті мобільний і віддалений доступ (MRA) не працюватимуть, оскільки в більшості випадків сертифікати не розгортаються на клієнтах Jabber. У сценарії business-to-business, якщо суб'єкт, що телефонує, не може надати сертифікат, дзвінок відключається.

Ми рекомендуємо використовувати значення, відмінне від 5061, для TLS для взаємної автентифікації, наприклад порт 5062. Служби Webex гібридного типу використовують той самий запис SIP TLS, що й для B2B. У випадку з портом 5061 деякі інші послуги, які не можуть надати сертифікат клієнта TLS, не працюватимуть.

Якщо наявний запис уже використовується для ділових комунікацій, рекомендовано вказати субдомен корпоративного домену як пункт призначення SIP у Control Hub і, як наслідок, загальнодоступний запис DNS SRV, як таке:

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

Бізнес-бізнес, мобільний і віддалений доступ, а також трафік Webex на одній парі Expressway

У викликах «Бізнес-бізнес» (B2B) і мобільний і віддалений доступ (MRA) використовується порт 5061 для SIP TLS, а трафік Webex використовує порт 5062 для SIP TLS із взаємною автентифікацією.

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

Перевірка особистості виконується в два етапи:

1. Перевірка права власності на домен. Цей крок включає в себе три типи доменів і являє собою одноразову перевірку перевірки:

   • Домен електронної пошти

   • Домен EXPRESSWAY-E DNS

   • Каталог доменів URI

2. Перевірка права власності на ім'я EXPRESSWAY-E DNS. Цей крок виконується за допомогою впровадження TLS з взаємною аутентифікацією і передбачає використання публічних сертифікатів як на хмарі, так і на швидкісній трасі. На відміну від перевірки ідентичності домену, цей крок виконується під час будь-якого дзвінка, здійсненого та отриманого з хмари.

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

Хмара Webex виконує перевірку власності на домен для забезпечення безпеки. Крадіжка особистих даних є однією з можливих загроз, якщо ця перевірка не буде виконана.

У наведеній нижче історії докладно описано, що може статися, якщо не буде проведено перевірку права власності на домен.

Компанія з доменом DNS, установленим на "hacker.com", купує служби Webex Hybrid Services. Інша компанія, з власним доменом, встановленим на "example.com", також користується гібридними сервісами. Один з генеральних менеджерів компанії Example.com носить ім'я Джейн Роу і має каталог URI jane.roe@example.com.

Адміністратор Hacker.com компанії встановлює один зі своїх URI каталогу для jane.roe@example.com, а адресу електронної пошти jane.roe@hacker.com. Вона може це зробити, оскільки хмара не перевіряє домен SIP URI в цьому прикладі.

Далі вона входить в програму Webex за допомогою jane.roe@hacker.com. Оскільки вона володіє доменом, електронний лист для підтвердження читається та відповідається, і вона може ввійти. Нарешті, вона телефонує колезі, Джону Доу, набравши john.doe@example.com із своєї програми Webex. Джон сидить у своєму офісі і бачить виклик на своєму відеопристрої з jane.roe@example.com; це URI каталогу, пов’язаний із цим обліковим записом електронної пошти.

"Вона за кордоном", - думає він. "Можливо, їй знадобиться щось важливе". Він відповідає на телефонні дзвінки, а фальшива Джейн Роу просить важливі документи. Вона пояснює, що її пристрій зламаний, і оскільки вона подорожує, вона просить його надіслати документи на її приватну електронну адресу, jane.roe@hacker.com. Таким чином, компанія розуміє лише після того, як Джейн Роу повертається в офіс, що важлива інформація була просочена за межі компанії.

Компанія Example.com має багато способів захистити від шахрайських викликів, які надходять з Інтернету, але одна з обов’язків хмари Webex полягає в тому, щоб упевнитися, що ідентифікаційні дані будь-кого, хто телефонує з Webex, правильні та не підроблені.

Щоб перевірити особу, Webex вимагає, щоб компанія довела, що вона володіє доменами, які використовуються в Hybrid Calling. Якщо ні, гібридні служби не працюватимуть.

Щоб забезпечити це право власності, потрібні два кроки перевірки домену:

1. Доведіть, що компанія володіє доменом електронної пошти, доменом Expressway-E, доменом Directory URI.

   • Усі ці домени повинні бути маршрутизовані та відомі публічним DNS-серверам.

   • Щоб підтвердити право власності, адміністратор DNS повинен ввести текстовий запис DNS (TXT). Запис TXT — це тип запису ресурсу в службі DNS, який використовується для надання можливості пов'язувати деякий довільний і неформатований текст з хостом або іншим іменем.

   • Адміністратор DNS повинен ввести цей запис TXT в зоні, право власності на яку необхідно довести. Після цього кроку хмара Webex виконує запит запису TXT для цього домену.

   • Якщо запит TXT буде успішним і результат збігається з токеном, який було створено з хмари Webex, домен перевіряється.

   • Наприклад, адміністратор має довести, що вона володіє доменом «example.com», якщо вона хоче, щоб служби Webex Hybrid Services працювали над її доменом.

   • Через https://admin.webex.com вона розпочинає процес перевірки, створивши запис TXT, щоб він відповідав токена, який створила хмара Webex:

     

   • Потім адміністратор DNS створює запис TXT для цього домену зі значенням 123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef, як у такому прикладі:

     

   • На цьому етапі хмара може перевірити, чи відповідає запис TXT для домену example.com токену.

   • Хмара виконує пошук TXT DNS:

     

   • Оскільки значення TXT збігається зі значенням токена, цей збіг доводить, що адміністратор додав запис TXT для свого власного домену до загальнодоступного DNS і що вона володіє доменом.

2. Перевірка права власності на ім'я DNS Expressway-E.

   • Хмара повинна перевірити, чи має Expressway-E підтверджену особу від одного з центрів сертифікації, яким довіряє хмара. Адміністратор Expressway-E повинен запросити публічний сертифікат для своєї швидкісної автомагістралі-E в одному з цих центрів сертифікації. Щоб видати сертифікат, центр сертифікації виконує процес перевірки ідентичності на основі перевірки валідації домену (для сертифікатів, підтверджених доменом) або перевірки валідації організації (для перевірених організацією сертифікатів).

   • Дзвінки в хмару і з неї залежать від сертифіката, який був виданий швидкісній автомагістралі-Е. Якщо сертифікат недійсний, виклик відпадає.

З’єднувач пристроїв Webex має зв’язатися з Webex, щоб служба гібридних викликів працювала.

З’єднувач пристроїв Webex розгорнуто у внутрішній мережі, а спосіб він зв’язується з хмарою через вихідне з’єднання HTTPS. Цей тип використовується для будь-якого браузера, який підключається до вебсервера.

Зв’язок із хмарою Webex використовує TLS. З’єднувач пристроїв Webex є клієнтом TLS, а хмара Webex є сервером TLS. Таким чином, з’єднувач пристроїв Webex перевіряє сертифікат сервера.

Центр сертифікації підписує сертифікат сервера за допомогою власного закритого ключа. Будь-який користувач, який має відкритий ключ, може розшифрувати цей підпис і довести, що той самий центр сертифікації підписав цей сертифікат.

Якщо З’єднувач пристроїв Webex має перевірити сертифікат, наданий хмарою, він повинен використовувати відкритий ключ центру сертифікації, який підписав цей сертифікат, для декодування підпису. Відкритий ключ міститься в сертифікаті центру сертифікації. Щоб установити довіру до органів сертифікації, що використовуються хмарою, список сертифікатів цих довірених органів сертифікації має бути в сховищі довірених органів сертифікації Webex.

Під час зв’язку з пристроями інструмент використовує надані вами довірені сертифікати. Зараз ми можемо це зробити, розмістивши їх у [домашню папку]/.devicestool/certs.

Список сертифікатів центру сертифікації також необхідний для швидкісної дороги-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 є рекомендованим методом Microsoft для цього завдання. Адміністраторам Expressway-C не потрібно знати пароль, оскільки значення може ввести в інтерфейс Expressway-C адміністратор Exchange. Пароль чітко не відображається, навіть якщо адміністратор Expressway-C має root-доступ до вікна Expressway-C. Пароль зберігається в зашифрованому вигляді за допомогою того ж механізму шифрування облікових даних, що й інші паролі на Expressway-C.

Для додаткової безпеки виконайте дії, наведені в посібнику з розгортання для служби гібридного календаря Cisco Webex, щоб увімкнути TLS для захисту з 'єднань EWS на дроті.

Щоб отримати додаткову безпеку, виконайте вказівки в розділі Розгортання роз 'єму календаря швидкісних автомагістралей для Microsoft Exchange, щоб увімкнути TLS для захисту з' єднань EWS на дроті.