Implementarea perechii Expressway-C și Expressway-E permite apeluri către și de la Internet folosind tehnologii de traversare firewall. Această implementare este ceea ce vă ia în siguranță controlul apelurilor locale și îl leagă de Cisco 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ției serviciului SRV:

prioritate = 10

greutate = 10

port = 5062

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

_sips._tcp. example.com locației serviciului 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 pentru o conexiune server-server, cum ar fi la apel, care este stabilit între Expressway-E și cloud Cisco Webex. Acest concept se numește TLS cu autentificare reciprocă și este necesar atunci când se integrează cu Cisco 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. Cisco Webex Hybrid Services utilizează aceeași înregistrare TLS SIP utilizată pentru B2B. În cazul portului 5061, alte servicii care nu pot furniza un certificat de client TLS nu vor funcționa.

Traficul Business-to-business, Mobile și Remote Access și Cisco Webex pe aceeași pereche Expressway

Apelurile Business-to-Business și Mobile și Remote Access utilizează portul 5061 pentru SIP TLS, iar traficul Cisco 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 o verificare a identității pe care cloud-ul Cisco Webex o 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.

O poveste pentru a arăta importanța verificării proprietății asupra domeniului

Cloud-ul Cisco Webex efectuează verificarea proprietății asupra 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 domeniu DNS setat la "hacker.com" cumpără Cisco Webex Hybrid Services. 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 Cisco Webex Teams 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ă, ea face un apel către un coleg, John Doe, apelând john.doe@example.com din aplicația Cisco Webex Teams. John stă în biroul său și vede un apel pe dispozitivul său video provenind de la jane.roe@example.com; adică uri-ul directorului asociat cu acel cont de e-mail.

"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.

Compania Example.com are multe modalități de a proteja împotriva apelurilor frauduloase care vin de pe Internet, dar una dintre responsabilitățile cloud-ului Cisco Webex este să se asigure că identitatea oricărei persoane care apelează de la Cisco Webex este corectă și nu falsificată.

Pentru a verifica identitatea, Cisco Webex necesită ca compania să dovedească faptul că deține domeniile utilizate în apelarea hibridă. Dacă nu, nu va 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, cloud-ul Cisco Webex efectuează o interogare de înregistrare TXT pentru acel domeniu.

   • Dacă interogarea TXT are succes și rezultatul se potrivește cu simbolul generat din cloud-ul Cisco Webex, domeniul este verificat.

   • De exemplu, administratorul trebuie să dovedească faptul că deține domeniul "example.com", dacă dorește ca Cisco Webex Hybrid Services să lucreze la domeniul său.

   • Prin https://admin.webex.com, ea începe procesul de verificare prin crearea unei înregistrări TXT pentru a se potrivi cu simbolul generat de cloud-ul Cisco Webex:

     

   • Administratorul DNS creează apoi o înregistrare TXT pentru acest domeniu cu valoarea setată la 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, ca în exemplul următor:

     

   • Î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.

Gazda conectorului Expressway-C trebuie să fie înregistrată la Cisco Webex pentru ca serviciile hibride să funcționeze.

Expressway-C este implementat în rețeaua internă, iar modul în care se înregistrează în cloud este printr-o conexiune HTTPS de ieșire - același tip care este utilizat pentru orice browser care se conectează la un server web.

Înregistrarea și comunicarea în cloud-ul Cisco Webex utilizează TLS. Expressway-C este clientul TLS, iar cloud-ul Cisco Webex este serverul TLS. Ca atare, Expressway-C verifică certificatul de server.

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ă Expressway-C trebuie să valideze certificatul furnizat de cloud, acesta trebuie să utilizeze cheia publică a autorității de certificare care a semnat certificatul respectiv pentru a decoda 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 certificatelor acestor autorități de certificare de încredere trebuie să se află în magazinul de încredere Expressway. Procedând astfel, Expressway poate verifica dacă apelul provine cu adevărat din cloud-ul Cisco Webex.

Cu încărcarea manuală, puteți încărca toate certificatele relevante ale autorității de certificare în magazinul de încredere expressway-C.

Cu încărcarea automată, cloud-ul în sine încarcă aceste certificate în magazinul de încredere al Expressway-C. Îți recomandăm să folosești încărcarea automată. Lista de certificate se poate modifica, iar încărcarea automată garantează că obțineți cea mai actualizată listă.

Dacă permiteți instalarea automată a certificatelor de autoritate de certificare, sunteți redirecționat către https://admin.webex.com (portalul de gestionare). Redirecționarea se face chiar de către Expressway-C, fără intervenția utilizatorului. Dumneavoastră, în calitate de administrator Cisco Webex, trebuie să vă autentificați printr-o conexiune HTTPS. La scurt timp după aceea, norul împinge certificatele CA la Expressway-C.

Până când certificatele sunt încărcate în magazinul de încredere Expressway-C, conexiunea HTTPS nu poate fi stabilită.

Pentru a evita această problemă, Expressway-C este preinstalat cu certificate CA de încredere Cisco Webex. Aceste certificate sunt utilizate numai pentru a configura și valida conexiunea HTTPS inițială și nu apar în lista de încredere Expressway-C. Odată ce certificatele autorităților de certificare de încredere sunt extrase din cloud prin această conexiune HTTPS inițială, certificatele respective sunt disponibile pentru utilizare la nivel de platformă; apoi, ele apar în lista de încredere Expressway-C.

Această listă afișează certificatele de autoritate de certificare pe care cloud-ul Cisco Webex le utilizează în prezent. Această listă s-ar putea schimba în viitor:

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

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

• C = SUA, O = Go Daddy Group, Inc, OU = Du-te Tati clasa 2 Certificat Autoritatea

• C = SUA, 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. - Numai pentru utilizare autorizată, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Autoritatea publică de certificare primară clasa 3

O listă a certificatelor autorității de certificare este, de asemenea, necesară pentru Expressway-E în perechea de traversare. Expressway-E comunică cu cloud-ul Cisco Webex utilizând SIP cu TLS, impus prin autentificare reciprocă. Expressway-E are încredere în apelurile care vin de la și merg în cloud, numai dacă CN sau SAN-ul certificatului prezentat de cloud în timpul configurării conexiunii TLS se potrivește cu numele subiectului configurat pentru zona DNS de pe Expressway ("callservice.ciscospark.com"). Autoritatea de certificare eliberează un certificat numai după o verificare a identității. Dreptul de proprietate asupra domeniului callservice.ciscospark.com trebuie dovedit pentru a obține un certificat semnat. Deoarece noi (Cisco) deținem acel domeniu, numele DNS "callservice.ciscospark.com " este dovada directă căpeer-ul de la distanță este cu adevărat Cisco Webex.

Calendar Connector integrează Cisco Webex cu Microsoft Exchange 2010, 2013, 2016 sau Office 365 printr-un cont de asumare. Rolul de gestionare a uzurpării identității aplicației în Exchange permite aplicațiilor să uzurpe identitatea utilizatorilor dintr-o organizație pentru a efectua activități în numele utilizatorului. Rolul de asumare a aplicației trebuie configurat în Exchange și este utilizat în Conector calendar ca parte a configurației Exchange pe interfața Expressway-C.

Contul de asumare Exchange este metoda recomandată de Microsoft pentru această activitate. 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ă utilizând 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.