Questa sezione fornisce un contesto aggiuntivo sugli elementi di configurazione chiave relativi ai servizi ibridi.

Questi punti sono fondamentali se desidera implementare con successo la chiamata ibrida per i dispositivi Webex. Abbiamo evidenziato questi elementi in particolare per i seguenti motivi:

• Vogliamo spiegarli, in modo che Lei comprenda il loro ruolo in una distribuzione ibrida e si senta rassicurato.

• Sono prerequisiti obbligatori che garantiscono un'implementazione sicura tra il nostro cloud e il suo ambiente locale.

• Dovrebbero essere trattate come attività precedenti al giorno zero: il completamento può richiedere un po' più di tempo rispetto alla configurazione tipica in un'interfaccia utente, quindi conceda un lasso di tempo per ordinare questi elementi.

• Dopo che questi elementi saranno stati risolti nel suo ambiente, il resto della sua configurazione dei servizi ibridi procederà senza intoppi.

L'implementazione delle coppie Expressway-C ed Expressway-E consente le chiamate da e verso Internet utilizzando tecnologie di attraversamento del firewall. Questa distribuzione è ciò che prende in modo sicuro il controllo delle chiamate in sede e lo collega a Webex.

L'Expressway-C e l'Expressway-E non richiedono l'apertura di alcuna porta in entrata nel firewall della zona demilitarizzata (DMZ) a causa dell'architettura di attraversamento del firewall. Ma le porte di segnalazione TCP SIP e le porte multimediali UDP devono essere aperte in entrata sul firewall Internet per consentire il passaggio delle chiamate in entrata. Deve attendere il tempo necessario per aprire la porta appropriata sul suo firewall aziendale.

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

Ad esempio, per le chiamate business-to-business (B2B) in entrata 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 servizi come voce, video, condivisione di contenuti, doppio video e così via. Le porte multimediali da aprire dipendono dal numero di chiamate simultanee e dal numero di servizi.

Può configurare la porta di ascolto SIP su Expressway in modo che abbia un valore compreso tra 1024 e 65534. Allo stesso tempo, questo valore e il tipo di protocollo devono essere pubblicizzati nei DNS SRV registri pubblici e lo stesso valore deve essere aperto sul firewall Internet.

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

Esempio

In questo esempio, supponiamo che la porta 5062 sia utilizzata per le chiamate SIP TLS in entrata.

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

_sorsi. _tcp.example.com Ubicazione del servizio SRV:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sorsi. _tcp.example.com Ubicazione del servizio SRV:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

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

Un dispositivo esterno alla rete (su Internet) che effettua una chiamata SIP a un utente del dominio aziendale (user1@example.com) deve interrogare il 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 tra aziende, 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 fallisce, disconnette la chiamata. Il cliente non ha bisogno di un certificato.

L'handshake TLS è mostrato nel diagramma seguente:

Tuttavia, la specifica TLS afferma che il server può controllare il certificato del client anche inviando un messaggio di richiesta di certificato al client durante il protocollo 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 si chiama TLS con autenticazione reciproca ed è necessario per l'integrazione con Webex.

Sia la parte chiamante che quella chiamata controllano il certificato dell'altro peer, come mostra il diagramma seguente:

Il cloud controlla l'identità di Expressway e Expressway controlla l'identità del cloud. Ad esempio, se l' identità cloud nel certificato (CN o SAN) non corrisponde a quella configurata su Expressway, la connessione viene interrotta.

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

Le consigliamo di utilizzare un valore diverso da 5061 per TLS con autenticazione reciproca, come la porta 5062. I Webex Hybrid Services utilizzano lo stesso record SIP TLS utilizzato per il B2B. Nel caso della porta 5061, alcuni altri servizi che non possono fornire un certificato client TLS non funzioneranno.

Se un record esistente è già utilizzato per le comunicazioni tra aziende, consigliamo di specificare un sottodominio del dominio aziendale come destinazione SIP in Control Hub e, di conseguenza, un record pubblicoDNS SRV, 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 Remote Access e Webex sulla stessa coppia Expressway

Le chiamate Business-to-Business (B2B) e Mobile e Remote Access (MRA) utilizzano la porta 5061 per SIP TLS e 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à che il cloud Webex implementa per dimostrare che Lei è chi dice di essere.

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

1. Controllo della proprietà del dominio. Questo passaggio prevede tre tipi di domini ed è un controllo di verifica una tantum:

   • Dominio di posta elettronica

   • Dominio DNS Expressway-E

   • Dominio URI della directory

2. Controllo della proprietà del nome DNS Expressway-E. Questo passaggio viene eseguito tramite l'implementazione di TLS con autenticazione reciproca e prevede l'uso di certificati pubblici sia sul cloud che sull'autostrada. A differenza del controllo dell'identità del dominio, questo passaggio viene eseguito durante qualsiasi chiamata effettuata e ricevuta dal cloud.

L'importanza del controllo della proprietà del dominio

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

La seguente storia descrive cosa potrebbe succedere se non viene eseguito un controllo della proprietà del dominio.

Un'azienda con dominio DNS impostato su «hacker.com» acquista Webex Hybrid Services. Anche un'altra società, con il proprio dominio impostato su «example.com», utilizza servizi ibridi. Uno dei direttori generali della società Example.com si chiama Jane Roe e ha l'URI della directory jane.roe@example.com.

L'amministratore della società Hacker.com imposta uno degli URI del suo elenco su jane.roe@example.com e l'indirizzo email su jane.roe@hacker.com. Può farlo 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, l'email di verifica viene letta e risponde e può accedere. Infine, chiama un collega, John Doe, componendo 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 rubrica associato a quell'account email.

«È all'estero», pensa. «Potrebbe aver bisogno di qualcosa di importante». Lui risponde al telefono e la falsa Jane Roe chiede documenti importanti. Spiega che il suo dispositivo è rotto e, poiché è in viaggio, gli chiede di inviare i documenti al suo indirizzo email privato, jane.roe@hacker.com. In questo modo, l'azienda si rende conto solo dopo che Jane Roe è tornata in ufficio che informazioni importanti sono trapelate all'esterno dell'azienda.

La società Example.com ha molti modi per proteggersi 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 l'azienda dimostri di possedere i domini utilizzati in Hybrid Calling. In caso contrario, i servizi ibridi non funzioneranno.

Per garantire questa proprietà, sono necessari i due passaggi di verifica del dominio:

1. Dimostri che l'azienda possiede il dominio email, il dominio Expressway-E, il dominio Directory URI.

   • Tutti questi domini devono essere instradabili e conosciuti dai server DNS pubblici.

   • Per dimostrare la proprietà, l'amministratore DNS deve inserire un record di testo DNS (TXT). Un record TXT è un tipo di record di risorse nel DNS utilizzato per fornire la possibilità di associare del testo arbitrario e non formattato a un host o altro nome.

   • L'amministratore DNS deve inserire quel record TXT nella zona la cui proprietà deve essere dimostrata. Dopo questo passaggio, il cloud Webex esegue una query di 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 possedere il dominio «example.com», se desidera che Webex Hybrid Services funzioni sul suo dominio.

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

     

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

     

   • A questo punto, il cloud può verificare che il record TXT per il dominio example.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 del proprio dominio al DNS pubblico e che è proprietaria del dominio.

2. Controllo della proprietà del nome DNS Expressway-E.

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

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

Il Webex Device Connector deve comunicare con Webex affinché la chiamata ibrida funzioni.

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

La comunicazione con il cloud Webex utilizza TLS. Webex Device Connector è il client TLS e il cloud Webex è il server TLS. Pertanto, Webex Device Connector controlla il certificato del server.

L'autorità di certificazione firma un certificato del server utilizzando la propria chiave privata. Chiunque disponga della chiave pubblica può decodificare quella firma e dimostrare che la stessa autorità di certificazione ha firmato quel certificato.

Se Webex Device Connector deve convalidare il certificato fornito dal cloud, deve utilizzare la chiave pubblica dell'autorità di certificazione che ha firmato quel 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 attendibili deve trovarsi nell'archivio di fiducia di Webex Device Connector.

Quando comunica con i dispositivi, lo strumento utilizza i certificati affidabili forniti da Lei. Attualmente il modo per farlo è inserirli [home folder]/.devicestool/certs.

Un elenco di certificati delle autorità di certificazione è richiesto anche per l'Expressway-E nella coppia di attraversamento. Expressway-E comunica con il cloud Webex utilizzando SIP con TLS, applicato mediante autenticazione reciproca. Expressway-E considera attendibili le chiamate provenienti e dirette al cloud, solo se il CN o SAN del certificato presentato dal cloud durante la configurazione 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 un controllo di identità. La proprietà del dominio callservice.webex.com deve essere dimostrata per far firmare un certificato. Poiché noi (Cisco) possediamo quel 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 imitazione. Il ruolo di gestione dell'impersonificazione delle applicazioni in Exchange consente alle applicazioni di impersonare gli utenti di un'organizzazione per eseguire attività per conto dell'utente. Il ruolo di rappresentazione dell'applicazione deve essere configurato in Exchange e viene utilizzato nel connettore del calendario come parte della configurazione di Exchange sull'interfaccia Expressway-C.

L'account di imitazione di Exchange è il metodo consigliato da Microsoft per questa attività. Gli amministratori di Expressway-C non devono conoscere la password, perché il valore può essere inserito nell'interfaccia Expressway-C da un amministratore di Exchange. La password non è mostrata chiaramente, anche se l'amministratore di Expressway-C ha accesso root alla casella Expressway-C. La password viene archiviata crittografata utilizzando lo stesso meccanismo di crittografia delle credenziali delle altre password sull'Expressway-C.

Per una maggiore sicurezza, segua i passaggi della Deployment Guide for Cisco Webex Hybrid Calendar Service per abilitare il TLS al fine di proteggere le connessioni EWS via cavo.

Per una maggiore sicurezza, segua i passaggi indicati in Deploy Expressway Calendar Connector per Microsoft Exchange abilitare il TLS al fine di proteggere le connessioni EWS via cavo.