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

Tyto body jsou klíčové, 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 ě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.

• Po vyřešení těchto položek ve vašem prostředí proběhne zbytek konfigurace hybridních služeb hladce.

Nasazení dvojice Expressway-C a Expressway-E umožňuje volání do a z internetu pomocí technologií procházení firewallu. Toto nasazení bezpečně propojí vaše místní řízení hovorů s Webexem.

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á při připojení typu server-server, například při hovoru mezi Expressway-E a cloudem Webex. Tento koncept se nazývá TLS se vzájemným ověřováním a je vyžadován při integraci s Webexem.

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 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 se pro komunikaci mezi podniky (business-to-business) již používá existující záznam, doporučujeme v Control Hubu jako cíl SIP zadat subdoménu firemní domény a následně veřejný záznam SRV DNS takto:

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

Provoz mezi firmami, mobilní a vzdálený přístup a provoz Webexu na stejném páru dálnic Expressway

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

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 prokázal, že jste tím, za koho se vydáváte.

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.

Důležitost kontroly vlastnictví domény

Cloud Webex provádí kontrolu vlastnictví domény za účelem zajištění 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.

Dále se přihlásí do aplikace Webex pomocí 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 Doeovi, vytočením čísla john.doe@example.com z její aplikace Webex. Jan sedí ve své kanceláři a na videozařízení vidí hovor, který přichází z… jane.roe@example.com; což je URI adresáře přidružený k danému 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 nabízí mnoho způsobů, jak se chránit před podvodnými hovory z internetu, ale jednou z povinností cloudu Webex je zajistit, aby identita každého, kdo volá z Webexu, byla správná a nebyla zfalšovaná.

Pro ověření identity Webex vyžaduje, aby společnost prokázala, že vlastní domény používané v hybridním volání. Pokud to tak není, 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 provede cloud Webex dotaz na záznam TXT pro danou doménu.

   • Pokud je dotaz TXT úspěšný a výsledek se shoduje s tokenem vygenerovaným z cloudu Webex, doména je ověřena.

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

   • Prostřednictvím https://admin.webex.comzahájí proces ověřování vytvořením záznamu TXT, který bude odpovídat tokenu vygenerovanému cloudem Webex:

     

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

     

   • 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í Webex Device Connector komunikovat se službou Webex.

Webex Device Connector je nasazen v interní síti a komunikuje s cloudem prostřednictvím odchozího připojení HTTPS – stejného typu, jaký se používá pro jakýkoli prohlížeč připojující se k webovému serveru.

Komunikace s cloudem Webex využívá protokol 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 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í Webex Device Connector ověřit certifikát poskytnutý cloudem, musí k dekódování podpisu použít veřejný klíč certifikační autority, která daný certifikát podepsala. Veřejný klíč je obsažen v certifikátu certifikační autority. Aby bylo možné navázat důvěryhodnost s certifikačními autoritami používanými 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 nástroj používá důvěryhodné certifikáty, které poskytnete. V současné době je to možné umístěním do [home folder]/.devicestool/certs.

Pro expressway-E v traverzní dvojici je také vyžadován seznam certifikátů certifikační autority. Expressway-E komunikuje s cloudem Webex pomocí protokolu SIP s TLS, vynuceného vzájemným ověřováním. Expressway-E důvěřuje hovorům přicházejícím z cloudu a odcházejícím do cloudu, pouze pokud se CN nebo SAN certifikátu předloženého cloudem během nastavení TLS připojení shoduje s názvem subjektu nakonfigurovaným pro zónu DNS na Expressway („callservice.webex.com“). Certifikační autorita vydá certifikát až po kontrole identity. Pro podepsání certifikátu je nutné prokázat vlastnictví domény callservice.webex.com. Protože my (Cisco) tuto doménu vlastníme, je název DNS „callservice.webex.com“ přímým důkazem, že vzdálený protějšek 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.

Pro tento úkol je doporučenou metodou společnosti Microsoft použití účtu zosobnění Exchange. 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.