Det här avsnittet ger ytterligare kontext om viktiga konfigurationsobjekt som är relaterade till Hybrid-tjänster.

Dessa punkter är avgörande om du vill distribuera hybridsamtal för Webex-enheter. Vi har markerat de här objekten särskilt av följande orsaker:

• Vi vill förklara dem så att du förstår deras roll i en hybriddistribution och kan känna dig trygg.

• De är obligatoriska förutsättningar som säkerställer en säker distribution mellan våra molntjänster och din lokala miljö.

• De ska behandlas som aktiviteter före dag noll: de kan ta lite längre tid att slutföra än en vanlig konfiguration i ett användargränssnitt, så planera för en tidsram där alla objekt hinner sorteras.

• När dessa objekt har åtgärdats i din miljö går resten av konfigurationen för Hybrid-tjänster smidigt.

Distributionen av Expressway-C och Expressway-E tillåter samtal till och från internet med hjälp av brandväggstraversal-tekniker. Den här distributionen tar din lokala samtalskontroll på ett säkert sätt och kopplar den till Webex.

För Expressway-C och Expressway-E krävs inte att en inkommande port öppnas i brandväggen för demilitariserad zon (DMZ) på grund av brandväggens traversalarkitektur. Men TCP SIP-signaleringsportar och UDP-medieportar måste öppnas för att inkommande samtal ska komma igenom. Du måste vänta en stund för att lämplig port ska öppnas på företagsbrandväggen.

Brandväggens traversalarkitektur visas i följande diagram:

För till exempel inkommande B2B-samtal (business-to-business) där SIP-protokoll används måste TCP-portarna 5060 och 5061 (5061 används för SIP TLS) öppnas på den externa brandväggen, tillsammans med UDP-medieportar som används för tjänster som t.ex. röst, video, dokumentdelning, dubbel video och så vidare. Vilka medieportar som ska öppnas beror på antalet samtidiga samtal och antalet tjänster.

Du kan konfigurera SIP-lyssningsporten på Expressway med vilket värde som helst mellan 1024 och 65534. Samtidigt måste värdet och protokolltypen annonseras i offentliga DNS SRV-register och samma värde måste öppnas på internetbrandväggen.

Även om standarden för SIP TCP är 5060 och SIP TLS 5061 förhindras inte användning av olika portar, vilket visas i följande exempel.

Exempel

I det här exemplet förutsätter vi att port 5062 används för inkommande SIP TLS-samtal.

DNS SRV-registreringen för ett kluster med två Expressway-servrar ser ut så här:

_sips._tcp.example.com SRV-tjänstplats:

prioritet = 10

vikt = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV-tjänstplats:

prioritet = 10

vikt = 10

port = 5062

svr hostname = us-expe2.example.com

Registreringarna innebär att samtal dirigeras till us-expe1.example.com och us-expe2.example.com med samma lastdelning (prioritet och vikt) där TLS används som transporttyp och 5062 som lyssningsportnummer.

När ett SIP-samtal till en användare av företagsdomänen (user1@example.com) sker via en enhet som är extern i nätverket (på internet), måste DNS tillfrågas för att enheten ska förstå vilken transporttyp och vilket portnummer som ska användas, hur trafiken ska laddas/delas och till vilka SIP-servrar som samtalet ska skickas.

Om DNS-posten innehåller _sips._tcp anger posten SIP TLS.

TLS är ett klientserverprotokoll för vilka det, i de vanligaste implementeringarna, används certifikat för autentisering. I ett business-to-business-samtalsscenario är TLS-klienten den anropande enheten och TLS-servern den uppringda enheten. Med TLS kontrollerar klienten certifikatet på servern och om kontrollen misslyckas kopplas samtalet bort. Det behövs inget certifikat för klienten.

TLS-handskakningen visas i följande diagram:

Med TLS-specifikationen fastställs dock att servern också kan kontrollera klientcertifikatet genom att skicka ett meddelande om certifikatförfrågan till klienten under TLS-handskakningsprotokollet. Det här meddelandet är användbart vid en server-till-server-anslutning, t.ex. vid samtal som upprättas mellan Expressway-E och Webex-molnet. Detta koncept kallas TLS med ömsesidig autentisering och krävs vid integrering med Webex.

Både parten som ringer och parten som blir uppringd kontrollerar certifikatet för den andra deltagaren enligt följande diagram:

Molnet kontrollerar Expressway-identiteten och Expressway kontrollerar molnets identitet. Om molnets identitet i certifikatet (CN eller SAN) inte överensstämmer med vad som är konfigurerat på Expressway bryts anslutningen.

Om ömsesidig autentisering är aktiverat gör Expressway-E alltid en begäran om klientcertifikatet. Som en följd av det fungerar inte mobil åtkomst eller fjärråtkomst (MRA) eftersom certifikat i de flesta fall inte distribueras för Jabber-klienter. I ett business-to-business-scenario, om den anropande enheten inte kan tillhandahålla ett certifikat, kopplas samtalet bort.

Vi rekommenderar att du använder ett annat värde än 5061 för TLS med ömsesidig autentisering, till exempel port 5062. Webex Hybrid-tjänster använder samma SIP TLS-post som används för B2B. I fallet med port 5061 fungerar inte vissa andra tjänster som inte kan tillhandahålla ett TLS-klientcertifikat.

Om en befintlig post redan används för kommunikation mellan företag rekommenderar vi att du anger en underdomän till företagsdomänen som SIP-destination i Control Hub och därmed en offentlig DNS SRV-post enligt följande:

 Tjänst och protokoll: _sips._tcp.mtls.example.com Prioritet: 1 Vikt: 10 Portnummer: 5062 Mål: us-expe1.example.com 

Business-to-Business, mobilåtkomst och Remote Access samt Webex-trafik på samma Expressway-par

Samtal mellan företag (B2B) och mobil och fjärråtkomst (MRA) använder port 5061 för SIP TLS, och Webex-trafik använder port 5062 för SIP TLS med ömsesidig autentisering.

Kontrollen av ägarskap för domänen ingår i identitetsverifieringen. Domänverifiering är en säkerhetsåtgärd och identitetskontroll som Webex-molnet implementerar för att bevisa att du är den du säger att du är.

Identitetskontrollen utförs i två steg:

1. Kontroll av domänens ägarskap. Det här steget omfattar tre typer av domäner och är en engångsverifiering:

   • Reservera domän

   • DNS-domän för Expressway-E

   • URI-domän för katalog

2. Ägarskapskontroll av DNS-namn för Expressway-E. Det här steget utförs via implementeringen av TLS med ömsesidig autentisering och innebär användning av offentliga certifikat på både molnet och Expressway. Till skillnad från identitetskontrollen av domänen utförs det här steget under alla samtal som tas emot i molnet.

Betydelsen av domänägarkontroll

Webex-molnet utför domänägarkontrollen för att upprätthålla säkerheten. Om kontrollen inte utförs är identitetsstöld ett möjligt hot.

Följande historia beskriver vad som kan hända om en ägarskapskontroll inte utförs.

Ett företag med en DNS-domän inställd på ”hacker.com” köper Webex Hybrid-tjänster. Ett företag med sin egen domän inställd på ”exempel.com” använder också Hybrid-tjänster. En av cheferna på företaget Exempel.com heter Johanna Svensson och har katalog-URI johanna.svensson@exempel.com.

Administratören på företaget Hacker.com ställer in en av sina katalog-URI:er till johanna.svensson@exempel.com och e-postadressen till johanna.svensson@hacker.com. Hon kan göra det eftersom molnet inte kontrollerar SIP URI-domänen i det här exemplet.

Sedan loggar hon in på Webex-appen med jane.roe@hacker.com. Eftersom hon äger domänen har verifieringsmeddelandet lästs och besvarats och hon kan logga in. Slutligen ringer hon till en kollega, John Doe, genom att ringa john.doe@example.com från sin Webex-app. John sitter på sitt kontor och ser ett samtal på sin videoenhet från jane.roe@example.com. Det är den katalog-URI som är kopplad till det e-postkontot.

”Hon är utomlands,” tror han. ”Hon kan behöva något viktigt.” Han svarar i telefonen och den falska Johanna Svensson frågar efter ett mycket viktigt dokument. Hon förklarar att hennes enhet inte fungerar och eftersom hon är på resa ber hon honom att skicka dokumentet till sin privata e-postadress, johanna.svensson@hacker.com. På det sättet förstår inte företaget att viktig information har läckt utanför företaget förrän Johanna Svensson är tillbaka på kontoret.

Företaget Example.com har många sätt att skydda mot bedrägliga samtal från internet, men ett av Webex-molnets ansvar är att se till att identiteten på alla som ringer från Webex är korrekt och inte förfalskad.

För att kontrollera identiteten kräver Webex att företaget visar att det äger de domäner som används i hybridsamtal. Annars fungerar inte Hybrid-tjänster.

Följande två kontrollsteg krävs för att säkerställa ägarskapet:

1. Bevisa att företaget äger e-postdomänen, Expressway-E-domänen, katalog-URI-domänen.

   • Alla domäner måste vara dirigerbara och kända av offentliga DNS-servrar.

   • DNS-administratören måste ange en TXT-registrering för att bevisa ägarskapet. EN TXT-registrering är en typ av resursregistrering i DNS som används för att tillhandahålla möjligheten att koppla viss skadlig och oformaterad text med en värd eller annat namn.

   • DNS-administratören måste ange den TXT-registreringen i zonen vars ägarskap måste bevisas. Efter det steget utför Webex-molnet en TXT-registreringsfråga för domänen.

   • Om TXT-frågan lyckades och resultatet matchar token som genererades från Webex-molnet verifieras domänen.

   • Som ett exempel måste administratören bevisa att hon äger domänen ”example.com” om hon vill att Webex Hybrid-tjänster ska fungera på sin domän.

   • Via https://admin.webex.com startar hon verifieringsprocessen genom att skapa en TXT-post som matchar token som Webex-molnet genererade:

     

   • DNS-administratören skapar sedan en TXT-post för denna domän med värdet inställt på 123456789abcdef123456789abcdef123456789abcdef, som i följande exempel:

     

   • Då kan molnet verifiera att TXT-registreringen för domänen exempel.com överensstämmer med token.

   • Molnet utför en TXT DNS-sökning:

     

   • Eftersom TXT-värdet överensstämmer med tokenvärdet bevisar det att administratören har lagt till TXT-registreringen för sin egen domän till den offentliga DNS-servern och att hon äger domänen.

2. Ägarskapskontroll av DNS-namn för Expressway-E.

   • Molnet måste kontrollera att Expressway-E har en bekräftad identitet från en av certifikatutfärdarna som är betrodda av molnet. Administratören för Expressway-E måste begära ett offentligt certifikat för sin Expressway-E till en av de här certifikatutfärdarna. Certifikatutfärdaren utför en identitetsverifieringsprocess för att utfärda certifikatet, baserat på en domänvalideringskontroll (för domänvaliderade certifikat) eller en organisationsvalideringskontroll (för organisationsvaliderade certifikat).

   • Samtal till och från molnet är beroende av det certifikat som har utfärdats till Expressway-E. Om certifikatet inte är giltigt avbryts samtalet.

Webex Device Connector måste kommunicera med Webex för att hybridsamtal ska fungera.

Webex-enhetsanslutning distribueras i det interna nätverket och sättet den kommunicerar med molnet är via en utgående HTTPS-anslutning – samma typ som används för alla webbläsare som ansluter till en webbserver.

Kommunikation till Webex-molnet använder TLS. Webex Device Connector är TLS-klienten och Webex-molnet är TLS-servern. Därför kontrollerar Webex Device Connector servercertifikatet.

Certifikatutfärdaren signerar ett certifikat med sin egen privata nyckel. Alla som har den offentliga nyckeln kan avkoda signaturen och bevisa att samma certifikatutfärdare signerade det certifikatet.

Om Webex Device Connector måste validera certifikatet som tillhandahålls av molnet måste det använda den offentliga nyckeln för certifikatutfärdaren som signerade certifikatet för att avkoda signaturen. Det finns en offentlig nyckel i certifikatet för certifikatutfärdaren. För att upprätta förtroende med de certifikatutfärdare som används av molnet måste listan över certifikat för dessa betrodda certifikatutfärdare finnas i förtroendearkivet för Webex Device Connector.

Vid kommunikation med enheter använder verktyget betrodda certifikat som du tillhandahåller. För närvarande går det att göra det genom att placera dem i [hemmapp]/.devicestool/certs.

En lista över certifikat för certifikatutfärdare krävs även för Expressway-E i traversalparet. Expressway-E kommunicerar med Webex-molnet med SIP med TLS, vilket upprätthålls genom ömsesidig autentisering. Expressway-E litar endast på samtal som kommer från och går till molnet om CN eller SAN för certifikatet som presenteras av molnet vid inställningen av TLS-anslutning matchar ämnesnamnet som konfigurerats för DNS-zonen på Expressway (”callservice.webex.com”). Certifikatutfärdaren utfärdar ett certifikat endast efter en identitetskontroll. Äganderätten till domänen callservice.webex.com måste bevisas för att ett certifikat ska signeras. Eftersom vi (Cisco) äger den domänen är DNS-namnet ”callservice.webex.com” ett direkt bevis på att den fjärranslutna kollegan verkligen är Webex.

kalenderanslutningen integrerar Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 via ett personifieringskonto. Rollen för personifieringshantering i Exchange gör det möjligt för program att efterlikna användare i en organisation och utföra uppgifter på uppdrag av användaren. Rollen för personifiering av program måste konfigureras i Exchange och används i kalenderanslutningen som en del av Exchange-konfigurationen i Expressway-C-gränssnittet.

Personifieringskontot i Exchange är Microsofts rekommenderade metod för den här uppgiften. Expressway-C-administratörer behöver inte känna till lösenordet eftersom värdet kan anges i Expressway-C-gränssnittet av en Exchange-administratör. Lösenordet visas inte tydligt även om administratören för Expressway-C har rotåtkomst till dialogrutan Expressway-C. Lösenordet lagras i krypterad form och använder samma krypteringsmekanism som andra lösenord på Expressway-C.

För extra säkerhet ska du följa stegen i installationsanvisningarna för Cisco Webex Hybrid Calendar Service för att aktivera TLS och säkra EWS-anslutningarna på ledningen.

För extra säkerhet ska du följa stegen i Expressway Calendar Connector för Microsoft Exchange och aktivera TLS och säkra EWS-anslutningar på ledningen.