Deze sectie biedt aanvullende context over belangrijke configuratie-items met betrekking tot hybride services.

Deze punten zijn cruciaal voor een succesvolle implementatie van Hybrid Calling voor Webex-apparaten. 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 punten in uw omgeving zijn aangepakt, zal de rest van uw Hybrid Services-configuratie probleemloos verlopen.

De implementatie van het Expressway-C- en Expressway-E-paar maakt het mogelijk om van en naar het internet te bellen met behulp van firewall-traversal-technologieën. Deze implementatie zorgt ervoor dat uw lokale gespreksbeheer veilig wordt gekoppeld aan 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-vermelding _sips._tcpbevat, dan specificeert de vermelding 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 bij een server-naar-serververbinding, bijvoorbeeld bij een gesprek tussen Expressway-E en de Webex-cloud. Dit concept heet TLS met wederzijdse authenticatie en is vereist bij 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. Webex Hybrid Services gebruikt hetzelfde SIP TLS-record als voor B2B. In het geval van poort 5061 werken sommige andere services die geen TLS-clientcertificaat kunnen geven niet.

Als er al een bestaand record wordt gebruikt voor zakelijke communicatie, raden we aan om in Control Hub een subdomein van het bedrijfsdomein als SIP-bestemming op te geven, en daarmee een openbaar DNS SRV-record, zoals hieronder weergegeven:

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

Zakelijk verkeer (B2B), mobiel en toegang op afstand en Webex-verkeer op dezelfde snelweg.

Zakelijke gesprekken (B2B) en mobiele en externe toegang (MRA) gebruiken poort 5061 voor SIP TLS, terwijl Webex-verkeer poort 5062 gebruikt voor SIP TLS met wederzijdse authenticatie.

De controle van het domeineigendom is onderdeel van de identiteitsverificatie. Domeinverificatie is een beveiligingsmaatregel en identiteitscontrole die 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.

Het belang van de domeinregistratiecontrole

De Webex-cloud voert een domeineigendomscontrole uit om de beveiliging te waarborgen. 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 Webex Hybrid 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. Ten slotte belt ze een collega, John Doe, door het nummer te kiezen. john.doe@example.com via haar Webex-app. John zit in zijn kantoor en ziet een inkomend gesprek op zijn videotelefoon. jane.roe@example.com; Dat is de directory-URI die aan dat e-mailaccount is gekoppeld.

'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 Example.com heeft diverse manieren om zich te beschermen tegen frauduleuze oproepen vanaf internet, maar een van de taken van de Webex-cloud is ervoor te zorgen dat de identiteit van iedereen die via Webex belt, correct is en niet vervalst.

Om de identiteit te verifiëren, vereist Webex dat het bedrijf bewijst dat het eigenaar is van de domeinen die in Hybrid Calling worden gebruikt. Anders werken Hybrid 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 die stap voert de Webex-cloud een TXT-recordquery uit voor dat domein.

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

   • Een beheerder moet bijvoorbeeld bewijzen dat zij de eigenaar is van het domein "example.com" als zij Webex Hybrid Services op haar domein wil gebruiken.

   • Via https://admin.webex.comstart ze het verificatieproces door een TXT-record aan te maken dat overeenkomt met het token dat de Webex-cloud heeft gegenereerd:

     

   • De DNS-beheerder maakt vervolgens een TXT-record aan 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 Webex Device Connector moet met Webex communiceren om hybride bellen mogelijk te maken.

Webex Device Connector is geïmplementeerd in het interne netwerk en communiceert met de cloud via een uitgaande HTTPS-verbinding – hetzelfde type verbinding dat wordt gebruikt door 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. Daarom 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 het 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 creëren met de certificeringsinstanties die door de cloud worden gebruikt, moet de lijst met certificaten van deze vertrouwde certificeringsinstanties in de vertrouwensopslag van de Webex Device Connector staan.

Bij de communicatie met apparaten maakt de tool gebruik van vertrouwde certificaten die u aanlevert. Momenteel doe je dat door ze tussen [home folder]/.devicestool/certste 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, waarbij wederzijdse authenticatie wordt afgedwongen. Expressway-E vertrouwt inkomende en uitgaande gesprekken met de cloud alleen als de CN of SAN van het certificaat dat door de cloud wordt gepresenteerd tijdens het opzetten van de TLS-verbinding 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. Om een certificaat te kunnen ondertekenen, moet het eigendom van het domein callservice.webex.com worden bewezen. Omdat wij (Cisco) eigenaar zijn van dat domein, is de DNS-naam "callservice.webex.com" een direct bewijs dat de externe partij daadwerkelijk 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 door Microsoft aanbevolen methode 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.