In questa sezione viene fornito un contesto aggiunto sulle voci di configurazione chiave relative ai servizi ibridi.

Questi punti sono fondamentali se si desidera distribuire correttamente la chiamata ibrida per i 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 affrontate queste voci nel proprio ambiente, il resto della configurazione dei servizi ibridi funzionerà correttamente.

La distribuzione della coppia Expressway-C ed Expressway-E consente le chiamate da e verso Internet utilizzando tecnologie trasversali del firewall. Questa distribuzione consente al tuo controllo delle chiamate locali in modo sicuro e lo collega a 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.esempio.com Posizione servizio SRV:

priorità = 10

peso = 10

porta = 5062

nome host SVR = us-expe1.esempio.com

_sips._tcp.esempio.com Posizione 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 su una connessione da server a server, ad esempio durante una chiamata stabilita tra Expressway-E e il cloud Webex. Questo concetto è denominato TLS con autenticazione reciproca ed è richiesto 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 Webex utilizzano lo stesso record TLS SIP utilizzato per B2B. Nel caso della porta 5061, alcuni servizi che non possono fornire un certificato client TLS non funzioneranno.

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

 Servizio e protocollo: _sips._tcp.mtls.example.com Priorità: 1 Peso: 10 Numero porta: Destinazione 5062: us-expe1.esempio.com 

Traffico Business-to-Business, Mobile e Remote Access e Webex sulla stessa coppia Expressway

Le chiamate business-to-business (B2B) e Mobile and Remote Access (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 di identità implementati dal cloud Webex per dimostrare che sei la persona che hai detto 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 di proprietà del dominio

Il cloud Webex esegue il controllo di proprietà del dominio per applicare 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.

Una società con dominio DNS impostato su "hacker.com" acquista i servizi ibridi Webex. 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, effettua una chiamata a un collega, John Doe, chiamando 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; ossia l'URI della rubrica associato all'account e-mail specificato.

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

La società Example.com offre molti modi per proteggere dalle chiamate fraudolente provenienti da Internet, ma una delle responsabilità del cloud Webex è assicurarsi che l'identità di chiunque chiami da Webex sia corretta e non falsificata.

Per verificare l'identità, Webex richiede che la società dimostri di essere proprietaria dei domini utilizzati in Hybrid Calling. 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 tale operazione, il cloud Webex esegue una query di record TXT per tale 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 provare di essere in possesso del dominio "example.com", se desidera che i servizi ibridi Webex funzionino sul proprio dominio.

   • Attraverso https://admin.webex.com, avvia il processo di verifica creando un record TXT che corrisponde 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é la chiamata ibrida funzioni, Webex Device Connector deve comunicare con Webex.

Webex Device Connector viene distribuito nella rete interna e il modo in cui comunica con il cloud è attraverso una connessione HTTPS in uscita, lo stesso tipo utilizzato per qualsiasi browser che si connette a un server Web.

La comunicazione al cloud Webex utilizza il protocollo TLS. Webex Device Connector è il client TLS e il cloud Webex è il server TLS. In questo modo, 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 decodificare la firma. Una chiave pubblica è contenuta nel certificato dell'autorità di certificazione. Per stabilire l'attendibilità con le autorità di certificazione utilizzate dal cloud, l'elenco dei certificati di queste autorità di certificazione attendibili deve essere presente nell'archivio attendibilità del Connettore dispositivo Webex.

Quando si comunica con i dispositivi, lo strumento utilizza i certificati attendibili forniti. Attualmente, è possibile effettuare questa operazione inserendoli in [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, imposto dall'autenticazione reciproca. Expressway-E considera affidabili le chiamate provenienti e destinate al cloud solo se il CN o SAN del certificato presentato dal cloud durante l'impostazione della connessione TLS corrisponde al nome dell'oggetto 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 la proprietà del dominio callservice.webex.com. Poiché (Cisco) è il proprietario di tale dominio, il nome DNS "callservice.webex.com" è la prova diretta che il peer remoto è veramente 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 rappresentazione 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.