La distribuzione della combinazione Expressway-C ed Expressway-E consente di effettuare chiamate da e verso Internet utilizzando tecnologie di attraversamento firewall. Questa distribuzione assume in modo sicuro il controllo locale delle chiamate o lo collega a Cisco 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:

posizione servizio SRV _sips._tcp.esempio.com:

priorità = 10

peso = 10

porta = 5062

nome host SVR = us-expe1.esempio.com

posizione servizio SRV _sips._tcp.esempio.com:

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 per una chiamata stabilita tra Expressway-E e il cloud Cisco WebEx. Questo concetto si chiama TLS con autenticazione reciproca ed è richiesto per l'integrazione con Cisco 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. Cisco WebEx Servizi ibridi utilizzano lo stesso record SIP TLS utilizzato per B2B. Nel caso della porta 5061, alcuni servizi che non possono fornire un certificato client TLS non funzioneranno.

B2B, Mobile and Remote Access e traffico Cisco WebEx sulla stessa combinazione Expressway

Chiamate B2B e Mobile and Remote Access utilizzano la porta 5061 per SIP TLS e il traffico Cisco 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à che il cloud Cisco WebEx implementa per dimostrare l'effettiva identità dell'utente.

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.

Una storia per dimostrare l'importanza del controllo dell'identità del dominio

Il cloud Cisco WebEx esegue il controllo della proprietà del dominio per applicare criteri di 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 il dominio DNS impostato su "hacker.com" acquista i Servizi ibridi Cisco 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 a Cisco Webex Teams 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@esempio.com dalla propria app Cisco Webex Teams. John è nel suo ufficio e vede una chiamata sul proprio dispositivo video proveniente da jane.roe@esempio.com; ossia l'URI di directory associato a tale account e-mail.

"È 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 Esempio.com ha diversi modi per proteggersi da chiamate fraudolente provenienti da Internet, ma una delle responsabilità del cloud Cisco WebEx è assicurarsi che l'identità di chiunque chiami da Cisco WebEx sia corretta e non falsificata.

Per verificare l'identità, Cisco WebEx richiede che l'azienda provi che possiede i domini utilizzati in chiamata ibrida. In caso contrario, non funzionerà.

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 Cisco WebEx esegue una query del record TXT per il dominio.

   • Se la query TXT viene eseguita correttamente e il risultato corrisponde al token che è stato generato dal cloud Cisco WebEx, il dominio è verificato.

   • Ad esempio, l'amministratore deve dimostrare che possiede il dominio "esempio.com", se desidera che i Servizi ibridi Cisco WebEx funzionino sul proprio dominio.

   • Attraverso https://admin.webex.com, inizia il processo di verifica mediante la creazione di un record TXT da associare al token che il cloud Cisco WebEx ha generato:

     

   • L'amministratore DNS quindi crea 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.

L'host del connettore Expressway-C deve essere registrato su Cisco WebEx affinché i servizi ibridi funzionino.

Expressway-C viene distribuito nella rete interna e viene registrato sul cloud attraverso una connessione HTTPS in uscita: lo stesso metodo utilizzato per tutti i browser che si connettono a un server Web.

Registrazione e comunicazione al cloud Cisco WebEx utilizzano il protocollo TLS. Expressway-C è il client TLS e il cloud Cisco WebEx è il server TLS. Pertanto, Expressway-C controlla 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 Expressway-C 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 un rapporto di fiducia con le autorità di certificazione utilizzate dal cloud, l'elenco dei certificati di queste autorità di certificazione ritenute attendibili deve essere nell'archivio di attendibilità di Expressway. In questo modo, Expressway può verificare che la chiamata provenga davvero dal cloud Cisco WebEx.

Con il caricamento manuale, è possibile caricare tutti i certificati dell'autorità di certificazione rilevanti nell'archivio di attendibilità di Expressway-C.

Con il caricamento automatico, il cloud carica tali certificati nell'archivio di attendibilità di Expressway-C. Si consiglia di utilizzare il caricamento automatico. L'elenco di certificati può cambiare e il caricamento automatico garantisce di ottenere sempre l'elenco più aggiornato.

Se si consente l'installazione automatica di certificati dell'autorità di certificazione, si viene reindirizzati a https://admin.webex.com (portale di gestione). Il reindirizzamento avviene tramite Expressway-C stesso senza alcun intervento dell'utente. L'utente, come amministratore di Cisco WebEx, deve eseguire l'autenticazione tramite una connessione HTTPS. Subito dopo, il cloud trasferisce i certificati CA su Expressway-C.

Fino a quando i certificati sono caricati nell'archivio di attendibilità Expressway-C, non è possibile stabilire la connessione HTTPS.

Per evitare questo problema, Expressway-C è preinstallato con Cisco WebEx-certificati CA attendibili. Tali certificati vengono utilizzati solo per impostare e convalidare la connessione HTTPS iniziale e non appaiono nell'elenco di entità attendibili di Expressway-C. Una volta che i certificati delle autorità di certificazione attendibili vengono estratti dal cloud attraverso questa connessione HTTPS iniziale, tali certificati sono disponibili per l'uso a livello di piattaforma; quindi, vengono visualizzati nell'elenco di entità attendibili di Expressway-C.

L'elenco mostra i certificati dell'autorità di certificazione che il cloud Cisco WebEx attualmente utilizza. Questo elenco può cambiare in futuro:

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

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

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, 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. - Solo per uso autorizzato, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

Un elenco di certificati dell'autorità di certificazione è richiesto anche per Expressway-E nella combinazione di attraversamento. Expressway-E comunica con il cloud Cisco WebEx tramite SIP con TLS applicato tramite autenticazione reciproca. Expressway-E ritiene attendibili chiamate provenienti e ricevute dal cloud, solo se il CN o SAN del certificato presentato dal cloud durante l'impostazione 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à. La proprietà del dominio callservice.webex.com deve essere dimostrata per ottenere un certificato firmato. Poiché Cisco possiede un proprio dominio, il nome DNS "callservice.webex.com" è prova diretta che il peer remoto è attendibile Cisco WebEx.

Connettore calendario integra Cisco WebEx con Microsoft Exchange 2010, 2013, 2016 oppure 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 in Connettore calendario come parte della configurazione Exchange sull'interfaccia Expressway-C.

L'account di rappresentazione Exchange è il metodo consigliato da Microsoft per questa attività. Gli amministratori di Expressway-C non sono tenuti a 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 di Expressway-C dispone dell'accesso radice alla cassetta Expressway-C. La password viene memorizzata crittografata utilizzando lo stesso meccanismo di crittografia delle credenziali di altre password su 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.