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

Ove tačke su ključne ako želite da uspešno primenite hibridno pozivanje za Vebek uređaje. Ove stavke smo posebno istakli iz sledećih razloga:

• Želimo da ih objasnimo, tako da razumete njihovu ulogu u hibridnoj implementaciji i osećate se sigurnim.

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

• Treba ih tretirati kao preddnevne nulte aktivnosti: Oni mogu potrajati malo duže od tipične konfiguracije u korisničkom interfejsu, tako da dozvolite vremenski okvir da se ove stavke sortiraju.

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

Autoput-C i Autoput-E par raspoređivanje omogućava pozive na i sa Interneta koristeći firevall prelazak tehnologije. Ova primena je ono što sigurno uzima vašu kontrolu poziva u prostorijama i povezuje je sa Vebeksom.

Autoput-C i Autoput-E ne zahtevaju nikakav ulazni port da se otvori u demilitarizovanoj zoni (DMZ) zaštitni zid zbog arhitekture zaštitnog zida. Ali TCP SIP signalni portovi i UDP medijski portovi moraju biti otvoreni dolazni na Internet firevall kako bi dolazni pozivi doći. Morate dozvoliti vremena da se odgovarajući port otvori na vašem preduzeću firevall.

Arhitektura prelaska zaštitnog zida prikazana je na sledećem dijagramu:

Na primer, za dolazne business-to-business (B2B) pozive koji koriste SIP protokol, TCP portovi 5060 i 5061 (5061 se koristi za SIP TLS) moraju biti otvoreni na spoljnom zaštitnom zidu, zajedno sa UDP medijskim portovima koji se koriste za usluge kao što su glas, video, deljenje sadržaja, dual video i tako dalje. Koji medijski portovi za otvaranje zavisi od broja istovremenih poziva i broja usluga.

Možete konfigurisati SIP priključak za slušanje na Autoputu da bude bilo koja vrednost između 1024 do 65534. Istovremeno, ova vrednost i tip protokola moraju se oglašavati u javnim DNS SRV zapisima, a ta ista vrednost mora biti otvorena na Internet firevall-u.

Iako je standard za SIP TCP 5060 i za SIP TLS 5061, ništa ne sprečava korišćenje različitih portova, kao što pokazuje sledeći primer.

Primer

U ovom primeru, pretpostavljamo da se port KSNUMKS koristi za dolazne SIP TLS pozive.

DNS SRV zapis za klaster od dva Expressvai servera izgleda ovako:

_sips_tcp.. example.com SRV servisna lokacija:

prioritet = 10

težina = 10

port = 5062

svr hostname = us-expe1.example.com

_sips_tcp.. example.com SRV servisna lokacija:

prioritet = 10

težina = 10

port = 5062

svr hostname = us-expe2.example.com

Ovi zapisi znače da su pozivi usmereni na us-expe1.example.com i us-expe2.example.com sa jednakom podelom opterećenja (prioritet i težina) koristeći TLS kao tip transporta i KSNUMKS kao broj porta za slušanje.

Uređaj koji je spoljni u odnosu na mrežu (na Internetu) i koji upućuje SIP poziv korisniku korporativnog domena (user1@example.com) mora da upita DNS da bi razumeo koji tip transporta da koristi, broj porta, kako da učitate i delite saobraćaj i na koje SIP servere da pošaljete poziv.

Ako DNS unos uključuje _sips._tcp, unos određuje SIP TLS.

TLS je protokol klijent-server i, u najčešćim implementacijama, koristi sertifikate za autentifikaciju. U scenariju poslovnog poziva, TLS klijent je uređaj za pozivanje, a TLS server je pozvani uređaj. Sa TLS-om, klijent proverava sertifikat servera, a ako provera sertifikata ne uspe, prekida poziv. Klijentu nije potreban sertifikat.

TLS rukovanje je prikazano na sledećem dijagramu:

Međutim, TLS specifikacija navodi da server takođe može da proveri sertifikat klijenta slanjem poruke o zahtevu za sertifikat klijentu tokom TLS protokola rukovanja. Ova poruka je korisna na vezi između servera i servera, kao što je poziv koji je uspostavljen između Autoput-E i Vebek oblaka. Ovaj koncept se zove TLS sa uzajamnom autentifikacijom i potreban je prilikom integracije sa Vebeksom.

I pozivajuće i pozvane strane proveravaju sertifikat drugog vršnjaka, kao što je prikazano na sledećem dijagramu:

Oblak proverava identitet autoputa, a Autoput proverava identitet oblaka. Na primer, ako identitet oblaka u sertifikatu (CN ili SAN) ne odgovara onome što je konfigurisano na autoputu, veza je odbačena.

Ako je uključena uzajamna autentifikacija, Autoput-E uvek traži sertifikat klijenta. Kao rezultat toga, mobilni i daljinski pristup (MRA) neće raditi, jer u većini slučajeva sertifikati nisu raspoređeni na Jabber klijentima. U scenariju business-to-business, ako entitet koji poziva nije u mogućnosti da obezbedi sertifikat, poziv se prekida.

Preporučujemo da koristite drugu vrednost osim 5061 za TLS sa uzajamnom autentifikacijom, kao što je port 5062. Vebek hibridne usluge koriste isti SIP TLS zapis koji se koristi za BKSNUMKSB. U slučaju porta 5061, neke druge usluge koje ne mogu da obezbede TLS klijentski sertifikat neće raditi.

Ako se postojeći zapis već koristi za komunikaciju između preduzeća, preporučujemo da navedete poddomen korporativnog domena kao SIP odredište u Control Hub-u, a samim tim i javni DNS SRV zapis, na sledeći način:

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

Business-to-Business, mobilni i daljinski pristup i Vebek saobraćaj na istom paru autoputa

Business-to-business (BKSNUMKSB) i mobilni i daljinski pristup (MRA) pozivi koriste port KSNUMKS za SIP TLS, a Vebek saobraćaj koristi port KSNUMKS za SIP TLS sa međusobnom autentifikacijom.

Provera vlasništva nad domenom je deo verifikacije identiteta. Verifikacija domena je bezbednosna mera i provera identiteta koju Vebek oblak implementira kako bi dokazao da ste ono što kažete da jeste.

Provera identiteta se vrši u dve faze:

1. Provera vlasništva nad domenom. Ovaj korak uključuje tri vrste domena i predstavlja jednokratnu verifikaciju:

   • Domen e-pošte

   • Autoput-E DNS domen

   • Direktorijum URI domen

2. Autoput-E DNS provera vlasništva nad imenom. Ovaj korak se izvodi kroz implementaciju TLS-a sa uzajamnom autentifikacijom i uključuje upotrebu javnih sertifikata i na oblaku i na autoputu. Za razliku od provere identiteta domena, ovaj korak se izvodi tokom bilo kog poziva upućenog i primljenog iz oblaka.

Značaj provere vlasništva nad domenom

Vebek oblak vrši proveru vlasništva nad domenom kako bi sproveo sigurnost. Krađa identiteta je jedna od mogućih pretnji ako se ova provera ne izvrši.

Sledeća priča detaljno opisuje šta bi se moglo desiti ako se ne izvrši provera vlasništva nad domenom.

Kompanija sa DNS domenom postavljenim na "hacker.com" kupuje Vebek hibridne usluge. Druga kompanija, sa sopstvenim domenom postavljenim na "example.com", takođe koristi hibridne usluge. Jedan od generalnih direktora kompanije Example.com zove se Jane Roe i ima direktorijum URI jane.roe@example.com.

Administrator Hacker.com kompanije postavlja jedan od URI-ja direktorijuma na jane.roe@example.com i adresu e-pošte na jane.roe@hacker.com. Ona to može učiniti jer oblak ne proverava SIP URI domen u ovom primeru.

Zatim se prijavljuje u Vebek aplikaciju sa jane.roe@hacker.com. Budući da je vlasnik domena, e-pošta za verifikaciju se čita i odgovara, a ona se može prijaviti. Konačno, ona poziva kolegu, John Doe, biranjem john.doe@example.com iz svoje Vebek aplikacije. Džon sedi u svojoj kancelariji i vidi poziv na svom video uređaju koji dolazi iz jane.roe@example.com; to je URI direktorijuma povezan sa tim nalogom e-pošte.

"Ona je u inostranstvu", 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. Ona objašnjava da je njen uređaj pokvaren, a pošto putuje, ona ga zamoli da pošalje dokumente na njenu privatnu adresu e-pošte, jane.roe@hacker.com. Na ovaj način, kompanija shvata tek nakon što se Jane Roe vrati u kancelariju da su važne informacije procurile izvan kompanije.

Kompanija Example.com ima mnogo načina da se zaštiti od lažnih poziva koji dolaze sa Interneta, ali jedna od odgovornosti Vebek oblaka je da se uverite da je identitet bilo koga ko zove iz Vebek-a tačan i da nije falsifikovan.

Da bi proverio identitet, Vebek zahteva da kompanija dokaže da poseduje domene koji se koriste u hibridnom pozivanju. Ako se to ne desi, hibridne usluge neće raditi.

Da bi se osiguralo ovo vlasništvo, potrebna su dva koraka verifikacije domena:

1. Dokažite da kompanija poseduje domen e-pošte, Autoput-E domen, Direktorijum URI domen.

   • Svi ti domeni moraju biti rutabilni i poznati javnim DNS serverima.

   • Da bi dokazao vlasništvo, DNS administrator mora da unese DNS tekstualni zapis (TKST). TKST zapis je vrsta zapisa resursa u DNS-u koji se koristi za pružanje mogućnosti povezivanja nekog proizvoljnog i neformatiranog teksta sa domaćinom ili drugim imenom.

   • DNS administrator mora da unese taj TKST zapis u zonu čije vlasništvo mora biti dokazano. Nakon tog koraka, Vebek oblak vrši upit TKST zapisa za taj domen.

   • Ako je TKST upit uspešan i rezultat se podudara sa tokenom koji je generisan iz Vebek oblaka, domen se verifikuje.

   • Na primer, administrator mora dokazati da poseduje domen "example.com", ako želi da Vebek hibridne usluge rade na njenom domenu.

   • Kroz https://admin.webex.com, ona započinje proces verifikacije kreiranjem TKST zapisa koji odgovara tokenu koji je generisao Vebek oblak:

     

   • DNS administrator zatim kreira TKST zapis za ovaj domen sa vrednošću postavljenom na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, kao u sledećem primeru:

     

   • U ovom trenutku, oblak može da potvrdi da li se TKST zapis za domen example.com podudara sa tokenom.

   • Oblak vrši TKST DNS pretragu:

     

   • Budući da se TKST vrednost podudara sa vrednošću tokena, ovo podudaranje dokazuje da je administrator dodao TKST zapis za svoj domen u javni DNS i da je ona vlasnik domena.

2. Autoput-E DNS Provera vlasništva nad imenom.

   • Oblak mora da proveri da li Autoput-E ima potvrđen identitet od jednog od sertifikata autoriteta da oblak veruje. Administrator Autoput-E mora zatražiti javni sertifikat za svoj Autoput-E jednom od tih organa za izdavanje sertifikata. Da bi izdao sertifikat, autoritet za sertifikate vrši proces verifikacije identiteta, na osnovu provere validacije domena (za sertifikate validirane domenom) ili provere validacije organizacije (za sertifikate potvrđene organizacijom).

   • Pozivi na i iz oblaka zavise od sertifikata koji je izdat Autoput-E. Ako sertifikat nije važeći, poziv se odbacuje.

Konektor Vebek uređaja mora komunicirati sa Vebeksom kako bi hibridni pozivi radili.

Webex Device Connector je raspoređen u internoj mreži, a način na koji komunicira sa oblakom je preko odlazne HTTPS veze - istog tipa koji se koristi za bilo koji pretraživač koji se povezuje sa veb serverom.

Komunikacija sa Vebek oblakom koristi TLS. VeWebex Device Connector je TLS klijent, a Vebek oblak je TLS server. Kao takav, Vebek Device Connector proverava sertifikat servera.

Autoritet za sertifikate potpisuje sertifikat servera koristeći svoj privatni ključ. Svako ko ima javni ključ može da dekodira taj potpis i dokaže da je isti autoritet za sertifikate potpisao taj sertifikat.

Ako Veeks Device Connector mora da potvrdi sertifikat koji pruža oblak, mora da koristi javni ključ autoriteta za sertifikate koji je potpisao taj sertifikat da bi dekodirao potpis. Javni ključ je sadržan u sertifikatu autoriteta za sertifikate. Da biste uspostavili poverenje sa autoritetima sertifikata koje koristi oblak, lista sertifikata ovih pouzdanih autoriteta za sertifikate mora biti u prodavnici poverenja Vebek Device Connector-a.

Kada komunicirate sa uređajima, alat koristi pouzdane sertifikate koje pružate. Trenutno je način da se to uradi tako što ćete ih staviti u [home folder]/.devicestool/certs.

Lista sertifikata sertifikata je takođe potrebna za Autoput-E u prelaznom paru. Autoput-E komunicira sa Vebek oblakom koristeći SIP sa TLS-om, koji se sprovodi uzajamnom autentifikacijom. Autoput-E veruje pozivima koji dolaze i odlaze u oblak, samo ako CN ili SAN sertifikata predstavljenog od strane oblaka tokom podešavanja TLS veze odgovara nazivu subjekta konfigurisanom za DNS zonu na autoputu ("callservice.webex.com"). Autoritet za sertifikate izdaje sertifikat tek nakon provere identiteta. Vlasništvo nad callservice.webex.com domenom mora biti dokazano da bi se potpisao sertifikat. Zato što mi (Cisco) posedujemo taj domen, DNS ime "callservice.webex.com" je direktan dokaz da je udaljeni vršnjak zaista Vebek.

konektor kalendara integriše Vebek sa Microsoft Ekchange KSNUMKS, KSNUMKS, KSNUMKS ili Office KSNUMKS putem naloga za lažno predstavljanje. Uloga upravljanja lažnim predstavljanjem aplikacija u Ekchange-u omogućava aplikacijama da se lažno predstavljaju kao korisnici u organizaciji da obavljaju zadatke u ime korisnika. Uloga lažnog predstavljanja aplikacije mora biti konfigurisana u Ekchange i koristi se u konektoru kalendara kao deo konfiguracije Ekchange na Autoput-C interfejsu.

Račun za lažno predstavljanje Ekchange je Microsoftov preporučeni metod za ovaj zadatak. Autoput-C administratori ne moraju da znaju lozinku, jer vrednost može da se unese u Autoput-C interfejs od strane administratora Ekchange. Lozinka nije jasno prikazana, čak i ako administrator Autoput-C ima root pristup kutiji Autoput-C. Lozinka se čuva šifrovana pomoću istog mehanizma za šifrovanje akreditiva kao i druge lozinke na Autoputu-C.

Za dodatnu sigurnost, pratite korake u Vodiču za raspoređivanje Cisco Vebek hibridnog kalendara kako biste omogućili TLS kako biste osigurali EVS veze na žici.

Za dodatnu sigurnost, pratite korake u Razmenite konektor kalendara autoputa za Microsoft Ekchange da biste omogućili TLS kako biste osigurali EVS veze na žici.