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 hibridne pozive 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 ove stavke riješe u vašem okruženju, ostatak konfiguracije hibridnih usluga proći će glatko.

Implementacija para Expressway-C i Expressway-E omogućuje pozive prema i s interneta korištenjem tehnologija prolaska kroz vatrozid. Ovo postavljanje 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.example.com Lokacija SRV usluge:

prioritet = 10

težina = 10

priključak = 5062

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

_sips._tcp.example.com Lokacija SRV usluge:

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 poruka je korisna kod veze između poslužitelja, kao što je poziv koji se uspostavlja između Expressway-E i Webex oblaka. Ovaj koncept se naziva TLS s međusobnom autentifikacijom i potreban je prilikom integracije s Webexom.

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. Webex hibridne usluge koriste isti SIP TLS zapis koji se koristi 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ć koristi za komunikaciju između tvrtki, preporučujemo da u Control Hubu navedete poddomenu korporativne domene kao SIP odredište, a posljedično 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 

Promet između tvrtki, mobilni i udaljeni pristup te Webex promet na istom paru Expresswaya

Pozivi između tvrtki (B2B) i mobilni i udaljeni pristup (MRA) koriste port 5061 za SIP TLS, a Webex promet koristi port 5062 za SIP TLS s međusobnom autentifikacijom.

Provjera vlasništva nad domenom dio je provjere identiteta. Verifikacija domene je sigurnosna mjera i provjera identiteta koju Webex cloud implementira kako bi dokazao da ste vi osoba za koju se predstavljate.

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 domene

Webex oblak provodi provjeru vlasništva domene kako bi se osigurala 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 Webex Hybrid Services. 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 u Webex aplikaciju s 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. Napokon, ona zove kolegu, Johna Doea, birajući broj john.doe@example.com iz njezine Webex aplikacije. Ivan sjedi u svom uredu i na videouređaju vidi poziv koji dolazi od jane.roe@example.com; to je URI direktorija 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 clouda je osigurati da je identitet svakoga tko zove s Webexa točan i da nije krivotvoren.

Za provjeru identiteta, Webex zahtijeva da tvrtka dokaže da je vlasnik domena koje se koriste u hibridnom pozivu. Ako to ne učini, 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 generiranom iz Webex oblaka, domena je provjerena.

   • Na primjer, administratorica mora dokazati da je vlasnik domene "example.com" ako želi da Webex Hybrid Services radi na njezinoj domeni.

   • Putem https://admin.webex.compokreće proces provjere stvaranjem TXT zapisa koji odgovara tokenu koji je generirao Webex oblak:

     

   • DNS administrator zatim stvara TXT zapis za ovu 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 hibridno pozivanje funkcioniralo.

Webex Device Connector je implementiran 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 cloud je TLS poslužitelj. Stoga Webex Device Connector 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 provjeriti valjanost certifikata koji pruža oblak, mora upotrijebiti javni ključ tijela za izdavanje certifikata koje je potpisalo taj certifikat za dekodiranje potpisa. Javni ključ nalazi se u potvrdi ustanove za izdavanje certifikata. Za uspostavljanje povjerenja s tijelima za izdavanje certifikata koje koristi oblak, popis certifikata tih pouzdanih tijela za izdavanje certifikata mora biti u spremištu pouzdanih certifikata Webex Device Connectora.

Prilikom komunikacije s uređajima, alat koristi pouzdane certifikate koje vi navedete. Trenutno se to može učiniti postavljanjem 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 koristeći SIP s TLS-om, uz međusobnu autentifikaciju. Expressway-E vjeruje pozivima koji dolaze iz oblaka i odlaze u oblak samo ako se CN ili SAN certifikata koji oblak predstavlja tijekom postavljanja TLS veze podudara s nazivom subjekta konfiguriranim 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 potpisani certifikat. Budući da mi (Cisco) posjedujemo tu domenu, DNS naziv "callservice.webex.com" je izravan dokaz da je udaljeni peer zaista 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.

Račun za oponašanje sustava Exchange preporučena je metoda tvrtke Microsoft 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.