Tato část poskytuje přidaný kontext o klíčových položkách konfigurace, které se vztahují k hybridním službám.

Tyto body jsou zásadní, pokud chcete úspěšně nasadit hybridní volání pro zařízení Webex. Tyto položky jsme zdůraznili zejména z následujících důvodů:

• Chceme je vysvětlit, abyste pochopili jejich roli v hybridním nasazení a cítili se v klidu.

• Jsou to povinné předpoklady, které zajišťují bezpečné nasazení mezi naším cloudem a vaším místním prostředím.

• Mělo by se s nimi zacházet jako s nulovými aktivitami před dnem: dokončení může trvat o něco déle než typická konfigurace v uživatelském rozhraní, takže povolte časový rámec pro třídění těchto položek.

• Poté, co jsou tyto položky řešeny ve vašem prostředí, zbytek konfigurace hybridních služeb proběhne hladce.

Nasazení páru Expressway-C a Expressway-E umožňuje volání na internet a z něj pomocí technologií procházení firewal lem. Toto nasazení je to, co bezpečně přebírá vaše místní řízení hovorů a spojuje je s Webex.

Expressway-C a Expressway-E nevyžadují otevření příchozího portu v demilitarizované zóně (DMZ) firewall kvůli architektuře procházení firewallem. Signální porty TCP SIP a porty médií UDP musí být otevřeny příchozí na internetovém bráně firewall, aby mohly přicházet příchozí hovory. Pro otevření příslušného portu na firemní bráně firewall musíte mít čas.

Architektura procházení firewallu je znázorněna na následujícím diagramu:

Například pro příchozí firemní hovory (B2B) využí vající protokol SIP musí být na externím firewallu otevřeny porty TCP 5060 a 5061 (5061 se používá pro SIP TLS) spolu s porty médií UDP používanými pro služby, jako je hlas, video, sdílení obsahu, duální video atd. Které porty médií se mají otevřít, závisí na počtu souběžných hovorů a počtu služeb.

Port poslechu SIP na Expressway můžete nakonfigurovat tak, aby měl libovolnou hodnotu mezi 1024 a 65534. Současně musí být tato hodnota a typ protokolu inzerovány ve veřejných DNS SRV záznam ech a stejná hodnota musí být otevřena v internetovém bráně firewall.

Ačkoli standard pro SIP TCP je 5060 a pro SIP TLS 5061, nic nebrání použití různých portů, jak ukazuje následující příklad.

Příklad

V tomto příkladu předpokládáme, že port 5062 se používá pro příchozí volání SIP TLS.

Z DNS SRV áznam pro cluster dvou serverů Expressway vypadá takto:

_doušky. _tcp.example .com Umístění služby SRV:

priority = 10

weight = 10

port = 5062

svr název hostitele = us-expe1.example.com

_doušky. _tcp.example .com Umístění služby SRV:

priority = 10

weight = 10

port = 5062

svr název hostitele = us-expe2.example.com

Tyto záznamy znamenají, že hovory jsou přesměrovány na us-expe1.example.com a us-expe2.example.com se stejným sdílením zatížení (priorita a hmotnost) s použitím TLS jako typu přenosu a 5062 jako čísla portu poslechu.

Zařízení, které je mimo síť (na internetu) a které provádí SIP volání uživateli podnikové domény (user1@example.com), musí požádat DNS, aby zjistilo, jaký typ přenosu použít, číslo portu, jak načíst a sdílet provoz a na které SIP servery se má hovor odeslat.

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

TLS je protokol klient-server a v nejběžnějších implementacích používá certifikáty pro autentizaci. Ve scénáři volání mezi podniky je klient TLS volajícím zařízením a server TLS je volané zařízení. S TLS klient zkontroluje certifikát serveru a pokud kontrola certifikátu selže, odpojí hovor. Klient certifikát nepotřebuje.

Potřesení rukou TLS je znázorněno na následujícím diagramu:

Specifikace TLS však uvádí, že server může také zkontrolovat klientský certifikát odesláním zprávy požadavku na certifikát klientovi během protokolu handshake TLS. Tato zpráva je užitečná při připojení mezi serverem a serverem, například při hovoru, který je navázán mezi Expressw ay-E a cloudem Webex. Tento koncept se nazývá TLS se vzájemnou autentizací a je vyžadován při integraci s Webex.

Volající i volaná strana kontrolují certifikát druhého partnera, jak ukazuje následující diagram:

Cloud kontroluje identitu Expressway a Expressway ověří identitu cloudu. Pokud například identita cloudu v certifikátu (CN nebo SAN) ne odpovídá tomu, co je nakonfigurováno na Expressway, připojení se přeruší.

Pokud je zapnuto vzájemné ověřování, Expressway-E vždy požaduje klientský certifikát. Výsledkem je, že Mobile a Remote Access (MRA) nebudou fungovat, protože ve většině případů nejsou certifikáty nasazeny v klientech Jabber . Pokud ve scénáři mezi podniky není volající entita schopna poskytnout certifikát, je hovor od pojen.

Doporučujeme použít jinou hodnotu než 5061 pro protokol TLS se vzájem ným ověřováním, například port 5062. Webex Hybrid Services používají stejný záznam SIP TLS jako pro B2B. V případě portu 5061 nebudou fungovat některé další služby, které nemohou poskytnout klientský certifikát TLS.

Pokud je již existující záznam použit pro komunikaci mezi podniky, doporučujeme zadat subdoménu podnikové domény jako cíl SIP v Control Hubu a následně veřej ný DNS SRV záznam následujícím způsobem:

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

Provoz mezi podniky, mobily Remote Access a Webex na stejném páru Expressway

Volání typu Business-to-Business (B2B) a Mobile a Remote Access (MRA) používají port 5061 pro SIP TLS a provoz Webex používá port 5062 pro SIP TLS se vzájemnou autentizací.

Kontrola vlastnictví domény je součástí ověření identity. Ověření domény je bezpečnostní opatření a kontrola identity, kterou cloud Webex implementuje, aby dokázal, že jste tím, kým říkáte, že jste.

Kontrola totožnosti se provádí ve dvou fázích:

1. Kontrola vlastnictví domény. Tento krok zahrnuje tři typy domén a jedná se o jednorázovou ověřovací kontrolu:

   • E-mailová doména

   • Expressway-E DNS doména

   • Adresář URI domény

2. Kontrola vlastnictví názvu DNS Expressway-E. Tento krok se provádí implementací TLS se vzájemnou autentizací a zahrnuje použití veřejných certifikátů na cloudu i na Expressway. Na rozdíl od kontroly identity domény se tento krok provádí během jakéhokoli hovoru uskutečněného a přijímaného z cloudu.

Důležitost kontroly vlastnictví domény

Cloud Webex provádí kontrolu vlastnictví domény za účelem vynucení zabezpečení. Krádež identity je jednou z možných hrozeb, pokud tato kontrola nebude provedena.

Následující příběh podrobně popisuje, co se může stát, pokud není provedena kontrola vlastnictví domény.

Společnost s doménou DNS nastavenou na „hacker.com“ kupuje Webex Hybrid Services. Další společnost s vlastní doménou nastavenou na „example.com“ také používá hybridní služby. Jeden z generálních manažerů společnosti Example.com se jmenuje Jane Roe a má adresář URI jane.roe@example.com.

Administrátorka společnosti Hacker.com nastaví jednu ze svých adresářových URI na adresu jane.roe@example.com a e-mailovou adresu na jane.roe@hacker.com. Může to udělat, protože cloud v tomto příkladu nekontroluje doménu SIP URI.

Dále se přihlásí k aplikaci Webex pomocí adresy jane.roe@hacker.com. Protože vlastní doménu, ověřovací e-mail je přečten a zodpovězen a může se přihlásit. Nakonec zavolá kolegovi Johnovi Doeovi vytočením john.doe@example.com ze své aplikace Webex. John sedí ve své kanceláři a vidí hovor na svém videozařízení přicházející z jane.roe@example.com; to je adresář URI přidružený k tomuto e-mailovému účtu.

„Je v zahraničí,“ pomyslí si. „Možná bude potřebovat něco důležitého.“ Odpovídá na telefon a falešná Jane Roe žádá o důležité dokumenty. Vysvětluje, že její zařízení je rozbité, a protože cestuje, požádá ho, aby dokumenty zaslal na její soukromou e-mailovou adresu jane.roe@hacker.com. Tímto způsobem si společnost uvědomí až poté, co se Jane Roe vrátí do kanceláře, že důležité informace unikly mimo společnost.

Společnost Example.com má mnoho způsobů, jak chránit před podvodnými hovory přicházejícími z internetu, ale jednou z povinností cloudu Webex je zajistit, aby identita kohokoli volajícího z Webex byla správná a nefalšovaná.

Ke kontrole identity Webex vyžaduje, aby společnost prokázala, že vlastní domény používané v hybridním volání. Pokud tomu tak není, hybridní služby nebudou fungovat.

K zajištění tohoto vlastnictví jsou vyžadovány dva kroky ověření domény:

1. Dokažte, že společnost vlastní e-mailovou doménu, doménu Expressway-E, doménu URI adresáře.

   • Všechny tyto domény musí být směrovatelné a známé veřejnými servery DNS.

   • K prokázání vlastnictví musí správce DNS zadat textový záznam DNS (TXT). Záznam TXT je typ záznamu o prostředku v DNS, který slouží k zajištění možnosti přidružení libovolného a neformátovaného textu k hostiteli nebo jinému jménu.

   • Správce DNS musí zadat záznam TXT v zóně, jejíž vlastnictví musí být prokázáno. Po tomto kroku provede cloud Webex dotaz na záznam TXT pro danou doménu.

   • Pokud je dotaz TXT úspěšný a výsledek odpovídá tokenu, který byl vygenerován z cloudu Webex, doména je ověřena.

   • Například správce musí prokázat, že vlastní doménu „example.com“, pokud chce, aby Webex Hybrid Services fungovaly na její doméně.

   • Prostřed nictvím https://admin.webex.com spustí proces ověření vytvořením záznamu TXT, který odpovídá tokenu, který generoval cloud Webex:

     

   • Správce DNS pak vytvoří záznam TXT pro tuto doménu s hodnotou nastavenou na 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, jako v následujícím příkladu:

     

   • V tomto okamžiku může cloud ověřit, že záznam TXT pro doménu example.com odpovídá tokenu.

   • Cloud provede vyhledávání TXT DNS:

     

   • Protože hodnota TXT odpovídá hodnotě tokenu, tato shoda dokazuje, že správce přidal záznam TXT pro svou vlastní doménu do veřejného DNS a že vlastní doménu.

2. Kontrola vlastnictví názvu DNS Expressway-E.

   • Cloud musí zkontrolovat, zda má Expressway-E potvrzenou identitu od jedné z certifikačních autorit, kterým cloud důvěřuje. Správce Expressway-E musí požádat jednu z těchto certifikačních autorit o veřejný certifikát pro svůj Expressway-E. K vydání certifikátu provede certifikační autorita proces ověření identity založený na ověření domény (u certifikátů ověřených doménou) nebo ověření organizace (u certifikátů ověřených organizací).

   • Hovory do a z cloudu závisí na certifikátu, který byl vydán Expressway-E. Pokud certifikát není platný, hovor se přeruší.

Aby hybridní volání fungovalo, musí Webex Device Connector komunikovat s Webex.

Webex Device Connector je nasazen v interní síti a způsob, jakým komunikuje s cloudem, je prostřednictvím odchozího připojení HTTPS - stejného typu, jaký se používá pro jakýkoli prohlížeč, který se připojuje k webo vému serveru.

Komunikace s cloudem Webex používá TLS. Webex Device Connector je klient TLS a cloud Webex je server TLS. Webex Device Connector proto kontroluje certifikát serveru.

Certifikační autorita podepíše certifikát serveru pomocí vlastního soukromého klíče. Každý, kdo má veřejný klíč, může tento podpis dekódovat a prokázat, že certifikát podep sal stejná certifikační autorita.

Pokud Webex Device Connector musí ověřit certifikát poskytnutý cloudem, musí k dekódování podpisu použít veřejný klíč certifikační autority, která certifikát podepsala. Ve řejný klíč je obsažen v certifikátu certifikační autority. Chcete-li vytvořit důvěryhodnost certifikačních autorit používaných cloudem, musí být seznam certifikátů těchto důvěryhodných certifikačních autorit v úložišti důvěryhodnosti Webex Device Connector.

Při komunikaci se zařízeními používá nástroj důvěryhodné certifikáty, které poskytnete. V současné době je způsob, jak toho dosáhnout, jejich umístění [home folder]/.devicestool/certs.

Seznam certifikátů certifikační autority je také vyžadován pro Expressway-E v průchodovém pá ru. Expressway-E komunikuje s cloudem Webex pomocí SIP s TLS, vynuceným vzájemnou autentizací. Expressway-E důvěřuje hovor ům přicházejícím z cloudu a odcházejícím do cloudu, pouze pokud CN nebo SAN certifikátu předloženého cloudem během nastavení připojení TLS odpovídá názvu předmětu nakonfigurovanému pro zónu DNS na Expressway („callservice.webex.com“). Certifikační autorita vydá certifikát až po kontrole totožnosti. Vlastnictví domény callservice.webex.com musí být prokázáno, aby byl certifikát podepsán. Protože my (Cisco) vlastníme tuto doménu, název DNS „callservice.webex.com“ je přímým důkazem toho, že vzdálený peer je skutečně Webex.

konektor kalendáře integruje Webex s Microsoft Exchange 2013,2016,2019 nebo Office 365 prostřednictvím účtu zosobnění. Role správy zosobnění aplikací v Exchange umožňuje aplikacím vydávat se za uživatele v organizaci, aby prováděli úkoly jménem uživatele. Role zosobnění aplikace musí být nakonfigurována v Exchange a používá se v konektoru kalendáře jako součást konfigurace Exchange v rozhraní Expressway-C.

Účet zosobnění Exchange je doporučenou metodou společnosti Microsoft pro tento úkol. Správci Expressway-C nemusí znát heslo, protože hodnotu může zadat v rozhraní Expressway-C správce Exchange. Heslo není jasně zobrazeno, i když správce Expressway-C má kořenový přístup k poli Expressway-C. Heslo je uloženo zašifrované pomocí stejného mechanismu šifrování pověření jako jiná hesla na Expressway-C.

Chcete-li zajistit další zabezpečení, postupujte podle pokynů v Prů vodci nasazením služby Cisco Webex Hybrid Calendar Service a povolte protokol TLS za účelem zabezpečení připojení EWS na kabelu.

Pro další zabezpečení, postupujte podle pokynů v části Nas azení konektoru kalendáře Expressway pro Microsoft Exchange povolení protokolu TLS za účelem zabezpečení připojení EWS na vodiči.