Dit gedeelte biedt extra context over belangrijke configuratie-items die betrekking hebben op hybride services.

Deze punten zijn cruciaal als u hybride gesprekken voor Webex-apparaten wilt implementeren. We hebben deze items in het bijzonder uitgelicht vanwege de volgende redenen:

• We willen deze uitleggen zodat u hun rol in een hybride implementatie begrijpt en gerust kunt zijn.

• Ze zijn verplichte vereisten die zorgen voor een veilige implementatie tussen onze cloud en uw lokale omgeving.

• Ze moeten worden behandeld als 'pre-day zero'-activiteiten: het kan iets langer duren dan normaal om een typische configuratie in een gebruikersinterface te voltooien, dus zorg ervoor dat er genoeg tijd is om deze items te sorteren.

• Nadat deze items in uw omgeving zijn behandeld, gaat de configuratie van uw hybride services soepel.

De implementatie van het Expressway-C- en Expressway-E-paar maakt gesprekken naar en van internet mogelijk met behulp van firewall-traversal-technologieën. Met deze implementatie wordt uw gespreksbeheer op locatie veilig geïntegreerd in 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:

_sips._tcp.example.com SRV-servicelocatie:

prioriteit = 10

gewicht = 10

poort = 5062

serverhostnaam = us-expe1.voorbeeld.com

_sips._tcp.example.com SRV-servicelocatie:

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-invoer _sips._tcp bevat, specificeert de invoer SIP TLS.

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 verbinding tussen server en server, bijvoorbeeld tijdens een gesprek dat tot stand is gebracht tussen Expressway-E en de Webex-cloud. Dit concept heet TLS met wederzijdse verificatie en is vereist bij de integratie met 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. Hybride Webex-services gebruiken dezelfde SIP TLS-record als voor B2B. In het geval van poort 5061 werken sommige andere services die geen TLS-clientcertificaat kunnen geven niet.

Als een bestaande record al wordt gebruikt voor business-to-businesscommunicatie, raden we u aan als volgt een subdomein van het bedrijfsdomein op te geven als SIP-bestemming in Control Hub en bijgevolg een openbare DNS SRV-record:

 Service en protocol: _sips._tcp.mtls.example.com Prioriteit: 1 Gewicht: 10 Poortnummer: 5062 Doel: us-expe1.voorbeeld.com 

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

Business-to-business-gesprekken (B2B) en Mobile and Remote Access-gesprekken (MRA) gebruiken poort 5061 voor SIP TLS en Webex-verkeer gebruikt poort 5062 voor SIP TLS met wederzijdse verificatie.

De controle van het domeineigendom is onderdeel van de identiteitsverificatie. Domeinverificatie is een beveiligingsmaatregel en identiteitscontrole die door de Webex-cloud worden geïmplementeerd om te bewijzen dat u bent wie u zegt dat u bent.

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.

Het belang van de domeineigendomscontrole

De Webex-cloud voert de domeineigendomscontrole uit om beveiliging af te dwingen. 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 een DNS-domein ingesteld op 'hacker.com' koopt hybride 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 ze zich aan bij de Webex-app met jane.roe@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 een collega, John Doe, door john.doe@example.com te bellen vanuit haar Webex-app. John zit in zijn kantoor en ziet een gesprek op zijn videoapparaat afkomstig van jane.roe@example.com; dat is de directory-URI die is gekoppeld aan dat 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.

Voorbeeld.com biedt veel manieren om u te beschermen tegen frauduleuze gesprekken via internet, maar een van de verantwoordelijkheden van de Webex-cloud is ervoor te zorgen dat de identiteit van iedereen die belt vanuit Webex juist is en niet wordt vervalst.

Om de identiteit te controleren, vereist Webex dat het bedrijf bewijst dat het eigenaar is van de domeinen die worden gebruikt in hybride gesprekken. Als dit niet het geval is, werken hybride services 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 Webex-cloud een TXT-recordquery uit voor dat domein.

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

   • De beheerder moet bijvoorbeeld bewijzen dat ze eigenaar is van het domein 'voorbeeld.com', als ze wil dat Webex hybride services aan haar domein werken.

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

     

   • De DNS-beheerder maakt vervolgens 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.

Hybride gesprekken werken alleen als de Webex-apparaatconnector met Webex communiceert.

De Webex Device Connector wordt geïmplementeerd in het interne netwerk en communiceert met de cloud via een uitgaande HTTPS-verbinding. Dit type wordt gebruikt voor elke browser die verbinding maakt met een webserver.

Communicatie met de Webex-cloud maakt gebruik van TLS. Webex Device Connector is de TLS-client en de Webex-cloud is de TLS-server. Als zodanig controleert Webex Device Connector 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 Webex Device Connector het door de cloud verstrekte certificaat moet valideren, moet deze de openbare sleutel van de certificeringsinstantie die dat certificaat heeft ondertekend gebruiken om de handtekening te decoderen. Een openbare sleutel is opgenomen in het certificaat van de certificeringsinstantie. Om vertrouwen te wekken bij de certificeringsinstanties die door de cloud worden gebruikt, moet de lijst met certificaten van deze vertrouwde certificeringsinstanties in de vertrouwensopslag van Webex Device Connector staan.

Bij communicatie met apparaten gebruikt de tool vertrouwde certificaten die u levert. U kunt dat op dit moment doen door ze in [persoonlijke map]/.devicestool/certs te plaatsen.

Een lijst met certificaten van certificeringsinstanties is ook vereist voor de Expressway-E in het traversalpaar. Expressway-E communiceert met de Webex-cloud via SIP met TLS, en wordt afgedwongen door wederzijdse verificatie. Expressway-E vertrouwt alleen gesprekken die afkomstig zijn van en naar de cloud gaan als de CN of SAN van het certificaat dat door de cloud is gepresenteerd tijdens het instellen van de TLS-verbinding overeenkomt met de onderwerpnaam die is geconfigureerd voor de DNS-zone in Expressway ('callservice.webex.com'). De certificeringsinstantie geeft alleen een certificaat uit wanneer een identiteitscontrole is uitgevoerd. Het eigenaarschap van het domein callservice.webex.com moet worden bewezen om een certificaat te kunnen laten ondertekenen. Omdat wij (Cisco) eigenaar zijn van dat domein, is de DNS-naam 'callservice.webex.com' een direct bewijs dat de externe peer echt Webex is.

agendaconnector integreert Webex met Microsoft Exchange 2013, 2016, 2019 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. Expressway-C-beheerders hoeven het wachtwoord niet te weten omdat de waarde door een Exchange-beheerder kan worden ingevoerd in de Expressway-C-interface. 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 gebruikergegevens 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.

Voor extra beveiliging volgt u de stappen in Implementatie van Expressway Calendar Connector voor Microsoft Exchange om TLS in teschakelen zodat u EWS-verbindingen op de draad kunt beveiligen.