Táto časť poskytuje dodatočný kontext o kľúčových položkách konfigurácie, ktoré súvisia s hybridnými službami.

Tieto body sú kľúčové, ak chcete úspešne nasadiť Hybrid Calling pre zariadenia Webex. Tieto položky sme zdôraznili najmä z nasledujúcich dôvodov:

• Chceme ich vysvetliť, aby ste pochopili ich úlohu v hybridnom nasadení a cítili sa bezpečne.

• Sú to povinné predpoklady, ktoré zaisťujú bezpečné nasadenie medzi naším cloudom a vaším lokálnym prostredím.

• Mali by sa považovať za aktivity pred nulou: ich dokončenie môže trvať o niečo dlhšie ako pri typickej konfigurácii v používateľskom rozhraní, takže na zoradenie týchto položiek ponechajte časový rámec.

• Po vyriešení týchto položiek vo vašom prostredí bude zvyšok konfigurácie hybridných služieb prebiehať hladko.

Nasadenie páru Expressway-C a Expressway-E umožňuje volania na internet a z internetu pomocou technológií prechodu brány firewall. Toto nasadenie je to, čo bezpečne prevezme kontrolu vašich lokálnych hovorov a spojí ich s Webexom.

Expressway-C a Expressway-E nevyžadujú, aby bol v demilitarizovanej zóne (DMZ) firewall otvorený žiadny prichádzajúci port, kvôli architektúre prechodu firewallu. Signalizačné porty TCP SIP a mediálne porty UDP však musia byť otvorené na internetovej bráne firewall, aby mohli prichádzajúce hovory prechádzať. Musíte si nechať čas na otvorenie príslušného portu na vašej podnikovej bráne firewall.

Architektúra prechodu brány firewall je znázornená na nasledujúcom diagrame:

Napríklad pre prichádzajúce hovory typu business-to-business (B2B) pomocou protokolu SIP musia byť na externom firewalle otvorené porty TCP 5060 a 5061 (5061 sa používa pre SIP TLS) spolu s mediálnymi portami UDP používanými pre služby, ako je hlas , video, zdieľanie obsahu, duálne video atď. Ktoré mediálne porty otvoriť, závisí od počtu súbežných hovorov a počtu služieb.

Port na počúvanie SIP na Expressway môžete nakonfigurovať na akúkoľvek hodnotu medzi 1024 až 65534. Zároveň musí byť táto hodnota a typ protokolu zverejnená vo verejných záznamoch DNS SRV a rovnaká hodnota musí byť otvorená na internetovom firewalle.

Hoci štandardom pre SIP TCP je 5060 a pre SIP TLS 5061, nič nebráni použitiu rôznych portov, ako ukazuje nasledujúci príklad.

Príklad

V tomto príklade predpokladáme, že port 5062 sa používa na prichádzajúce hovory SIP TLS.

Záznam DNS SRV pre klaster dvoch serverov Expressway vyzerá takto:

_sips._tcp.example.com umiestnenie služby SRV:

priorita = 10

hmotnosť = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com umiestnenie služby SRV:

priorita = 10

hmotnosť = 10

port = 5062

svr hostname = us-expe2.example.com

Tieto záznamy znamenajú, že hovory sú smerované na us-expe1.example.com a us-expe2.example.com s rovnakým zdieľaním zaťaženia (priorita a váha) pomocou TLS ako typu dopravy a 5062 ako číslo portu počúvania.

Zariadenie, ktoré je externé pre sieť (na internete) a ktoré uskutočňuje volanie SIP používateľovi v podnikovej doméne (user1@example.com), sa musí dotazovať DNS, aby pochopilo, ktorý typ prenosu použiť, číslo portu, ako na zdieľanie záťaže a na ktoré servery SIP poslať hovor.

Ak položka DNS obsahuje _sips._tcp, položka špecifikuje SIP TLS.

TLS je protokol klient-server a v najbežnejších implementáciách používa na autentifikáciu certifikáty. V scenári hovoru medzi podnikmi je klient TLS volajúcim zariadením a server TLS je volaným zariadením. Pri TLS klient skontroluje certifikát servera a ak kontrola certifikátu zlyhá, odpojí hovor. Klient nepotrebuje certifikát.

TLS handshake je znázornený na nasledujúcom diagrame:

V špecifikácii TLS sa však uvádza, že server môže tiež skontrolovať certifikát klienta odoslaním správy so žiadosťou o certifikát klientovi počas protokolu TLS handshake. Táto správa je užitočná pri pripojení server-to-server, napríklad pri hovore, ktoré je vytvorené medzi Expressway-E a cloudom Webex. Tento koncept sa nazýva TLS so vzájomnou autentifikáciou a vyžaduje sa pri integrácii s Webexom.

Volajúci aj volaní účastníci kontrolujú certifikát druhého partnera, ako ukazuje nasledujúci diagram:

Cloud kontroluje identitu Expressway a Expressway kontroluje identitu cloudu. Ak sa napríklad identita cloudu v certifikáte (CN alebo SAN) nezhoduje s tým, čo je nakonfigurované na Expressway, pripojenie sa zruší.

Ak je vzájomná autentifikácia zapnutá, Expressway-E vždy požaduje certifikát klienta. V dôsledku toho nebude mobilný a vzdialený prístup (MRA) fungovať, pretože vo väčšine prípadov nie sú certifikáty nasadené na klientoch Jabber. V scenári typu business-to-business, ak volajúca entita nie je schopná poskytnúť certifikát, hovor sa odpojí.

Odporúčame vám použiť inú hodnotu ako 5061 pre TLS so vzájomnou autentifikáciou, napríklad port 5062. Hybridné služby Webex používajú rovnaký záznam SIP TLS ako pre B2B. V prípade portu 5061 nebudú fungovať niektoré ďalšie služby, ktoré nedokážu poskytnúť certifikát klienta TLS.

Ak sa už existujúci záznam používa na komunikáciu medzi podnikmi, odporúčame zadať subdoménu podnikovej domény ako cieľ SIP v Control Hub a následne verejný záznam DNS SRV, a to nasledovne:

 Služba a protokol: _sips._tcp Priorita .mtls.example.com: 1 Hmotnosť: 10 Číslo portu: 5062 Cieľ: us-expe1.example.com 

Business-to-Business, mobilný a vzdialený prístup a prevádzka Webex na rovnakom páre Expressway

Hovory typu Business-to-business (B2B) a Mobile and Remote Access (MRA) využívajú port 5061 pre SIP TLS a prevádzka Webexu využíva port 5062 pre SIP TLS so vzájomnou autentifikáciou.

Kontrola vlastníctva domény je súčasťou overenia identity. Overenie domény je bezpečnostné opatrenie a kontrola identity, ktorú cloud Webex implementuje, aby dokázal, že ste tým, za koho sa vydávate.

Kontrola identity prebieha v dvoch fázach:

1. Kontrola vlastníctva domény. Tento krok zahŕňa tri typy domén a ide o jednorazovú overovaciu kontrolu:

   • E-mailová doména

   • DNS doména Expressway-E

   • Doména URI adresára

2. Kontrola vlastníctva DNS názvu Expressway-E. Tento krok sa vykonáva prostredníctvom implementácie TLS so vzájomnou autentifikáciou a zahŕňa použitie verejných certifikátov na cloude aj na Expressway. Na rozdiel od kontroly identity domény sa tento krok vykonáva počas akéhokoľvek hovoru uskutočneného a prijatého z cloudu.

Dôležitosť kontroly vlastníctva domény

Cloud Webex vykonáva kontrolu vlastníctva domény na vynútenie bezpečnosti. Krádež identity je jednou z možných hrozieb, ak sa táto kontrola nevykoná.

Nasledujúci príbeh podrobne popisuje, čo sa môže stať, ak sa nevykoná kontrola vlastníctva domény.

Spoločnosť s doménou DNS nastavenou na „hacker.com“ kupuje hybridné služby Webex. Hybridné služby využíva aj ďalšia spoločnosť s vlastnou doménou nastavenou na „example.com“. Jeden z generálnych manažérov spoločnosti Example.com sa volá Jane Roe a má adresár URI jane.roe@example.com.

Administrátor spoločnosti Hacker.com nastaví jeden z jej URI adresára na jane.roe@example.com a e-mailovú adresu na jane.roe@hacker.com. Môže to urobiť, pretože cloud v tomto príklade nekontroluje doménu SIP URI.

Potom sa prihlási do aplikácie Webex pomocou jane.roe@hacker.com. Keďže je vlastníkom domény, overovací e-mail je prečítaný a zodpovedaný a môže sa prihlásiť. Nakoniec zavolá kolegovi Johnovi Doeovi vytočením adresy john.doe@example.com zo svojej aplikácie Webex. John sedí vo svojej kancelárii a na svojom video zariadení vidí hovor prichádzajúci z jane.roe@example.com; to je adresa URI priradená k tomuto e-mailovému účtu.

„Je v zahraničí,“ myslí si. "Možno potrebuje niečo dôležité." Zdvihne telefón a falošná Jane Roe si pýta dôležité dokumenty. Vysvetľuje, že jej zariadenie je pokazené, a keďže cestuje, žiada ho, aby poslal dokumenty na jej súkromnú e-mailovú adresu jane.roe@hacker.com. Týmto spôsobom si spoločnosť uvedomí, až keď sa Jane Roe vráti do kancelárie, že dôležité informácie unikli mimo spoločnosti.

Spoločnosť Example.com má mnoho spôsobov, ako sa chrániť pred podvodnými hovormi prichádzajúcimi z internetu, ale jednou z povinností cloudu Webex je zabezpečiť, aby identita každého volajúceho z Webexu bola správna a nebola sfalšovaná.

Na kontrolu identity Webex vyžaduje, aby spoločnosť preukázala, že vlastní domény používané v hybridnom volaní. Ak nie, hybridné služby nebudú fungovať.

Na zabezpečenie tohto vlastníctva sú potrebné dva kroky overenia domény:

1. Dokážte, že spoločnosť vlastní emailovú doménu, Expressway-E doménu, Directory URI doménu.

   • Všetky tieto domény musia byť smerovateľné a známe verejnými servermi DNS.

   • Na preukázanie vlastníctva musí správca DNS zadať textový záznam DNS (TXT). Záznam TXT je typ záznamu o zdroji v DNS, ktorý sa používa na poskytnutie možnosti priradiť nejaký svojvoľný a neformátovaný text k hostiteľovi alebo inému názvu.

   • Správca DNS musí zadať tento TXT záznam do zóny, ktorej vlastníctvo musí byť preukázané. Po tomto kroku cloud Webex vykoná dotaz na záznam TXT pre danú doménu.

   • Ak je dotaz TXT úspešný a výsledok sa zhoduje s tokenom, ktorý bol vygenerovaný z cloudu Webex, doména sa overí.

   • Napríklad správca musí preukázať, že vlastní doménu „example.com“, ak chce, aby na jej doméne fungovali hybridné služby Webex.

   • Prostredníctvom https://admin.webex.com začne proces overovania vytvorením záznamu TXT, ktorý sa zhoduje s tokenom, ktorý vygeneroval cloud Webex:

     

   • Správca DNS potom vytvorí záznam TXT pre túto doménu s hodnotou nastavenou na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, ako v nasledujúcom príklade:

     

   • V tomto bode môže cloud overiť, či sa záznam TXT pre doménu example.com zhoduje s tokenom.

   • Cloud vykoná vyhľadávanie TXT DNS:

     

   • Pretože hodnota TXT sa zhoduje s hodnotou tokenu, táto zhoda dokazuje, že správca pridal záznam TXT pre jej vlastnú doménu do verejného DNS a že je vlastníkom domény.

2. Kontrola vlastníctva názvu DNS Expressway-E.

   • Cloud musí skontrolovať, či má Expressway-E potvrdenú identitu od jednej z certifikačných autorít, ktorým cloud dôveruje. Správca Expressway-E musí požiadať o verejný certifikát pre svoju Expressway-E u jednej z týchto certifikačných autorít. Na vydanie certifikátu certifikačná autorita vykoná proces overenia identity na základe kontroly overenia domény (pre certifikáty overené doménou) alebo kontroly overenia organizácie (pre certifikáty overené organizáciou).

   • Volania do a z cloudu závisia od certifikátu, ktorý bol vydaný pre Expressway-E. Ak certifikát nie je platný, hovor sa zruší.

Aby Hybridné volanie fungovalo, musí Webex Device Connector komunikovať s Webexom.

Webex Device Connector je nasadený v internej sieti a spôsob, akým komunikuje s cloudom, je cez odchádzajúce HTTPS pripojenie – rovnaký typ, aký sa používa pre akýkoľvek prehliadač, ktorý sa pripája k webovému serveru.

Komunikácia s cloudom Webex využíva TLS. Webex Device Connector je klient TLS a cloud Webex je server TLS. Webex Device Connector ako taký kontroluje certifikát servera.

Certifikačná autorita podpisuje certifikát servera pomocou vlastného súkromného kľúča. Ktokoľvek s verejným kľúčom môže tento podpis dekódovať a dokázať, že certifikát podpísala rovnaká certifikačná autorita.

Ak má Webex Device Connector overiť certifikát poskytnutý cloudom, musí na dekódovanie podpisu použiť verejný kľúč certifikačnej autority, ktorá podpísala daný certifikát. Verejný kľúč je obsiahnutý v certifikáte certifikačnej autority. Ak chcete vytvoriť dôveru s certifikačnými autoritami používanými cloudom, zoznam certifikátov týchto dôveryhodných certifikačných autorít musí byť v úložisku dôveryhodnosti Webex Device Connector.

Pri komunikácii so zariadeniami nástroj používa dôveryhodné certifikáty, ktoré poskytnete. Momentálne je to možné tak, že ich umiestnite do [domovského priečinka]/.devicestool/certs.

Zoznam certifikátov certifikačnej autority sa vyžaduje aj pre Expressway-E v prechodovom páre. Expressway-E komunikuje s cloudom Webex pomocou SIP s TLS, vynúteným vzájomnou autentifikáciou. Expressway-E dôveruje hovorom prichádzajúcim z cloudu a smerujúcim do cloudu, iba ak sa CN alebo SAN certifikátu prezentovaného cloudom počas nastavovania pripojenia TLS zhoduje s názvom subjektu nakonfigurovaným pre zónu DNS na Expressway („callservice.webex.com“) . Certifikačná autorita vydá certifikát až po kontrole identity. Na podpísanie certifikátu je potrebné preukázať vlastníctvo domény callservice.webex.com. Keďže túto doménu vlastníme my (Cisco), názov DNS „callservice.webex.com“ je priamym dôkazom toho, že vzdialený partner je skutočne Webex.

konektor kalendára integruje Webex s Microsoft Exchange 2013, 2016, 2019 alebo Office 365 prostredníctvom konta na odcudzenie identity. Rola správy zosobnenia aplikácie na serveri Exchange umožňuje aplikáciám vydávať sa za používateľov v organizácii a vykonávať úlohy v mene používateľa. Rola zosobnenia aplikácie musí byť nakonfigurovaná v Exchange a používa sa v konektore kalendára ako súčasť konfigurácie Exchange na rozhraní Expressway-C.

Spoločnosťou Microsoft odporúčaný spôsob pre túto úlohu je účet Exchange na odcudzenie identity. Správcovia Expressway-C nepotrebujú poznať heslo, pretože hodnotu môže zadať v rozhraní Expressway-C správca Exchange. Heslo nie je jasne zobrazené, aj keď má správca Expressway-C root prístup k boxu Expressway-C. Heslo je uložené zašifrované pomocou rovnakého mechanizmu šifrovania poverení ako ostatné heslá na Expressway-C.

Ak chcete získať ďalšie zabezpečenie, postupujte podľa krokov v Príručke nasadenia pre službu Cisco Webex Hybrid Calendar Service a povoľte TLS, aby ste zabezpečili pripojenia EWS na drôte.

Ak chcete získať ďalšie zabezpečenie, postupujte podľa krokov v časti Nasadenie konektora kalendára Expressway pre Microsoft Exchange a povoľte TLS, aby ste zabezpečili pripojenia EWS na drôte.