Questa sezione fornisce ulteriori informazioni contestuali sugli elementi di configurazione chiave relativi ai servizi ibridi.

Questi punti sono cruciali per implementare con successo le chiamate ibride sui dispositivi Webex. Abbiamo evidenziato questi elementi in particolare per i seguenti motivi:

• Desideriamo spiegarli, in modo che gli utenti ne comprendano il ruolo in una distribuzione ibrida e si sentano più rassicurati.

• Sono prerequisiti obbligatori che garantiscono una distribuzione sicura tra il cloud e l'ambiente on-premise dell'utente.

• Devono essere considerati come attività preliminari: possono richiedere più tempo per il completamento rispetto alla configurazione tipica in un'interfaccia utente, quindi riservare il tempo necessario.

• Una volta risolti questi problemi nel tuo ambiente, il resto della configurazione dei Servizi ibridi procederà senza intoppi.

La configurazione della coppia Expressway-C ed Expressway-E consente chiamate da e verso Internet utilizzando tecnologie di attraversamento del firewall. Questa implementazione consente di integrare in modo sicuro il controllo delle chiamate locale con Webex.

Expressway-C ed Expressway-E non richiedono alcuna porta in entrata da aprire nel firewall DMZ grazie all'architettura di attraversamento firewall. Ma le porte di segnalazione SIP TCP e le porte multimediali UDP devono essere aperte in entrata sul firewall Internet per consentire il passaggio delle chiamate in arrivo. Attendere il tempo necessario affinché la porta appropriata venga aperta sul firewall aziendale.

L'architettura di attraversamento firewall è mostrata nel diagramma seguente:

Ad esempio, per le chiamate in entrata B2B (business-to-business) che utilizzano il protocollo SIP, le porte TCP 5060 e 5061 (5061 viene utilizzata per SIP TLS) devono essere aperte sul firewall esterno, insieme alle porte multimediali UDP utilizzate per i servizi, ad esempio voce, video, condivisione di contenuto, doppio video e così via. Le porte multimediali da aprire dipendono dal numero di chiamate concorrenti e dal numero di servizi.

È possibile configurare la porta di ascolto SIP su Expressway su un valore compreso tra 1024 a 65534. Allo stesso tempo, questo valore e il tipo di protocollo devono essere comunicati nei record DNS SRV pubblici e lo stesso valore deve essere aperto sul firewall Internet.

Sebbene lo standard per SIP TCP sia 5060 e per SIP TLS sia 5061, niente impedisce l'uso di porte diverse, come mostrato nell'esempio seguente.

Esempio

In questo esempio, si presuppone che la porta 5062 venga utilizzata per le chiamate in entrata SIP TLS.

Il record SRV DNS per un cluster di due server Expressway è simile al seguente:

_sips._tcp.example.com Posizione del servizio SRV:

priorità = 10

peso = 10

porta = 5062

nome host SVR = us-expe1.esempio.com

_sips._tcp.example.com Posizione del servizio SRV:

priorità = 10

peso = 10

porta = 5062

nome host SVR = us-expe2.esempio.com

Tali record indicano che le chiamate vengono indirizzate a us-expe1.esempio.com e us-expe2.esempio.com con pari condivisione del carico (priorità e peso) utilizzando il protocollo TLS come tipo di trasporto e 5062 come numero della porta di ascolto.

Un dispositivo esterno alla rete (su Internet) e che effettua una chiamata SIP a un utente del dominio aziendale (utente1@esempio.com) deve eseguire una query DNS per capire quale tipo di trasporto utilizzare, il numero di porta, come condividere il carico del traffico e a quali server SIP inviare la chiamata.

Se la voce DNS include _sips._tcp, la voce specifica SIP TLS.

TLS è un protocollo client-server e, nelle implementazioni più comuni, utilizza certificati per l'autenticazione. In uno scenario di chiamata B2B, il client TLS è il dispositivo chiamante e il server TLS è il dispositivo chiamato. Con TLS, il client controlla il certificato del server, e se il controllo del certificato non riesce, disconnette la chiamata. Il client non necessita di un certificato.

Nel diagramma seguente viene mostrato l'handshake TLS:

Tuttavia, la specifica TLS indica che il server può anche controllare il certificato client inviando un messaggio di richiesta di certificato al client durante il protocollo di handshake TLS. Questo messaggio è utile in una connessione server-to-server, come ad esempio una chiamata stabilita tra Expressway-E e il cloud Webex. Questo concetto è chiamato TLS con autenticazione reciproca ed è necessario per l'integrazione con Webex.

Entrambe le parti, chiamante e chiamato, verificano il certificato dell'altro peer, come mostrato nel diagramma seguente:

Il cloud controlla l'identità Expressway ed Expressway controlla l'identità del cloud. Ad esempio, se l'identità del cloud nel certificato (CN o SAN) non corrisponde a ciò che è configurato su Expressway, la connessione viene interrotta.

Se l'autenticazione reciproca è attivata, Expressway-E richiede sempre il certificato del client. Di conseguenza, Mobile and Remote Access (MRA) non funziona, perché nella maggior parte dei casi i certificati non vengono distribuiti su client Jabber. In uno scenario B2B, se l'entità chiamante non è in grado di fornire un certificato, la chiamata viene disconnessa.

Si consiglia di utilizzare un valore diverso da 5061 per TLS con autenticazione reciproca, ad esempio la porta 5062. I servizi ibridi di Webex utilizzano lo stesso record SIP TLS impiegato per le comunicazioni B2B. Nel caso della porta 5061, alcuni servizi che non possono fornire un certificato client TLS non funzioneranno.

Se per le comunicazioni business-to-business è già in uso un record esistente, si consiglia di specificare un sottodominio del dominio aziendale come destinazione SIP in Control Hub e, di conseguenza, un record SRV DNS pubblico, come segue:

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

Traffico business-to-business, mobile e di accesso remoto e Webex sulla stessa coppia di autostrade.

Le chiamate business-to-business (B2B) e le chiamate mobili e di accesso remoto (MRA) utilizzano la porta 5061 per SIP TLS, mentre il traffico Webex utilizza la porta 5062 per SIP TLS con autenticazione reciproca.

Il controllo della proprietà del dominio fa parte della verifica dell'identità. La verifica del dominio è una misura di sicurezza e un controllo dell'identità implementato dal cloud Webex per dimostrare che sei effettivamente chi dichiari di essere.

Il controllo dell'identità viene eseguito in due fasi:

1. Controllo della proprietà del dominio. Questa operazione prevede tre tipi di dominio ed è un controllo di verifica una-tantum:

   • Dominio e-mail

   • Dominio DNS Expressway-E

   • Dominio URI di directory

2. Controllo della proprietà del nome DNS Expressway-E. Questa operazione viene eseguita tramite l'implementazione di TLS con autenticazione reciproca e prevede l'uso di certificati pubblici su entrambi, cloud ed Expressway. A differenza del controllo dell'identità del dominio, questa operazione viene eseguita durante le chiamate effettuate al cloud e ricevute dal cloud.

L'importanza del controllo della proprietà del dominio

Il servizio cloud di Webex esegue il controllo della proprietà del dominio per garantire la sicurezza. Il furto di identità è una possibile minaccia se non viene eseguito questo controllo.

La seguente storia dimostra ciò che potrebbe accadere se non viene eseguito il controllo della proprietà del dominio.

Un'azienda con dominio DNS impostato su "hacker.com" acquista i servizi Webex Hybrid. Un'altra azienda, con il proprio dominio impostato su "esempio.com", sta utilizzando servizi ibridi. Uno dei direttori generali dell'azienda Esempio.com si chiama Jane Roe e dispone dell'URI di directory jane.roe@esempio.com.

L'amministratore dell'azienda Hacker.com imposta uno dei propri URI di directory su jane.roe@esempio.com e l'indirizzo e-mail su jane.roe@hacker.com. Questa operazione è consentita perché il cloud non controlla il dominio URI SIP in questo esempio.

Successivamente, accede all'app Webex con jane.roe@hacker.com. Poiché è proprietaria del dominio, il messaggio e-mail di verifica viene letto e viene inviata una risposta e Jane può accedere. Infine, fa una chiamata a un collega, John Doe, componendo il numero john.doe@example.com dalla sua app Webex. John è seduto nel suo ufficio e vede una chiamata sul suo dispositivo video proveniente da jane.roe@example.com; Questo è l'URI della directory associato a quell'account di posta elettronica.

"È all'estero", pensa. "Potrebbe aver bisogno di qualcosa di importante." Risponde al telefono e la falsa Jane Roe richiede alcuni documenti importanti. Spiega che il suo dispositivo si è rotto e poiché è in viaggio, gli chiede di inviare i documenti al suo indirizzo e-mail privato, jane.roe@hacker.com. In questo modo, l'azienda realizza solo dopo che Jane Roe torna in ufficio che informazioni importanti sono state divulgate all'esterno dell'azienda.

L'azienda Example.com dispone di numerosi sistemi per proteggersi dalle chiamate fraudolente provenienti da Internet, ma una delle responsabilità del cloud Webex è quella di garantire che l'identità di chiunque chiami tramite Webex sia corretta e non falsificata.

Per verificare l'identità, Webex richiede che l'azienda dimostri di essere proprietaria dei domini utilizzati nelle chiamate ibride. In caso contrario, i Servizi ibridi non funzioneranno.

Per garantire questa proprietà, è necessario eseguire le due operazioni di verifica del dominio:

1. Dimostrare che l'azienda possiede il dominio e-mail, dominio Expressway-E, dominio URI di directory.

   • Tutti questi domini devono essere inoltrabili e noti dai server DNS pubblici.

   • Per provare la proprietà, l'amministratore DNS deve immettere un record DNS di testo (TXT). Un record TXT è un tipo di record risorsa nel DNS utilizzato per consentire di associare testo non formattato e arbitrario a un nome host o un altro nome.

   • L'amministratore DNS deve immettere tale record TXT nella zona in cui la proprietà deve essere dimostrata. Dopo questo passaggio, il cloud di Webex esegue una query sui record TXT per quel dominio.

   • Se la query TXT ha esito positivo e il risultato corrisponde al token generato dal cloud Webex, il dominio viene verificato.

   • Ad esempio, l'amministratore deve dimostrare di essere il proprietario del dominio "example.com" se desidera che i servizi Webex Hybrid funzionino sul suo dominio.

   • Tramite https://admin.webex.com, avvia il processo di verifica creando un record TXT per corrispondere al token generato dal cloud Webex:

     

   • L'amministratore DNS crea quindi un record TXT per questo dominio con il valore impostato su 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, come nell'esempio seguente:

     

   • A questo punto, il cloud può verificare che il record TXT per il dominio esempio.com corrisponda al token.

   • Il cloud esegue una ricerca DNS TXT:

     

   • Poiché il valore TXT corrisponde al valore del token, questa corrispondenza dimostra che l'amministratore ha aggiunto il record TXT per il proprio dominio nel DNS pubblico e che possiede il dominio.

2. Controllo della proprietà del Nome DNS di Expressway-E.

   • Il cloud deve verificare che Expressway-E dispone di un'identità confermata da una delle autorità di certificazione attendibili per il cloud. L'amministratore di Expressway-E deve richiedere un certificato pubblico per il proprio Expressway-E a una di tali autorità di certificazione. Per rilasciare il certificato, l'autorità di certificazione esegue un processo di verifica di identità, basato su un controllo di convalida del dominio (per certificati convalidati da dominio) o un controllo di convalida dell'organizzazione (per certificati convalidati da organizzazione).

   • Le chiamate da e verso il cloud dipendono dal certificato rilasciato a Expressway-E. Se il certificato non è valido, la chiamata viene interrotta.

Affinché le chiamate ibride funzionino, il connettore del dispositivo Webex deve comunicare con Webex.

Webex Device Connector viene distribuito nella rete interna e comunica con il cloud tramite una connessione HTTPS in uscita, lo stesso tipo utilizzato da qualsiasi browser per connettersi a un server web.

La comunicazione con il cloud Webex utilizza TLS. Webex Device Connector funge da client TLS, mentre il cloud Webex funge da server TLS. Pertanto, Webex Device Connector verifica il certificato del server.

L'autorità di certificazione firma un certificato del server utilizzando la propria chiave privata. Chiunque con la chiave pubblica può decodificare tale firma e dimostrare che la stessa autorità di certificazione abbia firmato tale certificato.

Se Webex Device Connector deve convalidare il certificato fornito dal cloud, deve utilizzare la chiave pubblica dell'autorità di certificazione che ha firmato tale certificato per decodificarne la firma. Una chiave pubblica è contenuta nel certificato dell'autorità di certificazione. Per instaurare un rapporto di fiducia con le autorità di certificazione utilizzate dal cloud, l'elenco dei certificati di tali autorità attendibili deve essere presente nell'archivio attendibile di Webex Device Connector.

Durante la comunicazione con i dispositivi, lo strumento utilizza certificati attendibili forniti dall'utente. Attualmente il modo per farlo è inserirli tra parentesi quadre [home folder]/.devicestool/certs.

Un elenco di certificati dell'autorità di certificazione è richiesto anche per Expressway-E nella combinazione di attraversamento. Expressway-E comunica con il cloud Webex utilizzando SIP con TLS, protetto da autenticazione reciproca. Expressway-E considera attendibili le chiamate provenienti dal cloud e dirette verso di esso solo se il CN o il SAN del certificato presentato dal cloud durante la configurazione della connessione TLS corrisponde al nome del soggetto configurato per la zona DNS su Expressway ("callservice.webex.com"). L'autorità di certificazione rilascia un certificato solo dopo il controllo dell'identità. Per ottenere un certificato firmato, è necessario dimostrare di essere proprietari del dominio callservice.webex.com. Poiché noi (Cisco) possediamo quel dominio, il nome DNS "callservice.webex.com" è la prova diretta che il peer remoto è effettivamente Webex.

Il connettore calendario integra Webex con Microsoft Exchange 2013, 2016, 2019 o Office 365 tramite un account di rappresentazione. Il ruolo di gestione delle rappresentazioni delle applicazioni in Exchange consente alle applicazioni di rappresentare gli utenti in un'organizzazione per eseguire attività per conto dell'utente. Il ruolo di rappresentazione dell'applicazione deve essere configurato in Exchange e utilizzato nel connettore di calendario come parte della configurazione Exchange sull Expressway-C.

L'account di impersonificazione di Exchange è il metodo consigliato da Microsoft per questa attività. Expressway-C non è necessario conoscere la password poiché il valore può essere immesso nell'interfaccia Expressway-C da un amministratore Exchange. La password non viene visualizzata chiaramente, anche se l'amministratore Expressway-C dispone dell'accesso radice alla finestra Expressway-C. La password viene memorizzata crittografata utilizzando lo stesso meccanismo di crittografia delle credenziali di altre password sul Expressway-C.

Per ulteriore sicurezza, attenersi alla procedura nella Guida alla distribuzione per il servizio di calendario ibrido Cisco Webex per abilitare il protocollo TLS al fine di proteggere le connessioni EWS sulla rete.

Per ulteriore sicurezza, attenersi alla procedura in Distribuzione del connettore di calendario di Expressway per Microsoft Exchange per abilitare il protocollo TLS al fine di proteggere le connessioni EWS sulla rete.