Tato část poskytuje dodatečný kontext týkající se klíčových konfiguračních položek, které se týkají hybridních služeb.

Tyto body jsou klíčové, pokud chcete úspěšně nasadit službu Hybrid Calling 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 ěnováni.

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

• Měly by být považovány za činnosti před nulovým dnem: jejich 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 seřazení těchto položek.

• Jakmile budou tyto položky vyřešeny ve vašem prostředí, zbytek konfigurace hybridních služeb proběhne hladce.

Nasazení dvojice Expressway-C a Expressway-E umožňuje hovory na internet a z Internetu pomocí technologií pro procházení brány firewall. Toto nasazení bezpečně převezme řízení místních hovorů a propojí je se službou Webex.

Expressway-C a Expressway-E nevyžadují otevření žádného příchozího portu v bráně firewall demilitarizované zóny (DMZ) z důvodu architektury brány firewall. Ale tcp SIP signální porty a UDP mediální porty musí být otevřeny příchozí na internetové bráně firewall, aby příchozí hovory mohou projít. Je nutné poskytnout čas na otevření příslušného portu na podnikové bráně firewall.

Traverzní architektura brány firewall je znázorněna v následujícím diagramu:

Například pro příchozí volání mezi podniky (B2B) pomocí protokolu SIP musí být porty TCP 5060 a 5061 (5061 se používá pro SIP TLS) otevřeny na externí bráně firewall spolu s mediálními porty UDP používanými pro služby, jako je hlas, video, sdílení obsahu, duální video atd. Které mediální porty se mají otevřít, závisí na počtu souběžných volání a počtu služeb.

Odposlouchávací port SIP na dálnici můžete nakonfigurovat tak, aby měl libovolnou hodnotu mezi lety 1024 a 65534. Současně musí být tato hodnota a typ protokolu inzerovány ve veřejných záznamech DNS SRV a stejná hodnota musí být otevřena v internetové 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áznam DNS SRV pro cluster dvou serverů Expressway vypadá takto:

_sips._tcp.example.com Umístění služby SRV:

priorita = 10

hmotnost = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com Umístění služby SRV:

priorita = 10

hmotnost = 10

port = 5062

svr hostname = us-expe2.example.com

Tyto záznamy znamenají, že volání jsou směrována na us-expe1.example.com a us-expe2.example.com se stejným sdílením zatížení (priorita a hmotnost) pomocí protokolu TLS jako typu přenosu a 5062 jako čísla naslouchajícího portu.

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

Pokud položka DNS obsahuje _sips. , položka určuje_tcpSIP TLS.

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

TLS handshake je znázorněno na následujícím diagramu:

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

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

Cloud kontroluje identitu rychlostní silnice a Expressway kontroluje identitu cloudu. Pokud například identita cloudu v certifikátu (CN nebo SAN) neodpovídá tomu, co je nakonfigurováno na dálnici, připojení se vymaže.

Pokud je zapnuté vzájemné ověřování, Expressway-E vždy požaduje klientský certifikát. V důsledku toho mobilní a vzdálený přístup (MRA) nebude fungovat, protože ve většině případů nejsou certifikáty nasazeny na klientech Jabber. V případě mezipodnikovou situací, pokud volající entita není schopna poskytnout certifikát, je volání odpojeno.

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

Pokud se pro komunikaci mezi podniky již používá existující záznam, doporučujeme jako cíl SIP v centru Control Hub zadat subdoménu podnikové domény, a následně veřejný záznam DNS SRV následovně:

 Priorita služby a protokolu: _sips._tcp.mtls.example.com: 1 hmotnost: 10 Číslo portu: 5062 Cíl: us-expe1.příklad.com 

Mezipodnikový, mobilní a vzdálený přístup a provoz Webex ve stejné dvojici zařízení Expressway

Hovory typu business-to-business (B2B) a mobilní a vzdálený přístup (MRA) používají port 5061 pro SIP TLS a provoz Webex používá port 5062 pro SIP TLS se vzájemným ověřením.

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 provádí, aby prokázal, že jste tím, kým 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

   • Doména Expressway-E DNS

   • Doména identifikátoru URI adresáře

2. Kontrola vlastnictví názvu DNS expressway-E. Tento krok se provádí implementací TLS se vzájemným ověřováním a zahrnuje použití veřejných certifikátů v cloudu i na rychlostní silnici. Na rozdíl od kontroly identity domény se tento krok provádí během jakéhokoli volání do cloudu a přijatého z cloudu.

Význam kontroly vlastnictví domény

Cloud Webex provede kontrolu vlastnictví domény, aby bylo vynuceno zabezpečení. Krádež identity je jednou z možných hrozeb, pokud tato kontrola není provedena.

Následující článek podrobně popisuje, co se může stát, pokud se neprovádí kontrola vlastnictví domény.

Společnost s doménou DNS nastavenou na „hacker.com“ kupuje hybridní služby Webex. 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.

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

Následně se přihlásí do Aplikace Webex prostřednictvím jane.roe@hacker.com. Vzhledem k tomu, že doménu vlastní, ověřovací e-mail se přečte a odpoví a může se přihlásit. Nakonec zavolá kolegovi Johnu Doe tím, že ze své aplikace Webex vytočí adresu john.doe@example.com. John sedí ve své kanceláři a na svém videozařízení vidí hovor z jane.roe@example.com, což je identifikátor URI adresáře přidružený k tomuto e-mailovému účtu.

"Je v zahraničí," myslí si. "Možná bude potřebovat něco důležitého." Zvedne telefon a falešná Jane Roeová požádá o důležité dokumenty. Vysvětluje, že její zařízení je rozbité, a protože cestuje, požádá ho, aby poslal dokumenty 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 každého, kdo volá z Webexu, byla správná a nebyla falšována.

Aby bylo možné ověřit identitu, služba Webex vyžaduje, aby společnost prokázala, že vlastní domény používané v rámci hybridního volání. Pokud ne, hybridní služby nebudou fungovat.

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

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

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

   • Pro prokázání vlastnictví musí správce DNS zadat textový záznam DNS (TXT). Záznam TXT je typ záznamu prostředku v DNS, který slouží k poskytnutí možnosti přidružit libovolný a neformátovaný text k hostiteli nebo jinému názvu.

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

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

   • Pokud chce, aby hybridní služby Webex pracovaly ve své doméně, musí správce prokázat, že vlastní doménu „example.com“.

   • Prostřednictvím služby https://admin.webex.com spustí proces ověření vytvořením záznamu TXT, který odpovídá tokenu vygenerovanému cloudem Webex:

     

   • Správce DNS pak pro tuto doménu vytvoří záznam TXT s hodnotou nastavenou na 123456789abcdef123456789abcdef123456789abcdef, jak je uvedeno 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:

     

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

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

   • Cloud musí zkontrolovat, zda má Expressway-E potvrzenou identitu od jedné z certifikačních autorit, kterým cloud důvěřuje. Správce rychlostní silnice-E musí požádat o veřejné osvědčení pro svou rychlostní silnici E u jednoho z těchto certifikačních orgánů. K vystavení certifikátu certifikační autorita provede proces ověření identity na základě kontroly ověření domény (pro certifikáty ověřené doménou) nebo kontroly ověření organizace (pro certifikáty ověřené organizací).

   • Volání do a z cloudu závisí na certifikátu vydaném dálnici-E. Pokud certifikát není platný, je volání zrušeno.

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

Konektor zařízení Webex je nasazen v interní síti a způsob komunikace s cloudem je prostřednictvím odchozího připojení HTTPS – stejného typu, který se používá pro jakýkoli prohlížeč, který se připojuje k webovému serveru.

Komunikace do cloudu Webex využívá protokol TLS. Konektor zařízení Webex je klient TLS a cloud Webex je server TLS. Proto Webex Device Connector zkontroluje certifikát serveru.

Certifikační autorita podepíše certifikát serveru pomocí vlastního privátního klíče. Kdokoli s veřejným klíčem může tento podpis dekódovat a prokázat, že stejný certifikační úřad podepsal tento certifikát.

Pokud musí nástroj Webex Device Connector 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ěru u 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ěryhodných certifikátů Webex Device Connector.

Při komunikaci se zařízeními používá nástroj důvěryhodné certifikáty. Momentálně to lze provést tak, že je umístíte do [domovské složky]/.devicestool/certs.

Pro expressway-E v traverzní dvojici je také vyžadován seznam certifikátů certifikační autority. Zařízení Expressway-E komunikuje s cloudem Webex pomocí protokolu SIP s TLS, což je vynucováno vzájemným ověřením. Expressway-E důvěřuje hovorům přicházejícím z cloudu a odcházející do cloudu pouze v případě, že se CN nebo SAN certifikátu předloženého cloudem během nastavení připojení TLS shoduje s názvem předmětu nakonfigurovaným pro zónu DNS na Expressway („callservice.webex.com“). Certifikační autorita vydá certifikát až po kontrole identity. Pro získání podepsaného certifikátu musí být prokázáno vlastnictví domény callservice.webex.com. Protože tuto doménu vlastníme (společnost Cisco), název DNS „callservice.webex.com“ je přímým důkazem, že vzdálený partner je skutečně Webex.

kalendářový konektor integruje Webex s Microsoft Exchange 2013, 2016, 2019 nebo Office 365 prostřednictvím účtu zosobnění. Role správy napodobování aplikací ve službě Exchange umožňuje aplikacím napodobovat uživatele v organizaci při provádění úkolů jménem uživatele. Role imitace aplikace musí být nakonfigurována ve Exchange a používána v konektoru kalendáře jako součást konfigurace Exchange na rozhraní Expressway-C.

Účet pro zosobnění Exchange je doporučenou metodou společnosti Microsoft pro tuto úlohu. Správci rychlostní silnice C nemusí znát heslo, protože hodnotu může do rozhraní rychlostní silnice C zadat správce směnárny. Heslo není jasně zobrazeno, a to ani v případě, že má správce dálnice C přístup ke schránce dálnice C. Heslo je uloženo zašifrované pomocí stejného šifrovacího mechanismu jako ostatní hesla na dálnici C.

Pro další zabezpečení postupujte podle pokynů v příručce pro nasazení služby Cisco Webex Hybrid Calendar Service pro povolení TLS pro zajištění připojení EWS na drát.

Pro další zabezpečení postupujte podle kroků v části Nasazení konektoru kalendáře rychlostních silnic pro Microsoft Exchange a povolte TLS, abyste zajistili připojení EWS na drát.