Namestitev parov hitre ceste-C in hitre ceste-E omogoča klice v in iz interneta z uporabo tehnologije prečkanja požarnega zidu. Ta uvedba je tisto, kar varno prevzame vaš lokalni nadzor nad klici in ga poveže z njim Cisco Webex.

Expressway-C in Expressway-E ne zahtevata odprtja nobenih vhodnih vrat v požarnem zidu demilitariziranega območja (DMZ) zaradi arhitekture prečkanja požarnega zidu. Toda signalna vrata TCP SIP in medijska vrata UDP morajo biti odprta za vhod na internetnem požarnem zidu, da omogočijo dohodne klice. Počakati morate nekaj časa, da se na požarnem zidu vašega podjetja odprejo ustrezna vrata.

Arhitektura prečkanja požarnega zidu je prikazana v naslednjem diagramu:

Na primer, za dohodne klice med podjetji (B2B), ki uporabljajo protokol SIP, morajo biti vrata TCP 5060 in 5061 (5061 se uporablja za SIP TLS) odprta na zunanjem požarnem zidu, skupaj z medijskimi vrati UDP, ki se uporabljajo za storitve, kot je govor , video, deljenje vsebine, dvojni video itd. Katera medijska vrata odpreti, je odvisno od števila sočasnih klicev in števila storitev.

Prisluškovalna vrata SIP na hitri cesti lahko konfigurirate na katero koli vrednost med 1024 in 65534. Istočasno morata biti ta vrednost in vrsta protokola objavljena v javnih zapisih DNS SRV, ta ista vrednost pa mora biti odprta na internetnem požarnem zidu.

Čeprav je standard za SIP TCP 5060 in za SIP TLS 5061, nič ne preprečuje uporabe različnih vrat, kot prikazuje naslednji primer.

Primer

V tem primeru predpostavljamo, da se vrata 5062 uporabljajo za dohodne klice SIP TLS.

Zapis DNS SRV za gručo dveh strežnikov Expressway izgleda takole:

_sips._tcp.example.com Lokacija storitve SRV:

prioriteta = 10

teža = 10

vrata = 5062

ime gostitelja svr = us-expe1.example.com

_sips._tcp.example.com Lokacija storitve SRV:

prioriteta = 10

teža = 10

vrata = 5062

ime gostitelja svr = us-expe2.example.com

Ti zapisi pomenijo, da so klici usmerjeni na us-expe1.example.com in us-expe2.example.com z enako porazdelitvijo obremenitve (prioriteta in teža) z uporabo TLS kot vrste transporta in 5062 kot številke poslušajočih vrat.

Naprava, ki je zunanja v omrežju (v internetu) in ki kliče SIP uporabniku domene podjetja (user1@example.com), mora poizvedovati DNS, da razume, katero vrsto prenosa uporabiti, številko vrat, kako za porazdelitev prometa in na katere strežnike SIP poslati klic.

Če vnos DNS vključuje _sips._tcp, vnos podaja SIP TLS.

TLS je protokol odjemalec-strežnik in v najpogostejših izvedbah za preverjanje pristnosti uporablja potrdila. V scenariju klica med podjetji je odjemalec TLS klicna naprava, strežnik TLS pa klicana naprava. Pri TLS odjemalec preveri potrdilo strežnika in če preverjanje potrdila ne uspe, prekine klic. Stranka ne potrebuje potrdila.

Rokovanje TLS je prikazano v naslednjem diagramu:

Vendar pa specifikacija TLS navaja, da lahko strežnik preveri potrdilo odjemalca tudi tako, da odjemalcu med protokolom rokovanja TLS pošlje sporočilo Zahteva za potrdilo. To sporočilo je uporabno pri povezavi med strežniki, na primer pri klicu, ki je vzpostavljen med Expressway-E in Cisco Webex oblak. Ta koncept se imenuje TLS z medsebojno avtentikacijo in je potreben pri integraciji z Cisco Webex.

Tako kličoča kot klicana stran preverita potrdilo drugega vrstnika, kot prikazuje naslednji diagram:

Oblak preveri identiteto Expressway, Expressway pa preveri identiteto oblaka. Če se na primer identiteta oblaka v potrdilu (CN ali SAN) ne ujema s konfiguracijo na Expresswayu, se povezava prekine.

Če je vključena medsebojna avtentikacija, Expressway-E vedno zahteva potrdilo odjemalca. Zaradi tega mobilni in oddaljeni dostop (MRA) ne bo deloval, ker v večini primerov potrdila niso nameščena na odjemalcih Jabber. V scenariju med podjetji, če kličoča entiteta ne more zagotoviti potrdila, se klic prekine.

Priporočamo, da za TLS z medsebojnim preverjanjem pristnosti uporabite drugo vrednost kot 5061, na primer vrata 5062. Cisco Webex Hibridne storitve uporabljajo isti zapis SIP TLS, ki se uporablja za B2B. V primeru vrat 5061 nekatere druge storitve, ki ne morejo zagotoviti potrdila odjemalca TLS, ne bodo delovale.

Business-to-business, mobilni in oddaljeni dostop ter Cisco Webex prometa na istem paru hitrih cest

Klici med podjetji ter klici prek mobilnega in oddaljenega dostopa uporabljajo vrata 5061 za SIP TLS in Cisco Webex promet uporablja vrata 5062 za SIP TLS z medsebojno avtentikacijo.

Preverjanje lastništva domene je del preverjanja identitete. Preverjanje domene je varnostni ukrep in preverjanje identitete, ki ga Cisco Webex programi v oblaku, da dokažete, da ste to, za kar se predstavljate.

Preverjanje identitete poteka v dveh fazah:

1. Preverjanje lastništva domene. Ta korak vključuje tri vrste domen in je enkratno preverjanje preverjanja:

   • E-poštna domena

   • Domena DNS Expressway-E

   • Domena URI imenika

2. Preverjanje lastništva imena DNS Expressway-E. Ta korak se izvaja z implementacijo TLS z medsebojno avtentikacijo in vključuje uporabo javnih potrdil tako v oblaku kot na hitri cesti. Za razliko od preverjanja identitete domene se ta korak izvede med katerim koli klicem v oblaku in prejetim iz njega.

Zgodba, ki prikazuje pomen preverjanja lastništva domene

The Cisco Webex oblak izvaja preverjanje lastništva domene za uveljavljanje varnosti. Kraja identitete je ena od možnih groženj, če tega preverjanja ne izvedete.

Naslednja zgodba podrobno opisuje, kaj se lahko zgodi, če se preverjanje lastništva domene ne izvede.

Podjetje z domeno DNS, nastavljeno na "hacker.com", kupuje Cisco Webex Hibridne storitve. Uporablja tudi drugo podjetje z lastno domeno, nastavljeno na "example.com". hibridne storitve. Eden od generalnih direktorjev podjetja Example.com se imenuje Jane Roe in ima URI imenika jane.roe@example.com.

Skrbnik podjetja Hacker.com nastavi enega od svojih URI-jev imenika na jane.roe@example.com in e-poštni naslov na jane.roe@hacker.com. To lahko stori, ker oblak v tem primeru ne preverja domene SIP URI.

Nato se prijavi v Ekipe Cisco Webex z jane.roe@hacker.com. Ker je ona lastnica domene, se potrditveno e-poštno sporočilo prebere in nanj odgovori ter se lahko prijavi. Nazadnje pokliče kolega, Johna Doeja, tako da od nje pokliče john.doe@example.com Ekipe Cisco Webex aplikacija John sedi v svoji pisarni in na svoji video napravi vidi klic, ki prihaja z jane.roe@example.com; to je URI imenika, povezan s tem e-poštnim računom.

»V tujini je,« si misli. "Morda potrebuje nekaj pomembnega." Oglasi se na telefon in lažna Jane Roe zahteva pomembne dokumente. Pojasni, da je njena naprava pokvarjena, in ker je na potovanju, ga prosi, naj pošlje dokumente na njen zasebni e-poštni naslov, jane.roe@hacker.com. Tako podjetje šele potem, ko se Jane Roe vrne v pisarno, ugotovi, da so pomembne informacije ušle izven podjetja.

Podjetje Example.com ima veliko načinov za zaščito pred goljufivimi klici, ki prihajajo iz interneta, vendar je ena od odgovornosti Cisco Webex oblak je zagotoviti, da je identiteta vsakogar, ki kliče iz Cisco Webex je pravilna in ni ponarejena.

Če želite preveriti identiteto, Cisco Webex zahteva, da podjetje dokaže, da je lastnik domen, ki se uporabljajo v hibridno klicanje. Če ne, ne bo delovalo.

Za zagotovitev tega lastništva sta potrebna dva koraka za preverjanje domene:

1. Dokažite, da ima podjetje e-poštno domeno, domeno Expressway-E, domeno URI imenika.

   • Vse te domene morajo biti usmerljive in jih morajo poznati javni strežniki DNS.

   • Za dokaz lastništva mora skrbnik DNS vnesti besedilni zapis DNS (TXT). Zapis TXT je vrsta zapisa vira v DNS, ki se uporablja za zagotavljanje možnosti povezovanja poljubnega in neoblikovanega besedila z gostiteljskim ali drugim imenom.

   • Skrbnik DNS mora ta zapis TXT vnesti v cono, katere lastništvo mora biti dokazano. Po tem koraku, Cisco Webex oblak izvede poizvedbo zapisa TXT za to domeno.

   • Če je poizvedba TXT uspešna in se rezultat ujema z žetonom, ki je bil ustvarjen iz Cisco Webex oblak, je domena verificirana.

   • Na primer, administrator mora dokazati, da je lastnik domene "example.com", če želi Cisco Webex Hibridne storitve za delo na njeni domeni.

   • Skozi https://admin.webex.com, začne postopek preverjanja z ustvarjanjem zapisa TXT, ki se ujema z žetonom, ki ga je Cisco Webex ustvarjen oblak:

     

   • Skrbnik DNS nato ustvari zapis TXT za to domeno z vrednostjo, nastavljeno na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, kot v naslednjem primeru:

     

   • Na tej točki lahko oblak preveri, ali se zapis TXT za domeno example.com ujema z žetonom.

   • Oblak izvede iskanje TXT DNS:

     

   • Ker se vrednost TXT ujema z vrednostjo žetona, to ujemanje dokazuje, da je skrbnik dodal zapis TXT za svojo domeno v javni DNS in da je lastnica domene.

2. Preverjanje lastništva imena DNS Expressway-E.

   • Oblak mora preveriti, ali ima Expressway-E potrjeno identiteto enega od overiteljev, ki jim oblak zaupa. Skrbnik Expressway-E mora zahtevati javno potrdilo za svojo Expressway-E pri enem od teh overiteljev. Za izdajo potrdila overitelj potrdil izvede postopek preverjanja identitete na podlagi preverjanja veljavnosti domene (za potrdila, potrjena domene) ali preverjanja validacije organizacije (za potrdila, potrjena organizacije).

   • Klici v in iz oblaka so odvisni od certifikata, ki je bil izdan za Expressway-E. Če potrdilo ni veljavno, se klic prekine.

Gostitelj priključka Expressway-C mora biti registriran Cisco Webex da bi za hibridne storitve delati.

Expressway-C je nameščen v notranjem omrežju in način, kako se registrira v oblaku, je prek odhodne povezave HTTPS – istega tipa, ki se uporablja za kateri koli brskalnik, ki se poveže s spletnim strežnikom.

Registracija in komunikacija z Cisco Webex oblak uporablja TLS. Expressway-C je odjemalec TLS in Cisco Webex oblak je strežnik TLS. Tako Expressway-C preveri potrdilo strežnika.

Overitelj potrdil podpiše strežniško potrdilo s svojim zasebnim ključem. Vsakdo z javnim ključem lahko dekodira ta podpis in dokaže, da je isti overitelj potrdil podpisal to potrdilo.

Če mora Expressway-C potrditi potrdilo, ki ga zagotavlja oblak, mora za dekodiranje podpisa uporabiti javni ključ overitelja potrdil, ki je podpisal to potrdilo. Javni ključ je vsebovan v potrdilu overitelja potrdil. Za vzpostavitev zaupanja pri overiteljih potrdil, ki jih uporablja oblak, mora biti seznam potrdil teh zaupanja vrednih organov potrdil v shrambi zaupanja v Expresswayu. S tem lahko Expressway preveri, ali klic resnično prihaja iz Cisco Webex oblak.

Z ročnim nalaganjem lahko naložite vsa ustrezna potrdila overitelja potrdil v zaupanja vredno shrambo Expressway-C.

S samodejnim nalaganjem oblak sam naloži ta potrdila v shrambo zaupanja Expressway-C. Priporočamo, da uporabite samodejno nalaganje. Seznam potrdil se lahko spremeni, samodejno nalaganje pa zagotavlja, da dobite najnovejši seznam.

Če dovolite samodejno namestitev potrdil overitelja potrdil, boste preusmerjeni na https://admin.webex.com (portal za upravljanje). Preusmeritev izvede hitra cesta-C sama brez posredovanja uporabnika. Ti, kot Cisco Webex skrbnik, se mora overiti prek povezave HTTPS. Kmalu zatem oblak potisne potrdila CA na Expressway-C.

Dokler potrdila niso naložena v shrambo zaupanja Expressway-C, povezave HTTPS ni mogoče vzpostaviti.

Da bi se izognili tej težavi, je Expressway-C vnaprej nameščen z Cisco Webex-zaupanja vredni certifikati CA. Ta potrdila se uporabljajo samo za nastavitev in preverjanje začetne povezave HTTPS in niso prikazana na seznamu zaupanja vrednih Expressway-C. Ko so potrdila zaupanja vrednih overiteljev potrjena iz oblaka prek te začetne povezave HTTPS, so ta potrdila na voljo za uporabo na celotni platformi; potem se prikažejo na seznamu zaupanja Expressway-C.

Ta seznam prikazuje potrdila overitelja potrdil, ki jih je Cisco Webex oblak trenutno uporablja. Ta seznam se lahko v prihodnosti spremeni:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=ZDA, O=The Go Daddy Group, Inc., OU=Organ za potrdila razreda 2 Go Daddy

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - Samo za pooblaščeno uporabo, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=javna primarna overitelja potrdil razreda 3

Za Expressway-E v paru prečkanja je potreben tudi seznam potrdil overitelja potrdil. Expressway-E komunicira z Cisco Webex oblak, ki uporablja SIP s TLS, uveljavljen z medsebojno avtentikacijo. Expressway-E zaupa klicem, ki prihajajo iz oblaka in gredo vanj, le če se CN ali SAN potrdila, ki ga je predstavil oblak med nastavitvijo povezave TLS, ujema z imenom subjekta, konfiguriranim za območje DNS na Expresswayu ("callservice.ciscospark.com"). Certifikator izda potrdilo šele po preverjanju identitete. Lastništvo nad callservice.ciscospark.com domena mora biti dokazana za podpis potrdila. Ker smo mi (Cisco) lastnik te domene, ime DNS "callservice.ciscospark.com" je neposreden dokaz, da je oddaljeni vrstnik resnično Cisco Webex.

Koledar Connector integrira Cisco Webex z Microsoft Exchange 2010, 2013, 2016 ali Office 365 prek lažnega računa. Vloga za upravljanje poosebljanja aplikacij v Exchangeu omogoča aplikacijam, da poosebljajo uporabnike v organizaciji za izvajanje nalog v imenu uporabnika. Vloga poosebljanja aplikacije mora biti konfigurirana v Exchangeu in se uporablja v Koledar Connector kot del konfiguracije Exchange na Hitra cesta-C vmesnik.

Microsoftov priporočeni način za to nalogo je lažni račun Exchange. Hitra cesta-C skrbnikom ni treba poznati gesla, saj lahko vrednost vnesete v Hitra cesta-C skrbnik Exchangea. Geslo ni jasno prikazano, tudi če je Hitra cesta-C skrbnik ima korenski dostop do Hitra cesta-C škatla. Geslo je shranjeno šifrirano z istim mehanizmom šifriranja poverilnic kot druga gesla na Hitra cesta-C.

Za dodatno varnost sledite korakom v Priročnik za uvajanje za storitev hibridnega koledarja Cisco Webex da omogočite TLS za zaščito povezav EWS na žici.