Táto časť obsahuje pridaný kontext o kľúčových konfiguračných položkách, ktoré sa týkajú hybridných služieb.

Tieto body sú rozhodujúce, ak chcete úspešne nasadiť hybridné volanie pre zariadenia Webex. Tieto položky sme zdôraznili najmä z nasledujúcich dôvodov:

• Chceme im vysvetliť, aby ste pochopili ich úlohu pri hybridnom nasadení a cítili sa upokojení.

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

• Mali by sa s nimi zaobchádzať ako s nulovými aktivitami pred dňom: ich dokončenie môže trvať o niečo dlhšie ako typická konfigurácia v používateľskom rozhraní, takže umožnite časový rámec na zoradenie týchto položiek.

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

Nas@@ adenie párov Expressway-C a Expressway-E umožňuje hovory na internet a z internetu pomocou technológií prenosu firewall u. Toto nasadenie bezpečne preberá kontrolu lokálnych hovorov a spája ho s Webexom.

Expressway-C a Expressway-E nevyžadujú otvorenie žiadneho prichádzajúceho portu v bráne demilitarizovanej zóny (DMZ) kvôli architektúre traverznej firewall. Signalizačné porty TCP SIP a mediálne porty UDP však musia byť otvorené prichádzajúce na internetovom firewallu, aby mohli prichádzať prichádzajúce hovory. Musíte poskytnúť čas na otvorenie príslušného portu vo vašom podnikovom firewallu.

Architektúra prechodu firewallu je znázornená na nasledujúcom diagrame:

Napríklad pri prichádzajúcich hovoroch typu business-to-business (B2B) používajúcich protokol SIP musia byť na externom firewallu 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 hlas, video, zdieľanie obsahu, duálne video atď. Ktoré mediálne porty sa majú otvoriť, závisí od počtu súbežných hovorov a počtu služieb.

Port počúvania SIP na rýchlostnej ceste môžete nakonfigurovať tak, aby mal akúkoľvek hodnotu medzi 1024 až 65534. Táto hodnota a typ protokol u musia byť zároveň inzerované vo verejných DNS SRV záznamoch a rovnaká hodnota musí byť otvorená na internetovom firewallu.

Hoci štandard 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 pre prichádzajúce SIP TLS hovory.

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

_dúšky. _tcp.example .com SRV umiestnenie servisu:

priority = 10

weight = 10

port = 5062

svr názov hostiteľa = us-expe1.example.com

_dúšky. _tcp.example .com SRV umiestnenie servisu:

priority = 10

weight = 10

port = 5062

svr názov hostiteľa = us-expe2.example.com

Tieto záznamy znamenajú, že hovory sú nasmerované na us-expe1.example.com a us-expe2.example.com s rovnakým zdieľaním zaťaženia (priorita a hmotnosť) s použitím TLS ako druhu prepravy a 5062 ako čísla portu počúvania.

Zariadenie, ktoré je mimo siete (na internete) a ktoré uskutočňuje SIP hovor používateľovi firemnej domény (user1@example.com), musí požiadať DNS, aby zistilo, ak ý typ dopravy sa má použiť, číslo portu, ako načítať a zdieľať prevádzku a na ktoré servery SIP hovor odoslať.

Ak položka DNS obsahuje _sips. _tcp, polož ka určuje SIP TLS.

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

Podanie ruky TLS je znázornené na nasledujúcom diagrame:

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

Volajúce aj volané strany kontrolujú certifikát druhého partnera, ako ukazuje nasledujúci diagram:

Cloud kontroluje identitu rýchlostnej cesty a rýchlostná cesta kontroluje identitu cloudu. Ak sa napríklad identita cloudu v certifikáte (CN alebo SAN) nez hoduje s konfiguráciou na Expressway, pripojenie sa ukončí.

Ak je zapnutá vzájomná autentifikácia, Expressway-E vždy požaduje certifik át klienta. Výsledkom je, že Mobile a Remote Access (MRA) nebudú fungovať, pretože vo väčšine prípadov nie sú certifikáty nasadené na klientoch Jabber . Ak volajúci subjekt nie je schopný poskytnúť certifikát v scenári medzi podnikmi, hovor je odpojený.

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

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

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

Prevádzka Business-to-Business, Mobile Remote Access a Webex na rovnakom páre rýchlostných ciest

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

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

Kontrola identity sa vykonáva v dvoch fázach:

1. Kontrola vlastníctva domény. Tento krok zahŕňa tri typy domén a je jednorazovou overovacou kontrolou:

   • E-mailová doména

   • Expressway-E DNS doména

   • Adresár URI domény

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

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

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

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

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

Správca spoločnosti Hacker.com nastaví jednu zo svojich adresárových URI na adresu 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.

Ďalej sa prihlási do aplikácie Webex cez jane.roe@hacker.com. Pretože vlastní doménu, overovací e-mail sa číta a odpovedá a môže sa prihlásiť. Nakoniec zavolá kolegovi Johnovi Doe vytočením john.doe@example.com zo svojej aplikácie Webex. John sedí vo svojej kancelárii a vidí hovor na jeho video zariadení prichádzajúci z jane.roe@example.com; to je adresár URI priradený k tomuto e-mailovému účtu.

„Je v zahraničí,“ myslí si. Možno bude potrebovať niečo dôležité.“ Odpovedá na telefón a falošná Jane Roe žiada o dôležité dokumenty. Vysvetľuje, že jej zariadenie je poškodené a keďže cestuje, pož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ž po návrate Jane Roe do kancelárie, že dôležité informácie unikli mimo spoločnosti.

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

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

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

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

   • 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 zdrojového záznamu v DNS, ktorý sa používa na zabezpečenie možnosti priradenia ľubovoľného a neformátovaného textu k hostiteľovi alebo inému názvu.

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

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

   • Napríklad správca musí dokázať, že vlastní doménu „example.com“, ak chce, aby Webex Hybrid Services fungovala na jej doméne.

   • Pro stredníctvom https://admin.webex.com začne proces overovania vytvorením záznamu TXT, ktorý zodpovedá tokenu, ktorý vytvoril cloud Webex:

     

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

     

   • V tomto okamihu môže cloud overiť, či záznam TXT pre doménu example.com zodpovedá tokenu.

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

     

   • Pretože hodnota TXT zodpovedá hodnote tokenu, táto zhoda dokazuje, že správca pridala záznam TXT pre svoju vlastnú doménu do verejného DNS a že vlastní doménu.

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

   • Cloud musí skontrolovať, či má Expressway-E potvrdenú totožnosť od jedného z certifikačných orgánov, ktorým cloud dôveruje. Správca Expressway-E musí požiadať o verejné osvedčenie pre svoj Expressway-E niektorému z týchto certifikačných orgánov. Na vydanie certifikátu certifikačná autorita vykoná proces overovania identity založený na kontrole overovania domény (pre certifikáty overené doménou) alebo kontroly overenia organizácie (pre certifikáty overené organizáciou).

   • Hovory do cloudu a z neho závisia od certifikátu, ktorý bol vydaný Expressway-E. Ak certifikát nie je platný, hovor sa ukončí.

Konektor zariadenia Webex musí komunikovať so spoločnosťou Webex, aby fungovalo hybridné volanie.

Webex Device Connector je nasadený v internej sieti a spôsob komunikácie s cloudom je prostredníctvom odchádzajúceho pripojenia HTTPS — rovnakého typu, 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 preto kontroluje certifikát servera.

Certifikačná autorita podpisuje certifikát servera pomocou vlastného súkromného kľúča. Každý, kto má verejný kľúč, môže tento podpis dekódovať a dokázať, že ten istý certifikačný orgán podpísal tento certifikát.

Ak Webex Device Connector musí overiť certifikát poskytnutý cloudom, musí na dekódovanie podpisu použiť verejný kľúč certifik ačného orgánu, ktorý tento certifikát podpísal. Verejný kľúč je obsiahnutý v certifikáte certifikačného orgánu. Ak chcete nadviazať dôveru s certifikačnými orgánmi používanými v cloude, zoznam certifikátov týchto dôveryhodných certifikačných orgánov musí byť v dôveryhodnom obchode Webex Device Connector.

Pri komunikácii so zariadeniami nástroj používa dôveryhodné certifikáty, ktoré poskytnete. V súčasnosti je spôsob, ako to urobiť, umiestniť ich dovnútra [home folder]/.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 idúcim do cloudu, iba ak CN alebo SAN certifikátu prezentovaného cloudom počas nastavenia pripojenia TLS zodpovedá názvu predmetu nakon figurovanému pre zónu DNS na Expressway („callservice.webex.com“). Certifikačný orgán vydá certifikát až po kontrole totožnosti. Na podpísanie certifikátu musí byť preukázané vlastníctvo domény callservice.webex.com. Pretože my (Cisco) vlastníme túto doménu, názov DNS „callservice.webex.com“ je priamym dôkazom toho, že vzdialený peer je skutočne Webex.

Konektor kalendára integruje Webex s Microsoft Exchange programami 2013, 2016, 2019 alebo Office 365 prostredníctvom účtu imitácie. Úloha správy vydávania sa aplikácií v programe 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. Úloha imitácie aplikácie musí byť nakonfigurovaná v programe Exchange a používa sa v konektoroch kalendára ako súčasť konfigurácie programu Exchange na rozhraní Expressway-C.

Konto vydávania sa v službe Exchange je metódou odporúčanou spoločnosťou Microsoft pre túto úlohu. Správcovia Expressway-C nemusia poznať heslo, pretože hodnotu môže zadať do rozhrania Expressway-C správca Exchange. Heslo nie je jasne zobrazené, aj keď správca Expressway-C má root prístup do poľa Expressway-C. Heslo sa ukladá šifrované pomocou rovnakého mechanizmu šifrovania poverení ako ostatné heslá v Expressway-C.

Ak chcete zvýšiť zabezpečenie, postupujte podľa krokov v Prí ručke nasadenia služby Cisco Webex hybridného kalend ára a povoľte TLS, aby ste zabezpečili pripojenia EWS na kábli.

Ak chcete získať ďalšie zabezpečenie, postupujte podľa krokov v časti Nasadiť konektor kalendára rýchlostných ciest, Microsoft Exchange aby ste mohli povoliť TLS, aby ste zabezpečili pripojenia EWS na drôte.