Această secțiune oferă context suplimentar despre elementele cheie de configurare care se referă la Serviciile hibride.

Aceste puncte sunt esențiale dacă doriți să implementați cu succes Hybrid Calling pentru dispozitivele Webex. Am evidențiat aceste elemente în special din următoarele motive:

• Vrem să le explicăm, astfel încât să înțelegeți rolul lor într-o implementare hibridă și să vă simțiți liniștiți.

• Acestea sunt cerințe preliminare obligatorii care asigură o implementare sigură între cloud-ul nostru și mediul local.

• Acestea ar trebui să fie tratate ca activități înainte de ziua zero: acestea pot dura un pic mai mult pentru a finaliza decât configurația tipică într-o interfață cu utilizatorul, astfel încât să permită un interval de timp pentru a obține aceste elemente sortate.

• După ce aceste elemente sunt abordate în mediul dvs., restul configurației Serviciilor hibride va funcționa fără probleme.

Implementarea perechilor Expressway-C și Expressway-E permite apeluri către și de pe internet utilizând tehnologii de traversare firewall. Această implementare preia în siguranță controlul apelurilor locale și îl conectează la Webex.

Expressway-C și Expressway-E nu necesită niciun port de intrare pentru a fi deschis în firewall-ul zonei demilitarizate (DMZ) din cauza arhitecturii de traversare a firewall-ului. Dar porturile de semnalizare TCP SIP și porturile media UDP trebuie să fie deschise la intrare pe paravanul de protecție Internet pentru a permite apelurile primite să vină prin intermediul. Trebuie să acordați timp pentru a deschide portul corespunzător pe paravanul de protecție de întreprindere.

Arhitectura de traversare firewall este prezentată în următoarea diagramă:

De exemplu, pentru apelurile business-to-business (B2B) de intrare utilizând protocolul SIP, porturile TCP 5060 și 5061 (5061 este utilizat pentru SIP TLS) trebuie să fie deschise pe paravanul de protecție extern, împreună cu porturile media UDP utilizate pentru servicii precum voce, video, partajare de conținut, video dual și așa mai departe. Ce porturi media să se deschidă depinde de numărul de apeluri concurente și de numărul de servicii.

Aveți posibilitatea să configurați portul de ascultare SIP pe Expressway pentru a fi orice valoare între 1024 și 65534. În același timp, această valoare și tipul de protocol trebuie să fie promovate în înregistrările PUBLICE DNS SRV și aceeași valoare trebuie să fie deschis pe paravanul de protecție Internet.

Deși standardul pentru SIP TCP este 5060 și pentru SIP TLS 5061, nimic nu împiedică utilizarea unor porturi diferite, după cum arată următorul exemplu.

Exemplu

În acest exemplu, presupunem că portul 5062 este utilizat pentru apeluri SIP TLS de intrare.

Înregistrarea DNS SRV pentru un grup de două servere Expressway arată astfel:

_sips._tcp.example.com Locație serviciu SRV:

prioritate = 10

greutate = 10

port = 5062

nume gazdă svr = us-expe1.example.com

_sips._tcp.example.com Locație serviciu SRV:

prioritate = 10

greutate = 10

port = 5062

nume gazdă svr = us-expe2.example.com

Aceste înregistrări înseamnă că apelurile sunt direcționate către us-expe1.example.com și us-expe2.example.com cu partajare egală a sarcinii (prioritate și greutate) utilizând TLS ca tip de transport și 5062 ca număr de port de ascultare.

Un dispozitiv care este extern rețelei (pe Internet) și care efectuează un apel SIP către un utilizator al domeniului corporativ (user1@example.com) trebuie să interogheze DNS-ul pentru a înțelege ce tip de transport să utilizați, numărul portului, cum să partajați traficul și serverele SIP la care să trimiteți apelul.

Dacă intrarea DNS include _sips. , intrarea specifică_tcpSIP TLS.

TLS este un protocol client-server și, în cele mai frecvente implementări, utilizează certificate pentru autentificare. Într-un scenariu de apel business-to-business, clientul TLS este dispozitivul de apelare, iar serverul TLS este dispozitivul numit. Cu TLS, clientul verifică certificatul serverului și, dacă verificarea certificatului nu reușește, se deconectează apelul. Clientul nu are nevoie de un certificat.

Strângerea de mână TLS este prezentată în următoarea diagramă:

Cu toate acestea, specificația TLS afirmă că serverul poate verifica, de asemenea, certificatul client prin trimiterea unui mesaj de solicitare certificat la client în timpul protocolului de strângere de mână TLS. Acest mesaj este util pe o conexiune server-la-server, cum ar fi în timpul apelului care este stabilit între Expressway-E și cloudul Webex. Acest concept se numește TLS cu autentificare reciprocă și este necesar atunci când se integrează cu Webex.

Atât părțile apelante, cât și cele chemate verifică certificatul celuilalt coleg, după cum arată următoarea diagramă:

Cloud-ul verifică identitatea Expressway, iar Expressway verifică identitatea cloud. De exemplu, dacă identitatea în cloud din certificat (CN sau SAN) nu se potrivește cu ceea ce este configurat pe Expressway, conexiunea este abandonată.

Dacă autentificarea reciprocă este activată, Expressway-E solicită întotdeauna certificatul de client. Ca urmare, Mobile și Remote Access (MRA) nu va funcționa, deoarece în majoritatea cazurilor certificatele nu sunt implementate pe clienții Jabber. Într-un scenariu business-to-business, dacă entitatea apelante nu este în măsură să furnizeze un certificat, apelul este deconectat.

Vă recomandăm să utilizați o valoare diferită de 5061 pentru TLS cu autentificare reciprocă, cum ar fi portul 5062. Serviciile hibride Webex utilizează aceeași înregistrare SIP TLS utilizată pentru B2B. În cazul portului 5061, alte servicii care nu pot furniza un certificat de client TLS nu vor funcționa.

Dacă o înregistrare existentă este deja utilizată pentru comunicări între întreprinderi, vă recomandăm să specificați un subdomeniu al domeniului corporativ ca destinație SIP în Control Hub și, în consecință, o înregistrare DNS SRV publică, după cum urmează:

 Serviciu și protocol: _sips._tcp.mtls.example.com Prioritate: 1 Greutate: 10 Număr port: 5062 Țintă: us-expe1.exemplu.com 

Business-to-business, acces mobil și de la distanță și traficul Webex pe aceeași pereche Expressway

Apelurile business-to-business (B2B) și mobile and remote access (MRA) utilizează portul 5061 pentru SIP TLS, iar traficul Webex utilizează portul 5062 pentru SIP TLS cu autentificare reciprocă.

Verificarea proprietății asupra domeniului face parte din verificarea identității. Verificarea domeniului este o măsură de securitate și verificarea identității pe care cloud-ul Webex le implementează pentru a dovedi că sunteți cine spuneți că sunteți.

Verificarea identității se efectuează în două etape:

1. Verificarea proprietății asupra domeniului. Acest pas implică trei tipuri de domenii și este o verificare o singură dată:

   • Domeniu de e-mail

   • Domeniul DNS Expressway-E

   • Domeniu URI director

2. Verificarea proprietății numelui DNS Expressway-E. Acest pas se realizează prin implementarea TLS cu autentificare reciprocă și implică utilizarea certificatelor publice atât în cloud, cât și în Expressway. Spre deosebire de verificarea identității domeniului, acest pas este efectuat în timpul oricărui apel efectuat și primit din cloud.

Importanța verificării proprietății domeniului

Cloudul Webex efectuează verificarea proprietății domeniului pentru a impune securitatea. Furtul de identitate este o amenințare posibilă dacă această verificare nu este efectuată.

Următoarea poveste detaliază ce s-ar putea întâmpla dacă nu se efectuează o verificare a proprietății asupra domeniului.

O companie cu un domeniu DNS setat la „hacker.com” cumpără servicii hibride Webex. O altă companie, cu propriul domeniu setat la "example.com", utilizează, de asemenea, servicii hibride. Unul dintre directorii generali ai companiei Example.com se numește Jane Roe și are directorul URI jane.roe@example.com.

Administratorul companiei Hacker.com setează unul dintre URL-urile directorului său pentru a jane.roe@example.com și adresa de e-mail pentru a jane.roe@hacker.com. Ea poate face acest lucru deoarece cloud-ul nu verifică domeniul SIP URI din acest exemplu.

Apoi, se conectează la aplicația Webex cu jane.roe@hacker.com. Deoarece deține domeniul, e-mailul de verificare este citit și răspuns și se poate conecta. În cele din urmă, apelează un coleg, John Doe, apelând john.doe@example.com din Aplicația ei Webex. John stă în biroul său și vede un apel pe dispozitivul său video venind de la jane.roe@example.com; acesta este URI-ul de director asociat contului de e-mail respectiv.

"E în străinătate", crede el. "S-ar putea să aibă nevoie de ceva important." El răspunde la telefon, iar falsa Jane Roe cere documente importante. Ea explică faptul că dispozitivul ei este rupt și, pentru că călătorește, îi cere să trimită documentele la adresa ei privată de e-mail, jane.roe@hacker.com. În acest fel, compania își dă seama abia după ce Jane Roe se întoarce la birou că s-au scurs informații importante în afara companiei.

Example.com are multe modalități de a vă proteja împotriva apelurilor frauduloase care vin de pe internet, dar una dintre responsabilitățile cloudului Webex este de a vă asigura că identitatea oricărei persoane care apelează din Webex este corectă și nu falsificată.

Pentru a verifica identitatea, Webex solicită companiei să demonstreze că deține domeniile utilizate în Hybrid Calling. Dacă nu, Serviciile hibride nu vor funcționa.

Pentru a asigura această proprietate, sunt necesari cei doi pași de verificare a domeniului:

1. Dovediți că compania deține domeniul de e-mail, domeniul Expressway-E, domeniul Directory URI.

   • Toate aceste domenii trebuie să fie rutabile și cunoscute de serverele DNS publice.

   • Pentru a dovedi dreptul de proprietate, administratorul DNS trebuie să introducă o înregistrare DNS Text (TXT). O înregistrare TXT este un tip de înregistrare de resurse în DNS utilizat pentru a oferi capacitatea de a asocia un text arbitrar și neformatat cu o gazdă sau alt nume.

   • Administratorul DNS trebuie să introducă acea înregistrare TXT în zona a cărei proprietate trebuie dovedită. După acest pas, cloudul Webex efectuează o interogare de înregistrare TXT pentru domeniul respectiv.

   • Dacă interogarea TXT este reușită și rezultatul se potrivește cu tokenul generat din cloudul Webex, domeniul este verificat.

   • De exemplu, administratorul trebuie să demonstreze că deține domeniul „example.com”, dacă dorește ca Serviciile hibride Webex să funcționeze pe domeniul său.

   • Prin https://admin.webex.com, ea începe procesul de verificare prin crearea unei înregistrări TXT care să corespundă tokenului generat de cloudul Webex:

     

   • Administratorul DNS creează apoi o înregistrare TXT pentru acest domeniu cu valoarea setată la 123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef, ca în următorul exemplu:

     

   • În acest moment, cloud-ul poate verifica dacă înregistrarea TXT pentru example.com de domeniu se potrivește cu simbolul.

   • Cloud-ul efectuează o căutare DNS TXT:

     

   • Deoarece valoarea TXT se potrivește cu valoarea simbolului, această potrivire dovedește că administratorul a adăugat înregistrarea TXT pentru propriul domeniu la DNS-ul public și că deține domeniul.

2. Verificarea proprietății numelui DNS Expressway-E.

   • Cloud-ul trebuie să verifice dacă Expressway-E are o identitate confirmată de la una dintre autoritățile de certificare în care cloud-ul are încredere. Administratorul Expressway-E trebuie să solicite un certificat public pentru Autostrada-E către una dintre aceste autorități de certificare. Pentru a emite certificatul, autoritatea de certificare efectuează un proces de verificare a identității, pe baza unei verificări de validare a domeniului (pentru certificate validate de domeniu) sau a unei verificări de validare a organizației (pentru certificatele validate de organizație).

   • Apelurile către și din cloud depind de certificatul care a fost emis către Expressway-E. Dacă certificatul nu este valid, apelul este abandonat.

Webex Device Connector trebuie să comunice cu Webex pentru ca Hybrid Calling să funcționeze.

Webex Device Connector este implementat în rețeaua internă, iar modul în care comunică cu cloudul este printr-o conexiune HTTPS de ieșire - același tip utilizat pentru orice browser care se conectează la un server web.

Comunicarea cu cloudul Webex utilizează TLS. Webex Device Connector este clientul TLS, iar cloudul Webex este serverul TLS. Prin urmare, Webex Device Connector verifică certificatul serverului.

Autoritatea de certificare semnează un certificat de server utilizând propria cheie privată. Oricine are cheia publică poate decoda semnătura respectivă și poate dovedi că aceeași autoritate de certificare a semnat acel certificat.

Dacă Webex Device Connector trebuie să valideze certificatul furnizat de cloud, trebuie să utilizeze cheia publică a autorității de certificare care a semnat certificatul pentru a decodifica semnătura. O cheie publică este conținută în certificatul autorității de certificare. Pentru a stabili încrederea cu autoritățile de certificare utilizate de cloud, lista de certificate a acestor autorități de certificare de încredere trebuie să se afle în magazinul de încredere Webex Device Connector.

Atunci când comunicați cu dispozitive, instrumentul utilizează certificate de încredere pe care le furnizați. În prezent, modul de a face acest lucru este prin plasarea lor în [folder acasă]/.devicestool/certs.

O listă a certificatelor autorității de certificare este, de asemenea, necesară pentru Expressway-E în perechea de traversare. Expressway-E comunică cu cloudul Webex utilizând SIP cu TLS, impus prin autentificarea reciprocă. Expressway-E creditează cu încredere apelurile care vin din și merg către cloud, numai dacă CN sau SAN al certificatului prezentat de cloud în timpul configurării conexiunii TLS se potrivește cu numele de subiect configurat pentru zona DNS pe Expressway („callservice.webex.com”). Autoritatea de certificare eliberează un certificat numai după o verificare a identității. Pentru a obține un certificat semnat, trebuie dovedită proprietatea domeniului callservice.webex.com. Deoarece noi (Cisco) deținem acel domeniu, numele DNS „callservice.webex.com” este o dovadă directă a faptului că partenerul de la distanță este cu adevărat Webex.

Calendar connector integrează Webex cu Microsoft Exchange 2013, 2016, 2019 sau Office 365 printr-un cont de uzurpare a identității. Rolul de gestionare a uzurparei identității aplicației în Exchange permite aplicațiilor să uzurpare identitatea utilizatorilor unei organizații pentru a efectua sarcini în numele utilizatorului. Rolul de uzurpare a identității aplicației trebuie configurat în Exchange și este utilizat în conectorul calendarului ca parte a configurației Exchange pe interfața Expressway-C.

Contul de asumare a identității Exchange este metoda recomandată de Microsoft pentru această sarcină. Administratorii Expressway-C nu trebuie să cunoască parola, deoarece valoarea poate fi introdusă în interfața Expressway-C de către un administrator Exchange. Parola nu este afișată clar, chiar dacă administratorul Expressway-C are acces root la caseta Expressway-C. Parola este stocată criptată folosind același mecanism de criptare a acreditărilor ca și alte parole de pe Expressway-C.

Pentru securitate suplimentară, urmați pașii din Ghidul de implementare pentru Cisco Webex Hybrid Calendar Service pentru a activa TLS pentru a securiza conexiunile EWS pe fir.

Pentru securitate suplimentară, urmați pașii din Implementarea Expressway Calendar Connector pentru Microsoft Exchange pentru a activa TLS pentru a securiza conexiunile EWS pe fir.