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

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

• Želimo im objasniti kako biste razumjeli njihovu ulogu u hibridnoj implementaciji i osjećali se uvjereno.

• Oni su obavezni preduvjeti koji osiguravaju sigurnu implementaciju između našeg oblaka i vašeg lokalnog okruženja.

• Treba ih tretirati kao nulte aktivnosti prije dana: dovršavanje može potrajati malo duže od tipične konfiguracije u korisničkom sučelju, pa dopustite vremenski okvir za sortiranje tih stavki.

• Nakon što se ove stavke riješe u vašem okruženju, ostatak konfiguracije hibridnih usluga proći će glatko.

Implementacija parova Expressway-C i Expressway-E omogućuje pozive na i s Interneta pomoću tehnologija prelaska vatro zida. Ova implementacija sigurno preuzima kontrolu nad lokalnim pozivima i povezuje je s Webexom.

Expressway-C i Expressway-E ne zahtijevaju otvaranje ulaznog porta u vatrozidu demilitarizirane zone (DMZ) zbog arhitekture prelaska vatrozida. Ali TCP SIP signalni portovi i UDP medijski portovi moraju se otvoriti dolazno na internetskom vatrozidu kako bi se omogućilo dolaznim pozivima dolaziti. Morate dati vremena da se otvori odgovarajući priključak na vatrozidu vašeg poduzeća.

Arhitektura prelaska vatrozida prikazana je na sljedećem dijagramu:

Na primjer, za ulazne pozive između poduzeća (B2B) koji koriste SIP protokol, TCP portovi 5060 i 5061 (5061 se koristi za SIP TLS) moraju se otvoriti na vanjskom vatrozidu, zajedno s UDP medijskim portovima koji se koriste za usluge kao što su glas, video, dijeljenje sadržaja, dvostruki video i tako dalje. Koje medijske portove otvor iti ovisi o broju istodobnih poziva i broju usluga.

SIP priključak za slušanje na Expressway možete konfigurirati tako da ima bilo koju vrijednost između 1024 i 65534. Istodobno, ta vrijednost i vrsta protokola moraju se oglašavati u javnim DNS SRV zapisima, a ta ista vrijednost mora se otvoriti na internetskom vatrozidu.

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

Primjer

U ovom primjeru pretpostavljamo da se port 5062 koristi za dolazne SIP TLS pozive.

Zap DNS SRV is za skup dva poslužitelja Expressway izgleda ovako:

_gutljaj. _tcp.example .com SRV lokacija servisa:

priority = 10

weight = 10

port = 5062

svr ime hosta = us-expe1.example.com

_gutljaje. _tcp.example .com SRV lokacija servisa:

priority = 10

weight = 10

port = 5062

svr ime hosta = us-expe2.example.com

Ovi zapisi znače da su pozivi usmjereni na us-expe1.example.com i us-expe2.example.com s jednakim dijeljenjem tereta (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 upitati DNS kako bi razumio koju vrstu prijevoza koristiti, broj porta, kako učitati i dijeliti promet i na koje SIP poslužitelje poslati poziv.

Ako DNS unos uključuje _gutljaje. _tcp, un os određuje SIP TLS.

TLS je protokol klijent-poslužitelj i, u najčešćim implementacijama, koristi certifikate za provjeru autentičnosti. U scenariju poziva između poduzeća, TLS klijent je uređaj za pozivanje, a TLS posluž itelj je pozivni uređaj. Pomoću TLS-a klijent provjerava certifikat poslužitelja, a ako provjera certifik ata ne uspije, isključuje poziv . Klijentu nije potreban certifikat.

TLS rukovanje prikazano je na sljedećem dijagramu:

Međutim, TLS specifikacija navodi da poslužitelj također može provjeriti klijentski certifikat slanjem poruke zahtjeva za certifikat klijentu tijekom protokola TLS stiskanja ruke . Ova je poruka korisna za vezu poslužitelja na poslužitelj, kao što je na poziv koji je uspostavljen između Expressway-E i Webex oblaka. Taj se koncept naziva TLS s međusobnom autentifikacijom i potreban je prilikom integracije s Webexom.

I pozivne i pozivane strane provjeravaju potvr du drugog vršnjaka, kao što pokazuje sljedeći dijagram:

Oblak provjerava identitet brze ceste, a Expressway provjerava identitet oblaka. Na primjer, ako identitet oblaka u certifikatu (CN ili SAN) ne odgovara onome što je konfigurirano na Expressway, veza se prekida.

Ako je uključena međusobna provjera autentičnosti, Expressway-E uvijek traži klijentski certifikat. Kao rezultat toga, Mobile i Remote Access (MRA) neće raditi, jer se u većini slučajeva certifikati ne primjenjuju na Jabber klijentima. U scenariju između poduzeća, ako subjekt koji poziva ne može dostaviti certifikat, poziv se isključuje.

Preporučujemo da koristite vrijednost koja nije 5061 za TLS s međusobnom autentifikacijom, kao što je port 5062. Webex Hybrid Services koristi isti SIP TLS zapis koji se koristi za B2B. U slučaju porta 5061, neke druge usluge koje ne mogu pružiti certifikat TLS klijenta neće raditi.

Ako se postojeći zapis već koristi za komunikaciju između poduzeća, preporuč ujemo da navedete poddomenu korporativne domene kao odredište SIP u Control Hubu, a time i javni DNS SRV zapis , kako slijedi:

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

Poslovno-poslovni, mobilni Remote Access i Webex promet na istom paru brze ceste

Poslovno-poslovni (B2B) i mobilni i Remote Access (MRA) pozivi koriste port 5061 za SIP TLS, a Webex promet koristi port 5062 za SIP TLS uz međusobnu provjeru autentičnosti.

Provjera vlasništva domene dio je provjere identiteta. Provjera domene sigurnosna je mjera i provjera identiteta koju Webex oblak implementira kako bi dokazao da ste ono za koga kažete da jeste.

Provjera identiteta provodi se u dvije faze:

1. Provjera vlasništva domene. Ovaj korak uključuje tri vrste domena i predstavlja jednokratnu provjeru provjere:

   • Domena e-pošte

   • Expressway-E DNS domena

   • URI domena direktorija

2. Expressway-E DNS provjera vlasništva imena. Ovaj se korak provodi kroz implementaciju TLS-a uz međusobnu provjeru autentičnosti i uključuje korištenje javnih certifikata i na oblaku i na 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 domene

Webex oblak provodi provjeru vlasništva domene radi provođenja sigurnosti. Krađa identiteta jedna je od mogućih prijetnji ako se ova provjera ne izvrši.

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

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

Administrator tvrtke Hacker.com postavlja jedan od svojih URI-ova direktorija na 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 Webex App putem jane.roe@hacker.com. Budući da je vlasnik domene, e-mail za potvrdu se čita i odgovara, a ona se može prijaviti. Konačno, poziva kolegu, Johna Doea, pozivanjem na john.doe@example.com iz svoje Webex aplikacije. John sjedi u svom uredu i vidi poziv na svom video uređaju koji dolazi s jane.roe@example.com; to je URI direktorija povezan s tim računom e-pošte.

"Ona je u inozemstvu", misli. Možda će joj trebati nešto važno." Odgovara na telefon, a lažna Jane Roe traži važne dokumente. Objašnjava kako 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 je osigurati da je identitet svakoga tko zove s Webexa točan i da nije krivotvoren.

Da bi provjerio identitet, Webex zahtijeva da tvrtka dokaže da posjeduje domene koje se koriste u hibridnom pozivanju. Ako se to ne dogodi, Hybrid Services neće raditi.

Da bi se osiguralo ovo vlasništvo, potrebna su dva koraka provjere domene:

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

   • Sve te domene moraju biti usmjerljive i poznate javnim DNS poslužiteljima.

   • Da bi dokazao vlasništvo, DNS administrator mora unijeti DNS tekst zapis (TXT). TXT zapis je vrsta zapisa resursa u DNS-u koji se koristi za pružanje mogućnosti povezivanja nekog proizvoljnog i neformatiranog teksta s hostom ili drugim imenom.

   • 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, domena se provjerava.

   • Kao primjer, administrator mora dokazati da posjeduje domenu "example.com", ako želi da Webex Hybrid Services radi na njenoj domeni.

   • Pu tem https://admin.webex.com započinje postupak provjere stvaranjem TXT zapisa koji odgovara tokenu koji je Webex oblak stvorio:

     

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

     

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

   • Oblak vrši TXT DNS pretraživanje:

     

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

2. Expressway-E DNS provjera vlasništva imena.

   • Oblak mora provjeriti ima li Expressway-E potvrđeni identitet jednog od tijela certifikata kojima oblak vjeruje. Administrator Expressway-E mora zatražiti javnu potvrdu za svoj Expressway-E jednom od tih tijela za certifikaciju. Da bi izdao certifikat, tijelo za certifikat provodi postupak provjere identiteta na temelju provjere provjere valjanosti domene (za certifikate potvrđene domene) ili provjere valjanosti organizacije (za certifikate potvrđene organizacije).

   • Pozivi u oblak i iz njega ovise o certifikatu koji je izdan Expressway-E. Ako potvrda nije valjana, poziv se odustaje.

Webex priključak uređaja mora komunicirati s Webexom kako bi hibridno pozivanje moglo funkcionirati.

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

Komunikacija s Webex oblakom koristi TLS. Webex Device Connector je TLS klijent, a Webex oblak je TLS poslužitelj. Kao takav, Webex Device Connector provjerava certifikat poslužitelja.

Tijelo za certifikat potpisuje certifikat poslužitelja pomoću vlastitog privatnog ključa. Svatko tko ima javni ključ može dekodirati taj potpis i dokazati da je isti certifikat potpisao taj certifikat.

Ako Webex Device Connector mora potvrditi potvrdu koju pruža oblak, za dekodiranje potpisa mora upotrijebiti javni ključ tijela za certifikat koji je potpisao taj certifikat. Jav ni ključ sadržan je u potvrdi tijela za certifikat. Da biste uspostavili povjerenje s nadležnim tijelima za certifikate koje koristi oblak, popis certifikata tih vjerodostojnih tijela za certifikate mora se nalaziti u trgovini poverenja Webex Device Connector.

Kada komunicirate s uređajima, alat koristi pouzdane certifikate koje pružate. Trenutno je način da se to postigne stavljanjem unutra [home folder]/.devicestool/certs.

Popis certifikata ovlaštenja certifikata također je potreban za Expressway-E u paru za prelaz ak. Expressway-E komunicira s Webex oblakom koristeći SIP s TLS-om, koji se provodi međusobnom autentifikacijom. Expressway-E vjeruje pozivima koji dolaze iz oblaka i idu 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"). Tijelo za certifikaciju izdaje potvrdu tek nakon provjere identiteta. Vlasništvo domene callservice.webex.com mora biti dokazano da bi se potvrdio potpis certifikata. Budući da mi (Cisco) posjedujemo tu domenu, DNS naziv "callservice.webex.com" izravan je dokaz da je udaljeni peer uistinu Webex.

konektor kalendara integrira Webex s Microsoft Exchange 2013., 2016., 2019. ili Office 365 putem računa za lažno predstavljanje. Uloga upravljanja lažnim predstavljanjem aplikacija u programu Exchange omogućuje aplikacijama da se predstavljaju kao korisnike u organizaciji kako bi izvršavali zadatke u ime korisnika. Uloga predstavljanja aplikacije mora biti konfigurirana u programu Exchange i koristi se u konektoru kalendara kao dio konfiguracije sustava Exchange na Expressway-C sučelju.

Račun za lažno predstavljanje sustava Exchange preporučena je Microsoftova metoda za ovaj zadatak. Administratori Expressway-C ne moraju znati lozinku jer Exchange administrator može unijeti vrijednost u Expressway-C sučelje. Lozinka nije jasno prikazana, čak i ako administrator Expressway-C ima root pristup Expressway-C okviru. Lozinka se pohranjuje šifrirano pomoću istog mehanizma šifriranja vjerodajnica kao i druge lozinke na Expressway-C.

Za dodatnu sigurnost slijedite korake u V odiču za implementaciju usluge Cisco Webex hibridnog kalend ara kako biste omogućili TLS kako biste osigurali EWS veze na žici.

Za dodatnu sigurnost slijedite korake u odjeljku Postavljanje konektora za kalendar brze ceste kako Microsoft Exchange biste omogućili TLS kako biste osigurali EWS veze na žici.