Dette afsnit indeholder tilføjet kontekst om nøglekonfigurationselementer, der vedrører Hybrid Services.

Disse punkter er afgørende, hvis du vil implementere Hybrid Calling til Webex-enheder med succes. Vi har især fremhævet disse elementer af følgende grunde:

• Vi vil gerne forklare dem, så du forstår deres rolle i en hybrid implementering og føler dig beroliget.

• De er obligatoriske forudsætninger, der sikrer en sikker implementering mellem vores cloud og dit lokale miljø.

• De skal behandles som nulaktiviteter før dagen: de kan tage lidt længere tid at gennemføre end typisk konfiguration i en brugergrænseflade, så tillad en tidsramme for at få disse emner sorteret.

• Når disse emner er behandlet i dit miljø, vil resten af din Hybrid Services-konfiguration gå problemfrit.

Expressway-C- og Expressway-E- parimplementeringen tillader opkald til og fra internettet ved hjælp af firewall-traverseringsteknologier . Denne implementering er det, der sikkert tager din lokale opkaldskontrol og knytter den til Webex.

Expressway-C og Expressway-E kræver ikke, at nogen indgående port åbnes i den demilitariserede zone (DMZ) firewall på grund af firewall-traversalarkitekturen. Men TCP SIP-signalporte og UDP- medieporte skal åbnes indgående på internet firewallen for at lade indgående opkald komme igennem. Du skal give tid til at få åbnet den relevante port på din virksomheds firewall.

Firewall-krydsningsarkitekturen er vist i følgende diagram:

For indgående B2B-opkald (B2B), der bruger SIP-protokol, skal TCP-porte 5060 og 5061 (5061 bruges til SIP TLS) åbnes på den eksterne firewall sammen med UDP-medieporte, der bruges til tjenester som tale, video, indholdsdeling, dobbelt video osv. Hvilke medieporte, der skal åbnes, afhænger af antallet af samtidige opkald og antallet af tjenester.

Du kan konfigurere SIP-lytteporten på Expressway til at være en hvilken som helst værdi mellem 1024 og 65534. Samtidig skal denne værdi og protokoltypen annonceres i de offentlige DNS SRV registre, og den samme værdi skal åbnes på internetfirewallen.

Selvom standarden for SIP TCP er 5060 og for SIP TLS 5061, forhindrer intet brugen af forskellige porte, som det følgende eksempel viser.

Eksempel

I dette eksempel antager vi, at port 5062 bruges til indgående SIP TLS-opkald.

Rek DNS SRV orden for en klynge på to Expressway-servere ser sådan ud:

_slurker. _tcp.example .com SRV service placering:

priority = 10

weight = 10

port = 5062

svr værtsnavn = us-expe1.example.com

_slurker. _tcp.example .com SRV service placering:

priority = 10

weight = 10

port = 5062

svr værtsnavn = us-expe2.example.com

Disse optegnelser betyder, at opkald dirigeres til us-expe1.example.com og us-expe2.example.com med lige belastnings deling (prioritet og vægt) ved hjælp af TLS som transporttype og 5062 som lytteportnummer.

En enhed, der er ekstern til netværket (på internettet), og som foretager et SIP-opkald til en bruger af virksomheds domænet (user1@example.com), skal forespørge DNS'en for at forstå, hvilken transporttype der skal bruges, port nummeret, hvordan trafikken skal indlæses, og hvilke SIP- servere der skal sendes opkaldet til.

Hvis DNS-posten indeholder _sips. _tcp, indgangen angiver SIP TLS.

TLS er en klient-serverprotokol og bruger i de mest almindelige implementeringer certifikater til godkendelse. I et business-to-business-opkalds scenarie er TLS-klienten den opkaldende enhed, og TLS-serveren er den kaldte enhed. Med TLS kontrollerer klienten serverens certifikat, og hvis certifikatkontrollen mislykkes, afbryder den opkaldet. Kunden har ikke brug for et certifikat.

TLS-håndtryk er vist i følgende diagram:

TLS-specifikationen angiver dog, at serveren også kan kontrollere klientcertifikatet ved at sende en meddelelse om certifikatanmodning til klienten under TLS- håndtryksprotokollen. Denne meddelelse er nyttig på en server-til-server-forbindelse, f.eks. ved opkald, der opre ttes mellem Expressway-E og Webex-skyen. Dette koncept kaldes TLS med gensidig godkendelse og kræves ved integration med Webex.

Både den opkaldende og den opkaldte part kontrollerer certifikatet fra den anden peer, som følgende diagram viser:

Skyen kontrollerer Expressway-identiteten, og Expressway kontrollerer skyidentiteten. Hvis sky identiteten i certifikatet (CN eller SAN) f.eks. ikke svarer til det, der er konfigureret på Expressway, afbry des forbindelsen.

Hvis gensidig godkendelse er slået til, anmoder Expressway-E altid om klientcertifikatet. Som følge heraf fungerer Mobile og Remote Access (MRA) ikke, fordi certifikater i de fleste tilfælde ikke implementeres på Jabber-klienter . Hvis det opkaldende objekt ikke er i stand til at levere et certifikat, afbrydes opkaldet i et business-to- business-scenarie.

Vi anbefaler, at du bruger en anden værdi end 5061 til TLS med gensidig godkendelse, f.eks. Port 5062. Webex Hybrid Services bruger den samme SIP TLS-post, der bruges til B2B. I tilfælde af port 5061 fungerer nogle andre tjenester, der ikke kan levere et TLS-klient certifikat, ikke.

Hvis en eksisterende post allerede bruges til kommunikation mellem virksomheder, anbefaler vi, at du angiver et underdomæne til virksomhedsdomænet som SIP-destination i Control Hub og dermed en offentlig DNS SRV post på følgende måde:

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

Business-to-business-, mobil- Remote Access og Webex-trafik på det samme Expressway-par

Business-to-Business (B2B) og Mobile og Remote Access (MRA) opkald bruger port 5061 til SIP TLS, og Webex-trafik bruger port 5062 til SIP TLS med gensidig godkendelse.

Kontrol af domæneejerskab er en del af identitetsbekræftelsen. Domænebekræftelse er en sikkerhedsforanstaltning og identitetskontrol, som Webex-skyen implementerer for at bevise, at du er den, du siger, du er.

Identitetskontrollen udføres i to faser:

1. Kontrol af domæneejerskab. Dette trin involverer tre typer domæner og er en engangsverifikationskontrol:

   • E-mail-domæne

   • Expressway-E DNS-domæne

   • Directory URI-domæne

2. Expressway-E DNS-ejerskabskontrol. Dette trin udføres gennem implementering af TLS med gensidig godkendelse og involverer brug af offentlige certifikater på både skyen og Expressway. I modsætning til domæneidentitetskontrollen udføres dette trin under ethvert opkald, der foretages til og modtages fra skyen.

Betydningen af domæneejerkontrollen

Webex-skyen udfører kontrollen af domæneejerskab for at håndhæve sikkerheden. Identitetstyveri er en mulig trussel, hvis denne kontrol ikke udføres.

Følgende historie beskriver, hvad der kan ske, hvis en domæneejerkontrol ikke udføres.

Et firma med DNS-domæne indstillet til „hacker.com“ køber Webex Hybrid Services. En anden virksomhed, med sit eget domæne indstillet til „example.com“, bruger også hybridtjenester. En af administrerende direktører i virksomheden Example.com hedder Jane Roe og har kataloget URI jane.roe@example.com.

Administratoren af Hacker.com-firmaet sætter en af hendes katalogURI'er til jane.roe@example.com og e-mail-adressen til jane.roe@hacker.com. Hun kan gøre det, fordi skyen ikke kontrollerer SIP URI-domænet i dette eksempel.

Derefter logger hun på Webex App med jane.roe@hacker.com. Da hun ejer domænet, læses og besvares bekræftelsesmailen, og hun kan logge på. Endelig ringer hun til en kollega, John Doe, ved at ringe til john.doe@example.com fra sin Webex-app. John sidder på sit kontor og ser et opkald på sin videoenhed, der kommer fra jane.roe@example.com; det er den mappe URI, der er knyttet til den e-mail-konto.

„Hun er i udlandet,“ tænker han. „Hun har måske brug for noget vigtigt.“ Han svarer på telefonen, og den falske Jane Roe beder om vigtige dokumenter. Hun forklarer, at hendes enhed er gået i stykker, og fordi hun er på rejse, beder hun ham om at sende dokumenterne til sin private e-mail-adresse, jane.roe@hacker.com. På denne måde indser virksomheden først, efter at Jane Roe kommer tilbage til kontoret, at vigtige oplysninger blev lækket uden for virksomheden.

Virksomheden Example.com har mange måder at beskytte mod falske opkald, der kommer fra Internettet, men et af Webex-skyens ansvar er at sikre, at identiteten på enhver, der ringer fra Webex, er korrekt og ikke forfalsket.

For at kontrollere identiteten kræver Webex, at virksomheden beviser, at den ejer de domæner, der bruges i Hybrid Calling. Hvis det ikke gør det, fungerer Hybrid Services ikke.

For at sikre dette ejerskab kræves de to domænebekræftelsestrin:

1. Bevis, at virksomheden ejer e-mail-domænet, Expressway-E-domænet, Directory URI-domæne.

   • Alle disse domæner skal kunne dirigeres og kendes af offentlige DNS-servere.

   • For at bevise ejerskabet skal DNS-administratoren angive en DNS-tekstpost (TXT). En TXT-post er en type ressourcepost i DNS, der bruges til at give mulighed for at knytte vilkårlig og uformateret tekst til en vært eller et andet navn.

   • DNS-administratoren skal indtaste denne TXT-post i den zone, hvis ejerskab skal bevises. Efter dette trin udfører Webex-skyen en TXT-postforespørgsel for det pågældende domæne.

   • Hvis TXT-forespørgslen lykkes, og resultatet matcher det token, der blev genereret fra Webex-skyen, bekræftes domænet.

   • Som et eksempel skal administratoren bevise, at hun ejer domænet „example.com“, hvis hun ønsker, at Webex Hybrid Services skal arbejde på sit domæne.

   • Via https://admin.webex.com starter hun bekræftelsesprocessen ved at oprette en TXT-post, der matcher det token, som Webex-skyen genererede:

     

   • DNS-administratoren opretter derefter en TXT-post for dette domæne med værdien indstillet til 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, som i følgende eksempel:

     

   • På dette tidspunkt kan skyen kontrollere, at TXT-posten for domænet example.com matcher tokenet.

   • Skyen udfører et TXT DNS-opslag:

     

   • Da TXT-værdien svarer til tokenværdien, beviser dette match, at administratoren tilføjede TXT-posten for sit eget domæne til den offentlige DNS, og at hun ejer domænet.

2. Expressway-E DNS Navn ejerskabskontrol.

   • Skyen skal kontrollere, at Expressway-E har en bekræftet identitet fra en af de certifikatmyndigheder, som skyen har tillid til. Expressway-E-administratoren skal anmode om et offentligt certifikat for sin Expressway-E til en af disse certifikatmyndigheder. For at udstede certifikatet udfører certifikatmyndigheden en identitetsbekræftelsesproces baseret på en domænevalideringskontrol (for domænevaliderede certifikater) eller organisationsvalideringskontrol (for organisationsvaliderede certifikater).

   • Opkald til og fra skyen afhænger af det certifikat, der blev udstedt til Expressway-E. Hvis certifikatet ikke er gyldigt, afbrydes opkaldet.

Webex Device Connector skal kommunikere med Webex for at hybridopkald kan fungere.

Webex Device Connector er implementeret i det interne netværk, og den måde, det kommunikerer med skyen på, er via en udgående HTTPS-forbindelse - den samme type, der bruges til enhver browser, der opretter forbindelse til en webserver.

Kommunikation til Webex-skyen bruger TLS. Webex Device Connector er TLS-klienten, og Webex-skyen er TLS-serveren. Som sådan kontrollerer Webex Device Connector servercertifikatet.

Certifikatmyndigheden underskriver et servercertifikat ved hjælp af sin egen private nøgle. Alle med den offentlige nøgle kan afkode denne signatur og bevise, at den samme certifikatmyndighed har underskrevet certifikatet.

Hvis Webex Device Connector skal validere certifikatet leveret af skyen, skal det bruge den offentlige nø gle for den certifikatmyndighed, der underskrev certifikatet, til at afkode signaturen. En offentlig nøgle er indeholdt i certifikatmyndighedens certifikat. For at etablere tillid hos de certifikatmyndigheder, der bruges af skyen, skal listen over certifikater for disse certifikatautoriteter, der er tillid til, være i Webex Device Connector-tillidslageret.

Når du kommunikerer med enheder, bruger værktøjet certifikater, du angiver, du har tillid til. I øjeblikket er måden at gøre det på ved at placere dem ind [home folder]/.devicestool/certs.

Der kræves også en liste over certifikatmyndighedscertifikater for Expressway-E i krydspar ret. Expressway-E kommunikerer med Webex-skyen ved hjælp af SIP med TLS, håndhævet af gensidig godkendelse. Expressway-E har kun tillid til opkald, der kommer fra og går til skyen, hvis CN eller SAN for certifikatet præsenteret af skyen under opsætningen af TLS-forbindelsen stemmer overens med det emnenavn, der er konfigureret til DNS-zonen på Expressway („callservice.webex.com“). Certifikatmyndigheden frigiver først et certifikat efter en identitetskontrol. Ejerskabet af domænet callservice.webex.com skal bevises for at få et certifikat underskrevet. Fordi vi (Cisco) ejer dette domæne, er DNS-navnet „callservice.webex.com“ et direkte bevis på, at den eksterne peer virkelig er Webex.

kalenderforbindelse integrerer Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 via en efterligningskonto. Rollen til administration af programefterligning i Exchange gør det muligt for programmer at efterligne brugere i en organisation til at udføre opgaver på vegne af brugeren. Programmets efterligningsrolle skal konfigureres i Exchange og bruges i kalenderforbindelsen som en del af Exchange-konfigurationen på Expressway-C-grænsefladen.

Exchange-efterligningskontoen er Microsofts anbefalede metode til denne opgave. Expressway-C-administratorer behøver ikke at kende adgangskoden, fordi værdien kan indtastes i Expressway-C-grænsefladen af en Exchange-administrator. Adgangskoden vises ikke tydeligt, selvom Expressway-C-administratoren har root-adgang til Expressway-C-boksen. Adgangskoden gemmes krypteret ved hjælp af den samme legitimationskrypteringsmekanisme som andre adgangskoder på Expressway-C.

For yderligere sikkerhed skal du følge trinene i implementeringsvejledningen til Cisco Webex Hybrid Calendar Service for at aktivere TLS for at sikre EWS-forbindelser på ledningen.

For yderligere sikkerhed skal du følge trinene i Im plementer Expressway Calendar Connector for Microsoft Exchange at aktivere TLS for at sikre EWS-forbindelser på ledningen.