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

Deze punten zijn cruciaal als u Hybrid Calling succesvol wilt implementeren voor Webex-apparaten. We hebben deze punten in het bijzonder uitgelicht om de volgende redenen:

• We willen ze uitleggen, zodat u hun rol in een hybride implementatie begrijpt en u gerustgesteld voelt.

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

• Ze moeten worden behandeld als activiteiten vóór de dag nul: het kan iets langer duren om ze te voltooien dan bij een normale configuratie in een gebruikersinterface, dus houd rekening met een tijdsbestek om deze items te sorteren.

• Nadat deze items in uw omgeving zijn behandeld, verloopt de rest van uw Hybrid Services-configuratie probleemloos.

De combinatie Expressway-C en Expressway-E maakt gesprekken van en naar het internet mogelijk met behulp van firewalltraversaltechnologieën. Deze implementatie zorgt ervoor dat uw gespreksbeheer op locatie veilig wordt gekoppeld aan Webex.

De Expressway-C en Expressway-E hebben geen binnenkomende poort nodig om te worden geopend in de firewall van de gedemilitariseerde zone (DMZ) vanwege de architectuur die de firewall doorkruist. Maar de TCP SIP-signaalpoorten en UDP-mediapoorten moeten binnenkomend op de internetfirewall worden geopend om binnenkomende gesprekken door te laten gaan. U moet de tijd nemen om de juiste poort van uw bedrijfsfirewall te openen .

De architectuur voor het doorkruisen van de firewall wordt weergegeven in het volgende diagram:

Voor inkomende gesprekken tussen bedrijven (B2B) die het SIP-protocol gebruiken, moeten de TCP-poorten 5060 en 5061 (5061 wordt gebruikt voor SIP TLS) op de externe firewall worden geopend, samen met de UDP-mediapoorten die worden gebruikt voor diensten zoals spraak, video, het delen van inhoud, dubbele video, enzovoort. Welke mediapoorten moeten worden geopend, hangt af van het aantal gelijktijdige gesprekken en het aantal diensten.

U kunt de SIP-luisterpoort op Expressway zo configureren dat deze tussen 1024 en 65534 ligt. Tegelijkertijd moeten deze waarde en het protocoltype worden vermeld in de openbare DNS SRV registers, en diezelfde waarde moet worden geopend op de internetfirewall.

Hoewel de standaard voor SIP TCP 5060 is en voor SIP TLS 5061, staat niets het gebruik van verschillende poorten in de weg, zoals in het volgende voorbeeld wordt aangetoond.

Voorbeeld

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

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

_slokjes. Locatie van de SRV-service _tcp.example.com:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_slokjes. Locatie van de SRV-service _tcp.example.com:

priority = 10

weight = 10

port = 5062

svr hostnaam = us-expe2.example.com

Deze gegevens betekenen dat gesprekken worden doorverwezen naar us-expe1.example.com en us-expe2.example.com met een gelijke verdeling van de belasting (prioriteit en gewicht) met TLS als transporttype en 5062 als luisterpoortnummer.

Een apparaat dat zich buiten het netwerk bevindt (op het internet) en dat een SIP-oproep doet naar een gebruiker van het bedrijfsdomein (user1@example.com) moet de DNS opvragen om te begrijpen welk transporttype moet worden gebruikt, wat het poortnummer is, hoe het verkeer moet worden geladen en naar welke SIP-servers de oproep moet worden gestuurd.

Als de DNS-invoer _sips bevat. _tcp, de vermelding specificeert SIP TLS.

TLS is een client-serverprotocol en gebruikt in de meest voorkomende implementaties certificaten voor authenticatie. Bij een gesprek tussen bedrijven is de TLS-client het oproepende apparaat en de TLS-server het aangeroepen apparaat. Met TLS controleert de client het certificaat van de server en als de certificaatcontrole mislukt, wordt de verbinding verbroken. De klant heeft geen certificaat nodig.

De TLS-handdruk wordt weergegeven in het volgende diagram:

In de TLS-specificatie staat echter dat de server het clientcertificaat ook kan controleren door tijdens het TLS-handshakeprotocol een Certificate Request-bericht naar de client te sturen. Dit bericht is nuttig bij een verbinding tussen server en server, bijvoorbeeld tijdens een telefoongesprek tussen Expressway-E en de Webex-cloud. Dit concept heet TLS met wederzijdse authenticatie en is vereist bij integratie met Webex.

Zowel de oproepende als de gebelde partij controleren het certificaat van de andere peer, zoals uit het volgende schema blijkt:

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

Als wederzijdse authenticatie is ingeschakeld, vraagt Expressway-E altijd om het clientcertificaat. Als gevolg hiervan zullen Mobile en Remote Access (MRA) niet werken, omdat certificaten in de meeste gevallen niet worden geïmplementeerd op Jabber-clients . In een scenario tussen bedrijven wordt de verbinding verbroken als de oproepende entiteit geen certificaat kan verstrekken.

We raden u aan een andere waarde dan 5061 te gebruiken voor TLS met wederzijdse authenticatie, zoals poort 5062. Webex Hybrid Services gebruiken hetzelfde SIP TLS-record dat wordt gebruikt voor B2B. In het geval van poort 5061 zullen sommige andere services die geen TLS-clientcertificaat kunnen leveren, niet werken.

Als een bestaand record al wordt gebruikt voor communicatie tussen bedrijven, raden we aan om in Control Hub een subdomein van het bedrijfsdomein op te geven als de SIP-bestemming, en bijgevolg een openbaar DNS SRV record, als volgt:

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

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

Business-to-Business (B2B) en mobiele gesprekken Remote Access (MRA) gebruiken poort 5061 voor SIP TLS, en Webex traffic gebruikt poort 5062 voor SIP TLS met wederzijdse authenticatie.

De controle van het domeineigendom maakt deel uit van de identiteitsverificatie. Domeinverificatie is een beveiligingsmaatregel en identiteitscontrole die de Webex-cloud implementeert om te bewijzen dat u bent wie u zegt dat u bent.

De identiteitscontrole wordt in twee fasen uitgevoerd:

1. Controleer het eigendom van het domein. Deze stap omvat drie soorten domeinen en is een eenmalige verificatiecontrole:

   • E-maildomein

   • Expressway-E DNS-domein

   • Directory-URI-domein

2. Expressway-E DNS-naamcontrole. Deze stap wordt uitgevoerd door de implementatie van TLS met wederzijdse authenticatie en omvat het gebruik van openbare certificaten in zowel de cloud als op de snelweg. In tegenstelling tot de identiteitscontrole van het domein wordt deze stap uitgevoerd tijdens elk gesprek dat wordt gevoerd naar en ontvangen vanuit de cloud.

Het belang van de controle van het domeinbezit

De Webex-cloud voert de controle van het domeineigendom uit om de beveiliging af te dwingen. Identiteitsdiefstal is een mogelijke bedreiging als deze controle niet wordt uitgevoerd.

In het volgende verhaal wordt beschreven wat er kan gebeuren als er geen controle van het domeineigendom wordt uitgevoerd.

Een bedrijf waarvan het DNS-domein is ingesteld op „hacker.com” koopt Webex Hybrid Services. Een ander bedrijf, met een eigen domein ingesteld op „example.com”, maakt ook gebruik van hybride diensten. Eén van de algemeen managers van het bedrijf Example.com heet Jane Roe en heeft de adreslijst URI jane.roe@example.com.

De beheerder van het bedrijf Hacker.com stelt een van haar adresboek-URI's in op jane.roe@example.com en het e-mailadres op jane.roe@hacker.com. Dat kan ze 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 de eigenaar is van het domein, wordt de verificatie-e-mail gelezen en beantwoord en kan ze zich aanmelden. Tot slot belt ze een collega, John Doe, door via haar Webex-app naar john.doe@example.com te bellen. John zit in zijn kantoor en ziet een oproep op zijn videoapparaat van jane.roe@example.com; dat is de adresboek-URI die aan dat e-mailaccount is gekoppeld.

„Ze is in het buitenland”, denkt hij. „Misschien heeft ze iets belangrijks nodig.” Hij neemt de telefoon op en de valse Jane Roe vraagt om belangrijke documenten. Ze legt uit dat haar apparaat kapot is en omdat ze op reis is, vraagt ze hem de documenten naar haar privé-e-mailadres, jane.roe@hacker.com, te sturen. Op deze manier beseft het bedrijf pas nadat Jane Roe terugkomt op kantoor dat belangrijke informatie buiten het bedrijf is gelekt.

Het bedrijf Example.com heeft vele manieren om u te beschermen tegen frauduleuze oproepen van het internet, maar een van de verantwoordelijkheden van de Webex-cloud is ervoor te zorgen dat de identiteit van iedereen die belt via Webex correct is en niet vervalst.

Om de identiteit te controleren, vereist Webex dat het bedrijf bewijst dat het de eigenaar is van de domeinen die worden gebruikt bij Hybrid Calling. Als dat niet het geval is, zullen hybride diensten niet werken.

Om ervoor te zorgen dat dit eigendom is, zijn de twee stappen voor domeinverificatie vereist:

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

   • Al deze domeinen moeten routeerbaar zijn en bekend zijn bij openbare DNS-servers.

   • Om de eigendom te bewijzen, moet de DNS-beheerder een DNS-tekstrecord (TXT) invoeren. Een TXT-record is een soort bronrecord in de DNS dat wordt gebruikt om willekeurige en ongeformatteerde tekst te koppelen aan een host- of andere naam.

   • De DNS-beheerder moet dat TXT-record invoeren in de zone waarvan de 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 is gegenereerd in de Webex-cloud, wordt het domein geverifieerd.

   • De beheerder moet bijvoorbeeld bewijzen dat ze de eigenaar is van het domein „example.com”, als ze wil dat Webex Hybrid Services op haar domein werkt.

   • Via https://admin.webex.com start 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 voor dit domein met de waarde ingesteld op 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, zoals in het volgende voorbeeld:

     

   • Op dit moment kan de cloud verifiëren dat het TXT-record voor het domein example.com overeenkomt met het token.

   • De cloud voert een TXT DNS-lookup uit:

     

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

2. Expressway-E DNS-naamcontrole.

   • De cloud moet controleren of de Expressway-E een bevestigde identiteit heeft van een van de certificeringsinstanties die de cloud vertrouwt. De Expressway-E-beheerder moet een openbaar certificaat voor zijn Expressway-E aanvragen bij een van die certificeringsinstanties. Om het certificaat uit te geven, voert de certificeringsinstantie een identiteitsverificatieproces uit, gebaseerd op een domeinvalidatiecontrole (voor domeingevalideerde certificaten) of een validatiecontrole van de organisatie (voor gevalideerde certificaten van de organisatie).

   • Oproepen van en naar de cloud zijn afhankelijk van het certificaat dat werd uitgegeven aan de Expressway-E. Als het certificaat niet geldig is, wordt de oproep verbroken.

De Webex Device Connector moet communiceren met Webex om Hybrid Calling te laten werken.

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

De communicatie naar de Webex-cloud maakt gebruik van TLS. Webex Device Connector is de TLS-client en de Webex-cloud is de TLS-server. Webex Device Connector controleert dus het servercertificaat.

De certificeringsinstantie ondertekent een servercertificaat met haar eigen privésleutel. Iedereen met de openbare sleutel kan die handtekening ontcijferen en bewijzen dat dezelfde certificeringsinstantie dat certificaat heeft ondertekend.

Als Webex Device Connector het certificaat moet valideren dat door de cloud wordt geleverd, moet het de openbare sleutel gebruiken van de certificeringsinstantie die dat certificaat heeft ondertekend om de handtekening te decoderen. Een openbare sleutel is opgenomen in het certificaat van de certificeringsinstantie. Om vertrouwen te creëren bij de certificeringsinstanties die door de cloud worden gebruikt, moet de lijst met certificaten van deze vertrouwde certificeringsinstanties zich in de Webex Device Connector Trust Store bevinden.

Bij communicatie met apparaten maakt de tool gebruik van betrouwbare certificaten die u verstrekt. Momenteel kunt u dat doen door ze erin te plaatsen [home folder]/.devicestool/certs.

Een lijst van certificaten van certificeringsinstanties is ook vereist voor de Expressway-E in het traversal pair. Expressway-E communiceert met de Webex-cloud via SIP met TLS, afgedwongen door wederzijdse authenticatie. Expressway-E vertrouwt oproepen die van en naar de cloud gaan, alleen als de CN of SAN van het certificaat dat door de cloud wordt aangeboden tijdens de installatie van de TLS-verbinding overeenkomt met de onderwerpnaam die is geconfigureerd voor de DNS-zone op Expressway („callservice.webex.com”). De certificeringsinstantie geeft een certificaat pas vrij na een identiteitscontrole. De eigendom van het domein callservice.webex.com moet worden bewezen om een certificaat te laten ondertekenen. Omdat wij (Cisco) eigenaar zijn van dat domein, is de DNS-naam „callservice.webex.com” het directe bewijs dat de externe peer echt Webex is.

De agendaconnector integreert Webex met Microsoft Exchange 2013, 2016, 2019 of Office 365 via een imitatieaccount. De rol van applicatiebeheer in Exchange stelt toepassingen in staat om zich voor te doen als gebruikers in een organisatie om taken uit te voeren namens de gebruiker. De impersonatierol van de toepassing moet in Exchange worden geconfigureerd en wordt in de agendaconnector gebruikt als onderdeel van de Exchange-configuratie op de Expressway-C-interface.

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

Volg voor extra beveiliging de stappen in de implementatiegids voor Cisco Webex Hybrid Calendar Service om TLS in te schakelen om EWS-verbindingen op de kabel te beveiligen.

Volg voor extra beveiliging de stappen in Deploy Expressway Calendar Connector om TLS in Microsoft Exchange te schakelen om EWS-verbindingen op de kabel te beveiligen.