Met implementatie via een combinatie van Expressway-C en Expressway-E kunt u gesprekken naar en van internet via Firewall-traversaltechnologieën voeren. Deze implementatie neemt uw lokale gespreksbeheer en sluit dit aan op Cisco Webex.

De Expressway-C en Expressway-E vereisen niet dat een inkomende poort wordt geopend in de firewall met gedemilitariseerde zone (DMZ), vanwege de firewall-traversalarchitectuur. TCP SIP-signaleringspoorten en UDP-mediapoorten moeten echter inkomend worden geopend op de internetfirewall om inkomende gesprekken door te laten. Het kan even duren voor de juiste poort wordt geopend op de firewall van uw organisatie.

De firewall-traversalarchitectuur wordt weergegeven in het volgende diagram:

Voor inkomende business-to-businessgesprekken (B2B) met SIP-protocol moeten bijvoorbeeld de TCP-poorten 5060 en 5061 (5061 wordt gebruikt voor SIP-TLS) worden geopend op de externe firewall, samen met de UDP-mediapoorten die worden gebruikt voor services zoals spraak, video, inhoud delen, dubbele video, enzovoort. Welke mediapoorten open zijn, is afhankelijk van het aantal gelijktijdige gesprekken en het aantal services.

U kunt de SIP-luisterpoort op Expressway configureren voor elke waarde tussen 1024 en 65534. Tegelijkertijd moeten deze waarde en het protocoltype worden geadverteerd in de publieke DNS-SRV-records en dezelfde waarde moet openbaar worden gemaakt op de internetfirewall.

Hoewel de standaard voor SIP TCP 5060 is en 5061 voor SIP-TLS, is er niets wat het gebruik van meerdere poorten verhindert, zoals het volgende voorbeeld aantoont.

Voorbeeld

In dit voorbeeld we gaan we ervan uit dat poort 5062 wordt gebruikt voor binnenkomende TLS SIP-gesprekken.

Het DNS SRV-record voor een cluster van twee Expressway-servers ziet er als volgt uit:

SRV-servicelocatie _sips._tcp.voorbeeld.com:

prioriteit = 10

gewicht = 10

poort = 5062

serverhostnaam = us-expe1.voorbeeld.com

SRV-servicelocatie _sips._tcp.voorbeeld.com:

prioriteit = 10

gewicht = 10

poort = 5062

serverhostnaam = us-expe2.voorbeeld.com

Deze records houden in dat gesprekken worden omgeleid naar us-expe1.voorbeeld.com en us-expe2.voorbeeld.com met gelijke load delen (prioriteit en gewicht), waarbij TLS als het transporttype wordt gebruikt en 5062 als het luisterpoortnummer.

Een apparaat dat extern is voor het netwerk (op het internet) en een SIP-gesprek naar een gebruiker van het bedrijfsdomein (gebruiker1@voorbeeld.com) maakt, moet de DNS aanvragen om te bepalen welk transporttype en poortnummer moeten worden gebruikt, hoe de verkeerslast kan worden verdeeld en naar welke SIP-servers het gesprek moet worden verzonden.

Als de DNS-vermelding _sips._tcp bevat, geeft het item SIP-TLS op.

TLS is een protocol voor de clientserver en gebruikt in de meest voorkomende implementaties certificaten voor verificatie. In een scenario met een business-to-businessgesprek is de TLS-client het belapparaat en de TLS-server is het gebelde toestel. De client controleert het certificaat van de server met TLS. Als deze controle mislukt, wordt de verbinding van het gesprek verbroken. De client heeft geen certificaat nodig.

De TLS-handshake wordt in het volgende diagram weergegeven:

De TLS-specificatie geeft echter aan dat de server het clientcertificaat ook kan controleren door een certificaataanvraag naar de client te verzenden tijdens het TLS-handshakeprotocol. Dit bericht is nuttig voor een server-naar-serververbinding, zoals een gesprek dat tussen Expressway-E en de Cisco Webex-cloud tot stand is gekomen. Dit concept heet TLS met gemeenschappelijke verificatie en is vereist bij de integratie met Cisco Webex.

Zowel de belpartijen als de gebelde partijen controleren het certificaat van de ander, zoals het volgende diagram aangeeft:

De cloud controleert de identiteit van de Expressway en Expressway controleert de identiteit van de cloud. Als de identiteit van de cloud in het certificaat (CN of SAN) niet overeenkomt met wat is ingesteld op Expressway, wordt de verbinding verbroken.

Als gemeenschappelijke verificatie is ingeschakeld, vraagt Expressway-E altijd om het clientcertificaat. Hierdoor werkt Mobile and Remote Access (MRA) niet, omdat certificaten in de meeste gevallen niet worden geïmplementeerd op Jabber-clients. In een business-to-business-scenario wordt de verbinding van het gesprek verbroken als de belpartij geen certificaat kan verschaffen.

We raden u aan een andere waarde dan 5061 te gebruiken voor TLS met gemeenschappelijke verificatie, zoals poort 5062. Cisco Webex Hybride services maken gebruik van dezelfde SIP-TLS-records als voor B2B. In het geval van poort 5061 werken sommige andere services die geen TLS-clientcertificaat kunnen geven niet.

Business-to-business, Mobile and Remote Access en Cisco Webex-verkeer op hetzelfde Expressway-paar

Business-to-business- en Mobile and Remote Access-gesprekken gebruiken poort 5061 voor SIP-TLS en Cisco Webex-verkeer maakt gebruik van poort 5062 voor TLS SIP met gemeenschappelijke verificatie.

De controle van het domeineigendom is onderdeel van de identiteitsverificatie. Domeinverificatie is een veiligheidsmaatregel en identiteitscontrole die de Cisco Webex-cloud implementeert om te bewijzen dat u bent wie u zegt te zijn.

De identiteitscontrole wordt in twee fasen uitgevoerd:

1. Controle van domeineigendom Deze stap omvat twee typen domeinen en is een eenmalige verificatiecontrole:

   • E-maildomein

   • Expressway-E-DNS-domein

   • Directory-URI-domein

2. Eigendomscontrole van Expressway-E-DNS-naam. Deze stap wordt uitgevoerd via de implementatie van TLS met gemeenschappelijke verificatie en het gebruik van openbare certificaten in zowel de cloud als de Expressway. In tegenstelling tot de controle van het domein-id, wordt deze stap uitgevoerd tijdens elk gesprek naar en vanuit de cloud.

Een verhaal over het belang van de controle van het domeineigendom

De Cisco Webex-cloud voert deze controle van het domeineigendom uit om de veiligheid te garanderen. Als deze controle niet wordt uitgevoerd, kan dit leiden tot identiteitsdiefstal.

Het volgende verhaal laat zien wat er kan gebeuren als het domeineigendom niet wordt gecontroleerd.

Een bedrijf met het DNS-domein 'hacker.com' koopt hybride Cisco Webex-services. Een ander bedrijf, met zijn domein ingesteld op 'voorbeeld.com', gebruikt ook hybride services. Een van de algemene managers van het bedrijf Voorbeeld.com, Miep de Jong, heeft de directory-URI miep.de.jong@voorbeeld.com.

De beheerder van het bedrijf Hacker.com stelt een van haar directory-URI's in als miep.de.jong@voorbeeld.com en het e-mailadres als miep.de.jong@hacker.com. Zij kan dit doen omdat de cloud in dit voorbeeld het SIP URI-domein niet controleert.

Vervolgens meldt zij zich aan bij Cisco Webex Teams met miep.de.jong@hacker.com. Omdat ze is eigenaar van het domein, kan ze de bevestigings-e-mail lezen en beantwoorden, en kan zij zich aanmelden. Tot slot belt ze naar een collega, Jan Jansen, door te bellen naar jan.jansen@voorbeeld.com via haar Cisco Webex Teams-app. Jan zit in zijn kantoor en ziet een gesprek op zijn videoapparaat van miep.de.jong@voorbeeld.com, aangezien dit de directory-URI is die is gekoppeld aan dit e-mailaccount.

'Ze is in het buitenland,' denkt hij. 'Ze heeft mogelijk iets belangrijks nodig.' Hij neemt op en de valse Miep de Jong vraagt om belangrijke documenten. Ze legt uit dat haar apparaat kapot is en aangezien ze aan het reizen is, vraagt ze of hij haar de documenten kan sturen naar haar privé-e-mailadres, miep.de.jong@hacker.com. Op deze manier realiseert het bedrijf zich pas wanneer Miep de Jong terug op kantoor is dat belangrijke informatie naar buiten het bedrijf is gelekt.

Het bedrijf Voorbeeld.com kan zich op veel manieren tegen frauduleuze gesprekken beschermen met behulp van internet, maar een van de verantwoordelijkheden van de Cisco Webex-cloud is om te controleren of de identiteit van degene die u vanuit Cisco Webex belt, klopt en niet vervalst is.

Hiervoor vereist Cisco Webex dat het bedrijf kan bewijzen dat het de eigenaar is van de domeinen die worden gebruikt bij hybride bellen. Als dit niet het geval is, werkt niet.

Om dit eigendom te garanderen, zijn twee domeinverificatiestappen vereist:

1. Bewijzen dat het bedrijf eigenaar is van het e-maildomein, het Expressway-E-domein, het directory-URI-domein.

   • Al deze domeinen moeten omleidbaar zijn en bekend bij de publieke DNS-servers.

   • Om dit eigendom te bewijzen, moet de DNS-beheerder een DNS-tekstrecord (TXT) invoeren. Een TXT-record is een type resource in de DNS dat wordt gebruikt voor de mogelijkheid om een willekeurige en niet-opgemaakte tekst te koppelen aan een host of andere naam.

   • De DNS-beheerder moet deze TXT-record invoeren in de zone waarvan het eigendom moet worden bewezen. Na deze stap voert de Cisco Webex-cloud een TXT-recordquery voor dat domein uit.

   • Als de TXT-query gelukt is en het resultaat overeenkomt met het token dat is gegenereerd vanuit de Cisco Webex-cloud, is het domein geverifieerd.

   • Stel dat de beheerder moet bewijzen dat zij eigenaar is van het domein 'voorbeeld.com', als ze wil dat hybride Cisco Webex-services binnen haar domein werken.

   • Via https://admin.webex.com start ze het verificatieproces door een TXT-record te maken die is afgestemd op het token dat de Cisco Webex-cloud heeft gegenereerd:

     

   • De DNS-beheerder maakt dan een TXT-record voor dit domein met de waarde ingesteld op 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, zoals in het volgende voorbeeld:

     

   • Op dit moment kan de cloud bevestigen dat de TXT-record voor het domein voorbeeld.com overeenkomt met het token.

   • De cloud voert een TXT-DNS-zoekopdracht uit:

     

   • Omdat de TXT-waarde overeenkomt met de waarde van het token, bewijst deze overeenkomst dat de beheerder het TXT-record voor haar eigen domein heeft toegevoegd aan het openbare DNS en dat ze de eigenaar van het domein is.

2. Eigendomscontrole van Expressway-E-DNS-naam.

   • De cloud moet controleren dat de Expressway-E een bevestigde identiteit heeft van een van de certificeringsinstanties die bij de cloud vertrouwd is. De Expressway-E-beheerder moet een openbaar certificaat voor zijn Expressway-E bij een van deze certificeringsinstanties aanvragen. Voordat dit certificaat wordt uitgegeven, voert de certificeringsinstantie een identiteitsverificatieproces uit op basis van een domeinvalidatiecontrole (voor certificaten waarvoor het domein is geverifieerd) of een bedrijfsvalidatiecontrole (voor certificaten waarvoor het bedrijf is geverifieerd).

   • Gesprekken naar en van de cloud zijn afhankelijk van het certificaat dat is uitgegeven aan de Expressway-E. Als het certificaat niet geldig is, wordt het gesprek onderbroken.

De Expressway-C-connectorhost moet worden geregistreerd bij Cisco Webex zodat hybride services kunnen werken.

Expressway-C is in het interne netwerk geïmplementeerd en wordt via een uitgaande HTTPS-verbinding bij de cloud geregistreerd: hetzelfde type dat wordt gebruikt voor elke browser die verbinding maakt met een webserver.

Registratie en berichten naar de Cisco Webex-cloud gaat via TLS. Expressway-C is de TLS-client en de Cisco Webex-cloud is de TLS-server. Zo controleert Expressway-C het servercertificaat.

De certificeringsinstantie tekent het servercertificaat met zijn eigen privé-sleutel. Iedereen met de openbare sleutel kan deze handtekening decoderen en bewijzen dat dezelfde certificeringsinstantie dat certificaat heeft getekend.

Als de Expressway-C het certificaat van de cloud moet verifiëren, moet deze voor het decoderen van de handtekening de openbare sleutel gebruiken van de certificeringsinstantie die het certificaat heeft getekend. Een openbare sleutel is opgenomen in het certificaat van de certificeringsinstantie. De lijst met certificaten van deze vertrouwde certificeringsinstanties moet zich in de 'trust store' van de Expressway bevinden, om vertrouwen op te bouwen met de certificeringsinstanties die door de cloud worden gebruikt. Hierdoor kan de Expressway bewijzen dat het gesprek werkelijk van de Cisco Webex-cloud afkomstig is.

Met handmatig uploaden kunt u alle relevante certificaten van certificeringsinstanties naar de trust store van Expressway-C uploaden.

Met automatisch uploaden uploadt de cloud deze certificaten zelf naar de trust store van Expressway-C. We raden u aan om automatisch uploaden te gebruiken. De certificatenlijst kan worden gewijzigd. Automatisch uploaden garandeert dat u de recentste lijst hebt.

Als u het automatisch installeren van certificaten van certificeringsinstanties wilt toestaan, wordt u omgeleid naar https://admin.webex.com (de beheerportal). De omleiding wordt uitgevoerd door de Expressway-C zelf, zonder tussenkomst van een gebruiker. U, als Cisco Webex-beheerder, moet worden geverifieerd via een HTTPS-verbinding. Kort hierna pusht de cloud de CA-certificaten naar de Expressway-C.

Pas als de certificaten zijn geüpload naar de trust store van de Expressway-C kan de HTTPS-verbinding tot stand worden gebracht.

Om dit probleem te vermijden, is de Expressway-C vooraf geïnstalleerd met Cisco Webex-vertrouwde CA-certificaten. Deze certificaten worden alleen gebruikt om de initiële HTTPS-verbinding in te stellen en te verifiëren. Ze worden niet weergegeven in de vertrouwde lijst van de Expressway-C. Nadat de certificaten van de vertrouwde certificeringsinstanties zijn opgehaald van de cloud via deze initiële HTTPS-verbinding, zijn deze certificaten binnen het hele platform beschikbaar voor gebruik. Vervolgens worden ze weergegeven in de vertrouwde lijst van de Expressway-C.

In deze lijst staan de certificaten van certificeringsinstanties die de Cisco Webex-cloud momenteel gebruikt. Deze lijst kan in de toekomst worden gewijzigd:

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

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

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

• C=VS, 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=VS, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - Alleen voor geautoriseerd gebruik, CN=thawte Primary Root CA

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

Een lijst met certificaten van certificeringsinstanties is ook vereist voor de Expressway-E in het traversalpaar. Expressway-E communiceert met de Cisco Webex-cloud via SIP met TLS, geïmplementeerd door gemeenschappelijke autorisatie. Expressway-E vertrouwt gesprekken van en naar de cloud alleen als de CN of SAN van het certificaat dat door de cloud wordt gepresenteerd tijdens de TLS-verbindingsinstelling, overeenkomt met de onderwerpnaam die is geconfigureerd voor de DNS-zone op Expressway ('callservice.webex.com'). De certificeringsinstantie geeft alleen een certificaat uit wanneer een identiteitscontrole is uitgevoerd. Het eigendom van het callservice.webex.com-domein moet worden aangetoond om een ondertekend certificaat te ontvangen. Omdat wij (Cisco) eigenaar zijn van dat domein, is de DNS-naam 'callservice.webex.com' direct bewijs dat de externe peer daadwerkelijk Cisco Webex is.

Agendaconnector integreert Cisco Webex met Microsoft Exchange 2010, 2013, 2016 of Office 365 via een imitatieaccount. Met de beheerdersrol in Exchange voor imitatie van toepassingen kunnen toepassingen gebruikers binnen een bedrijf imiteren om namens hen taken uit te voeren. Deze rol moet worden geconfigureerd in Exchange en wordt gebruikt in de Agendaconnector als onderdeel van de Exchange-configuratie op de Expressway-C-interface.

Het Exchange-imitatieaccount is de aanbevolen methode van Microsoft voor deze taak. De Expressway-C-beheerders hoeven het wachtwoord niet te weten omdat de waarde door een Exchange-beheerder in de Expressway-C-interface kan worden ingevoerd. Het wachtwoord wordt niet duidelijk weergegeven, zelfs als de Expressway-C-beheerder hoofdtoegang tot het Expressway-C-vak heeft. Het wachtwoord wordt versleuteld opgeslagen met hetzelfde versleutelingsmechanisme voor verificatiegegevens als andere wachtwoorden op de Expressway-C.

Voor extra beveiliging volgt u de stappen in Implementatiehandleiding voor Cisco Webex hybride agendaservice om TLS in te schakelen zodat u EWS-verbindingen op de draad kunt beveiligen.