Ovaj odjeljak pruža dodatni kontekst o ključnim konfiguracijskim stavkama koje se odnose na hibridne usluge.

Te su točke ključne ako želite uspješno implementirati Hybrid Calling za Webex uređaje. Ove smo stavke posebno istaknuli iz sljedećih razloga:

• Želimo ih objasniti, tako da razumijete njihovu ulogu u hibridnom uvođenju i osjećate se ohrabreno.

• To su obvezni preduvjeti koji osiguravaju sigurno uvođenje između našeg oblaka i vašeg lokalnog okruženja.

• Treba ih tretirati kao aktivnosti prije nultog dana: može potrajati malo dulje od uobičajene konfiguracije u korisničkom sučelju, stoga dopustite vremenski okvir za sortiranje tih stavki.

• Nakon što se te stavke obrate u vašem okruženju, ostatak vaše konfiguracije hibridnih usluga bit će neometano.

Implementacija Expressway-C i Expressway-E omogućuje pozive na internet i s interneta upotrebom tehnologija zaobilaženja vatrozida. Ova implementacija je ono što sigurno preuzima vašu lokalnu kontrolu poziva i povezuje je s Webexom.

Expressway-C i Expressway-E ne zahtijevaju otvaranje ulaznog priključka u vatrozidu demilitarizirane zone (DMZ) zbog arhitekture prolaza vatrozida. No, TCP SIP signalni priključci i UDP medijski priključci moraju biti otvoreni ulazno u internetski vatrozid kako bi dolazni pozivi prošli. Morate dopustiti vrijeme za otvaranje odgovarajućeg priključka u poslovnom vatrozidu.

Arhitektura prijelaza vatrozida prikazana je u sljedećem dijagramu:

Na primjer, za dolazne pozive između poduzeća (B2B) pomoću SIP protokola, TCP priključci 5060 i 5061 (5061 se koristi za SIP TLS) moraju se otvoriti na vanjskom vatrozidu, zajedno s UDP medijskim priključcima koji se koriste za usluge kao što su govor, videozapisi, dijeljenje sadržaja, dvostruki videozapisi i tako dalje. Koji medijski priključci za otvaranje ovise o broju istodobnih poziva i broju usluga.

SIP priključak za slušanje na expresswayu možete konfigurirati kao bilo koju vrijednost između 1024 i 65534. U isto vrijeme, ova vrijednost i vrsta protokola moraju se oglašavati u javnim DNS SRV zapisima, a ta ista vrijednost mora biti otvorena na internetskom vatrozidu.

Iako je standard za SIP TCP 5060, a za SIP TLS 5061, ništa ne sprječava korištenje različitih priključaka, kao što pokazuje sljedeći primjer.

Primjer

U ovom primjeru pretpostavljamo da se priključak 5062 koristi za dolazne SIP TLS pozive.

DNS SRV zapis za klaster dva poslužitelja za Expressway izgleda ovako:

_sips._tcp.primjer.com lokacija usluge SRV:

prioritet = 10

težina = 10

priključak = 5062

svr naziv glavnog računala = us-expe1.example.com

_sips._tcp.primjer.com lokacija usluge SRV:

prioritet = 10

težina = 10

priključak = 5062

svr naziv glavnog računala = us-expe2.example.com

Ti zapisi znače da su pozivi usmjereni na us-expe1.example.com i us-expe2.example.com s jednakim dijeljenjem opterećenja (prioritet i težina) koristeći TLS kao vrstu prijevoza i 5062 kao broj priključka za slušanje.

Uređaj koji je izvan mreže (na Internetu) i koji upućuje SIP poziv korisniku korporativne domene (user1@example.com) mora pitati DNS da bi razumio koju vrstu prijenosa koristiti, broj priključka, kako učitati-dijeliti promet i na koje SIP poslužitelje poslati poziv.

Ako DNS unos sadrži _sips. , unos navodi_tcpSIP TLS.

TLS je klijentsko-poslužiteljski protokol i u najčešćim implementacijama koristi certifikate za provjeru autentičnosti. U scenariju poziva između tvrtke, TLS klijent je pozivni uređaj, a TLS poslužitelj je nazvani uređaj. S TLS-om klijent provjerava certifikat poslužitelja, a ako provjera certifikata ne uspije, prekida poziv. Klijentu ne treba certifikat.

Rukovanje TLS-om prikazano je u sljedećem dijagramu:

Međutim, U specifikaciji TLS-a navodi se da poslužitelj može provjeriti i klijentski certifikat slanjem poruke zahtjeva za certifikat klijentu tijekom protokola rukovanja TLS-om. Ova je poruka korisna na vezi između poslužitelja i poslužitelja, kao što je na pozivu koji je uspostavljen između Expressway-E i Webex oblaka. Ovaj se koncept naziva TLS s uzajamnom provjerom autentičnosti i potreban je prilikom integracije s uslugom Webex.

I pozivne i pozvane strane provjeravaju certifikat drugog ravnopravnog članova, kao što pokazuje sljedeći dijagram:

Oblak provjerava identitet brze ceste, a Brza cesta provjerava identitet oblaka. Na primjer, ako se identitet oblaka u certifikatu (CN ili SAN) ne podudara s onim što je konfigurirano na brzoj cesti, veza se ispušta.

Ako je uključena međusobna provjera autentičnosti, Expressway-E uvijek traži certifikat klijenta. Kao rezultat toga, mobilni i daljinski pristup (MRA) neće raditi, jer se u većini slučajeva certifikati ne implementiraju na Jabber klijente. U poslovnom scenariju, ako entitet pozivanja ne može dati certifikat, poziv se prekida.

Preporučujemo da koristite vrijednost koja nije 5061 za TLS s obostranom provjerom autentičnosti, kao što je priključak 5062. Hibridne usluge Webex upotrebljavaju isti SIP TLS zapis koji se upotrebljava za B2B. U slučaju priključka 5061 neke druge usluge koje ne mogu pružiti TLS klijentski certifikat neće funkcionirati.

Ako se postojeći zapis već upotrebljava za komunikaciju između tvrtki, preporučujemo da navedete poddomenu korporativne domene kao SIP odredište u okruženju Control Hub, a time i javni DNS SRV zapis, na sljedeći način:

 Usluga i protokol: _sips._tcp.mtls.primjer.com Prioritet: 1 Težina: 10 Broj priključka: 5062 Cilj: us-expe1.primjer.com 

Promet između tvrtki, mobilni i daljinski pristup te Webex promet na istom Expressway paru

Pozivi između tvrtki (B2B) i mobilni i daljinski pristup (MRA) upotrebljavaju ulaz 5061 za SIP TLS, a promet aplikacije Webex upotrebljava ulaz 5062 za SIP TLS s uzajamnom provjerom autentičnosti.

Provjera vlasništva nad domenom dio je provjere identiteta. Provjera domene sigurnosna je mjera i provjera identiteta koju Webex Cloud primjenjuje kako bi se dokazalo da ste ono što kažete da jeste.

Provjera identiteta provodi se u dvije faze:

1. Provjera vlasništva nad domenom. Ovaj korak uključuje tri vrste domena i jednokratna je provjera:

   • Domena e-pošte

   • DNS domena za Expressway-E

   • URI domena direktorija

2. Provjera vlasništva dns naziva za Expressway-E. Ovaj korak provodi se implementacijom TLS-a uz međusobnu autentifikaciju i uključuje korištenje javnih certifikata na oblaku i brzoj cesti. Za razliku od provjere identiteta domene, ovaj se korak izvodi tijekom bilo kojeg poziva upućenog i primljenog iz oblaka.

Važnost provjere vlasništva nad domenom

Webex oblak provodi provjeru vlasništva nad domenom kako bi nametnuo sigurnost. Krađa identiteta jedna je od mogućih prijetnji ako se ova provjera ne izvrši.

Sljedeća priča opisuje što bi se moglo dogoditi ako se ne izvrši provjera vlasništva nad domenom.

Tvrtka s DNS domenom postavljenom na "hacker.com" kupuje Hibridne usluge Webex. Druga tvrtka, s vlastitom domenom postavljenom na "example.com", također koristi hibridne usluge. Jedan od glavnih menadžera tvrtke Example.com zove se Jane Roe i ima imenik URI jane.roe@example.com.

Administratorica tvrtke Hacker.com postavlja jedan od svojih URI-ja direktorija kako bi jane.roe@example.com, a adresu e-pošte na jane.roe@hacker.com. Ona to može učiniti jer oblak ne provjerava SIP URI domenu u ovom primjeru.

Zatim se prijavljuje na aplikaciju Webex putem jane.roe@hacker.com. Budući da je vlasnica domene, e-pošta za potvrdu se čita i odgovara na njih i može se prijaviti. Naposljetku, poziva kolegu, Johnu Horu, birajući john.doe@primjer.com iz svoje aplikacije Webex. John sjedi u svom uredu i vidi poziv na svom videouređaju koji dolazi s jane.roe@primjer.com; to je URI imenika povezan s tim računom e-pošte.

"Ona je u inozemstvu", misli on. "Možda će joj trebati nešto važno." On se javlja na telefon, a lažna Jane Roe traži važne dokumente. Objašnjava da joj je uređaj pokvaren, a budući da putuje, traži od njega da dokumente pošalje na njezinu privatnu adresu e-pošte, jane.roe@hacker.com. Na taj način, tvrtka shvaća tek nakon što se Jane Roe vrati u ured da su važne informacije procurile izvan tvrtke.

Tvrtka Example.com ima mnogo načina zaštite od lažnih poziva koji dolaze s interneta, ali jedna od odgovornosti Webex oblaka jest osigurati da je identitet osoba koje nazivaju s Webexa točan i da nije krivotvoren.

Za provjeru identiteta, Webex zahtijeva da tvrtka dokaže da posjeduje domene koje se upotrebljavaju u usluzi Hybrid Calling. Ako ne uspije, hibridne usluge neće raditi.

Da biste osigurali to vlasništvo, potrebna su dva koraka provjere domene:

1. Dokažite da tvrtka posjeduje domenu e-pošte, domenu Expressway-E, URI domenu direktorija.

   • Sve te domene moraju biti usmjerive i poznate od strane javnih DNS poslužitelja.

   • Da bi dokazao vlasništvo, DNS administrator mora unijeti DNS tekstni zapis (TXT). TXT zapis je vrsta zapisa resursa u DNS-u koji se koristi za pružanje mogućnosti povezivanja nekog proizvoljnog i neoblikovanog teksta s glavnim računalom ili drugim nazivom.

   • DNS administrator mora unijeti taj TXT zapis u zonu čije vlasništvo mora biti dokazano. Nakon tog koraka, Webex oblak izvršava upit TXT zapisa za tu domenu.

   • Ako je TXT upit uspješan i rezultat odgovara tokenu koji je generiran iz Webex oblaka, provjerava se domena.

   • Kao primjer, administrator mora dokazati da je vlasnik domene "primjer.com", ako želi da hibridne usluge Webex rade na njezinoj domeni.

   • Kroz https://admin.webex.com pokreće postupak provjere stvaranjem TXT zapisa koji odgovara tokenu koji je generirao Webex oblak:

     

   • DNS administrator zatim stvara TXT zapis za tu domenu s vrijednošću postavljenom na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, kao u sljedećem primjeru:

     

   • U ovom trenutku oblak može provjeriti odgovara li TXT zapis za domenu example.com tokenu.

   • Oblak izvodi TXT DNS pretraživanje:

     

   • Budući da TXT vrijednost odgovara vrijednosti tokena, ovo podudaranje dokazuje da je administrator dodao TXT zapis za vlastitu domenu u javni DNS i da je ona vlasnik domene.

2. Provjera vlasništva DNS naziva na expressway-E.

   • Oblak mora provjeriti ima li Expressway-E potvrđeni identitet jednog od tijela za izdavanje certifikata kojem oblak vjeruje. Administrator brze ceste-E mora zatražiti javnu potvrdu za svoju brzu cestu-E jednom od tih tijela za izdavanje certifikata. Da bi izdala certifikat, ustanova za izdavanje certifikata provodi postupak provjere identiteta na temelju provjere valjanosti domene (za certifikate potvrđene domenom) ili provjere valjanosti tvrtke ili ustanove (za certifikate provjerene u tvrtki ili ustanovi).

   • Pozivi u i iz oblaka ovise o potvrdi koja je izdana na Expressway-E. Ako certifikat nije valjan, poziv se odustaje.

Webex Device Connector mora komunicirati s Webexom kako bi Hybrid Calling funkcionirao.

Webex Device Connector implementiran je u internoj mreži, a način na koji komunicira s oblakom odvija se putem izlazne HTTPS veze — iste vrste koja se koristi za bilo koji preglednik koji se povezuje s web-poslužiteljem.

Komunikacija s Webex oblakom upotrebljava TLS. Webex Device Connector je TLS klijent, a Webex Cloud TLS poslužitelj. Webex Device Connector stoga provjerava certifikat poslužitelja.

Ustanova za izdavanje certifikata potpisuje certifikat poslužitelja pomoću vlastitog privatnog ključa. Svatko s javnim ključem može dekodirati taj potpis i dokazati da je ista ustanova za izdavanje certifikata potpisala taj certifikat.

Ako Webex Device Connector mora potvrditi certifikat koji pruža oblak, mora upotrijebiti javni ključ certifikacijskog tijela koje je potpisalo taj certifikat za dekodiranje potpisa. Javni ključ nalazi se u potvrdi ustanove za izdavanje certifikata. Da biste uspostavili povjerenje s tijelima za izdavanje certifikata koje upotrebljava oblak, popis certifikata tih pouzdanih tijela za izdavanje certifikata mora se nalaziti u spremištu vjerodajnica za Webex Device Connector.

U komunikaciji s uređajima, alat upotrebljava pouzdane certifikate koje pružate. Trenutno se to može učiniti tako da ih smjestite u [home folder]/.devicestool/certs.

Popis certifikata ustanove za izdavanje certifikata potreban je i za Expressway-E u traversalnom paru. Expressway-E komunicira s Webex oblakom pomoću SIP-a s TLS-om, prisilno provedenom međusobnom provjerom autentičnosti. Expressway-E vjeruje pozive koji dolaze s oblaka i odlaze u njega, samo ako CN ili SAN certifikata koji je oblak predstavio tijekom postavljanja TLS veze odgovara nazivu subjekta konfiguriranom za DNS zonu na Expresswayu ("callservice.webex.com"). Ustanova za izdavanje certifikata izdaje certifikat tek nakon provjere identiteta. Vlasništvo nad domenom callservice.webex.com mora se dokazati kako bi se dobio potpisan certifikat. Budući da mi (Cisco) posjedujemo tu domenu, DNS naziv "callservice.webex.com" izravan je dokaz da je udaljeni kolega uistinu Webex.

konektor kalendara integrira Webex s Microsoft Exchange 2013., 2016., 2019. ili Office 365 putem računa za lažno predstavljanje. Uloga upravljanja predstavljanjem aplikacija u Exchangeu omogućuje aplikacijama da se lažno predstavljaju kao korisnici u organizaciji i da obavljaju zadatke u ime korisnika. Uloga imitacije aplikacije mora biti konfigurirana u Exchange-u i koristi se u konektoru kalendara kao dio konfiguracije Exchange-a na Expressway-C sučelju.

Microsoftov račun za predstavljanje Exchange preporučena je metoda za ovaj zadatak. Administratori usluge Expressway-C ne moraju znati zaporku jer vrijednost može unijeti administrator sustava Exchange u sučelje usluge Expressway-C. Lozinka nije jasno prikazana, čak i ako administrator usluge Expressway-C ima root pristup kutiji Expressway-C. Lozinka se pohranjuje kriptirana koristeći isti mehanizam za šifriranje vjerodajnica kao i ostale lozinke na Expressway-C-u.

Za dodatnu sigurnost, slijedite korake u Priručniku za primjenu za Cisco Webex Hybrid Calendar Service kako biste omogućili TLS kako biste osigurali EWS veze na žici.

Za dodatnu sigurnost slijedite korake u Priključku za implementaciju kalendara brze ceste za Microsoft Exchange kako biste omogućili TLS kako biste osigurali EWS veze na žici.