Dette afsnit indeholder tilføjet kontekst om vigtige konfigurationspunkter, der er relateret til hybrid-tjenester.

Disse punkter er afgørende, hvis du vil udrulle hybridopkald til Webex-enheder. Vi har fremhævet disse elementer af følgende grunde:

• Vi vil forklare dem, så du forstår deres rolle i en hybridudrulning og føler dig forsikret.

• Det er obligatoriske forudsætninger, der giver en sikker udrulning mellem vores sky og dit lokale miljø.

• De skal behandles som før-dag-nul-aktiviteter: Det kan tage lidt længere tid at gennemføre dem end typiske konfigurationer på en brugergrænseflade, så planlæg tid til at få disse elementer ordnet.

• Når disse elementer er blevet behandlet i dit miljø, vil resten af din konfiguration af hybrid-tjenester gå gnidningsløst.

Expressway-C- og Expressway-E-parinstallationen tillader opkald til og fra internettet ved hjælp af teknologier til passage gennem firewall. Denne udrulning er det, der sikkert tager din lokale opkaldskontrol og knytter den til Webex.

Expressway-C og Expressway-E kræver ingen åbning af den indgående port i den demilitariserede zone-firewall (DMZ) på grund af arkitekturen for passage gennem firewall. TCP SIP-signalporte og UDP-medieporte skal dog være åbne for indgående på internetfirewallen, så indgående opkald kan gå igennem. Du skal give tid til, at de korrekte porte kan blive åbnet i din virksomheds firewall.

Arkitekturen for passage gennem firewall er vist i følgende diagram:

For eksempel i forbindelse med indgående business-to-business-opkald (B2B) med SIP-protokol skal TCP-portene 5060 og 5061 (5061 bruges til SIP TLS) åbnes på den eksterne firewall sammen med UDP-medieporte, der bruges til tjenester som tale, video, deling af indhold, dobbelt video og så videre. Hvilke medieporte, der skal åbnes, afhænger af antallet af samtidige opkald og antallet af tjenester.

Du kan konfigurere SIP-lytteporten på Expressway til en værdi mellem 1024 til 65534. Samtidig skal denne værdi og protokoltypen være annonceret i den offentlige DNS SRV-post, og den samme værdi skal være åbnet på internetfirewallen.

Selv om standarden for SIP TCP er 5060 og for SIP TLS er 5061, er der intet, der forhindrer brugen af forskellige porte, hvilket følgende eksempel viser.

Eksempel

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

DNS SRV-posten for en klynge med to Expressway-servere ser således ud:

_sips._tcp.eksempel.com SRV-tjenesteplacering:

prioritet = 10

vægtning = 10

port = 5062

svr-hostnavn = us-expe1.example.com

_sips._tcp.eksempel.com SRV-tjenesteplacering:

prioritet = 10

vægtning = 10

port = 5062

svr-hostnavn = us-expe2.example.com

Disse poster betyder, at opkald sendes til us-expe1.example.com og us-expe2.example.com med samme belastningsdeling (prioritet og vægtning) med TLS som transporttype og 5062 som lytteport.

En enhed, der er ekstern for netværket (på internettet), og som foretager et SIP-opkald til en bruger af virksomhedens domæne (user1@example.com), skal spørge DNS for at finde ud af, hvilken transporttype der skal bruges, portnummeret, hvordan den skal belastningsdele trafikken, og hvilke SIP-servere opkaldet skal sendes til.

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

TLS er en klientserverprotokol og bruger certifikater til godkendelse i forbindelse med de fleste almindelige implementeringer. I et business-to-business-opkaldsscenarie er TLS-klienten den enhed, der ringes fra, og TLS-serveren er den enhed, der ringes til. Med TLS kontrollerer klienten serverens certifikat, og, hvis certifikatkontrollen mislykkes, afbryder den opkaldet. Klienten behøver ikke et certifikat.

TLS-håndtrykket vises i følgende diagram:

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

Både den, der ringer, og den modtagende part kontrollerer certifikatet fra den anden person, som det følgende diagram viser det:

Skyen kontrollerer Expressway-identiteten, og Expressway kontrollerer skyens identitet. Hvis skyidentiteten i certifikatet (CN eller SAN) for eksempel ikke matcher med konfigurationen på Expressway, afbrydes forbindelsen.

Hvis gensidig godkendelse er aktiveret, anmoder Expressway-E altid om klientcertifikatet. Som et resultat deraf vil Mobil- og Fjernadgang (MRA) ikke fungere, da certifikater i de fleste tilfælde ikke er udrullet på Jabber-klienter. I et business-to-business-scenarie, hvor enheden, der ringes fra, ikke er i stand til at levere et certifikat, afbrydes opkaldet.

Vi anbefaler, at du bruger en anden værdi end 5061 til TLS med gensidig godkendelse, f.eks. port 5062. Webex Hybrid-tjenester bruger den samme SIP TLS-post, der bruges til B2B. Med hensyn til port 5061 vil nogle andre tjenester, der ikke kan levere et TLS-klientcertifikat, ikke virke.

Hvis en eksisterende post allerede bruges til virksomhed-til-virksomhed-kommunikation, anbefaler vi, at du angiver et underdomæne af virksomhedsdomænet som SIP-destination i Control Hub og dermed en offentlig DNS SRV-post som følger:

 Tjeneste og protokol: _sips._tcp.mtls.example.com Prioritet: 1 vægt: 10 Portnummer: 5062 Mål: us-expe1.eksempel.com 

Virksomhed-til-virksomhed, mobil- og fjernadgang og Webex-trafik på det samme Expressway-par

Business-to-business-opkald (B2B) og mobil og fjernadgang (MRA) bruger port 5061 til SIP TLS, og Webex-trafik bruger port 5062 til SIP TLS med gensidig godkendelse.

Domæneejerskabskontrollen er en del af identitetsbekræftelsen. Domænebekræftelse er en sikkerhedsforanstaltning og identitetskontrol, som Webex Cloud implementerer for at bevise, at du er den, du udgiver dig.

Identitetskontrollen udføres i to trin:

1. Kontrol af domæneejerskab. Dette trin omfatter tre typer af domæner og er en enkeltstående bekræftelseskontrol:

   • Gør krav på domæne

   • Expressway-E DNS-domæne

   • Register-URI-domæne

2. Expressway-E DNS-navneejerskabskontrol. Dette trin udføres igennem implementering af TLS med gensidig godkendelse og involverer brug af offentlige certifikater for både skyen og Expresswayen. I modsætning til domæneidentitetskontrollen udføres dette trin under alle opkald til og fra skyen.

Betydningen af kontrol af domæneejerskab

Webex Cloud udfører kontrol af domæneejerskab for at håndhæve sikkerhed. Identitetstyveri er blot én mulig trussel, hvis denne kontrol ikke udføres.

Denne historie beskriver, hvad der kan ske, hvis der ikke udføres en domæneejerskabskontrol.

En virksomhed med DNS-domæne indstillet til "hacker.com" køber Webex-hybrid-tjenester. En anden virksomhed, hvis eget domæne er indstillet til "example.com", bruger også hybridtjenester. Én af virksomheden Example.com's direktører hedder Jane Roe og har register-URI'en jane.roe@example.com.

Administratoren fra virksomheden Hacker.com angiver én af sine register-URI'er som jane.roe@example.com og e-mailadressen som jane.roe@hacker.com. Det er hun i stand til at gøre, fordi skyen i dette eksempel ikke kontrollerer SIP URI-domænet.

Derefter logger hun ind på Webex-appen med jane.roe@hacker.com. Da hun ejer domænet, læses og besvares bekræftelses-e-mailen, og hun kan logge ind. 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 tilknyttet den e-mailkonto.

"Hun er i udlandet," tænker han. "Det kan være, hun har brug for noget vigtigt." Han tager telefonen, og den falske Jane Roe beder om vigtige dokumenter. Hun fortæller, at hendes enhed er gået i stykker, og fordi hun er på rejse, beder hun ham om at sende dokumenterne til hendes personlige e-mailadresse jane.roe@hacker.com. På den måde opdager virksomheden kun, at der er blevet lækket vigtige oplysninger til uden for virksomheden, efter at Jane Roe kommer tilbage til kontoret.

Virksomheden Example.com har mange måder at beskytte mod svigagtige opkald, der kommer fra internettet, men et af Webex-skyens ansvar er at sikre, at identiteten på alle, 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 hybridopkald. Hvis den ikke gør, fungerer hybridtjenester ikke.

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

1. Bevis, at virksomheden ejer e-maildomænet, Expressway-E-domænet og register-URI-domænet.

   • Alle disse domæner skal kunne routes og være kendt af offentlige DNS-servere.

   • For at bevise ejerskabet skal DNS-administratoren indtaste en DNS-txt-post (TXT). En TXT-post er en type ressourcepost i DNS'en, der bruges til at gøre det muligt at knytte vilkårlig, uformateret tekst til en host eller et andet navn.

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

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

   • Administratoren skal f.eks. bevise, at hun ejer domænet "example.com", hvis hun ønsker, at Webex-hybrid-tjenester skal fungere på sit domæne.

   • Gennem 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 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, som i følgende eksempel:

     

   • På dette tidspunkt kan skyen bekræfte, at TXT-posten for domænet example.com matcher med denne token.

   • Skyen udfører et TXT DNS-opslag:

     

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

2. Expressway-E DNS-navneejerskabskontrol.

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

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

Webex-enhedskonnektoren skal kommunikere med Webex, for at hybridopkald kan fungere.

Webex-enhedskonnektoren er installeret på det interne netværk, og den måde, den 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 Cloud bruger TLS. Webex-enhedskonnektoren er TLS-klienten, og Webex Cloud er TLS-serveren. Derfor kontrollerer Webex Device Connector servercertifikatet.

Certifikatudstederen signerer et servercertifikat ved brug af sin egen private nøgle. Alle, der har den offentlige nøgle, kan afkode signaturen og bevise, at den samme certifikatudsteder har signeret den.

Hvis Webex Device Connector skal validere certifikatet, der leveres af skyen, skal den bruge den offentlige nøgle fra den certifikatmyndighed, der har signeret certifikatet, til at afkode signaturen. Der findes en offentlig nøgle i certifikatet fra certifikatudstederen. For at oprette tillid til de certifikatmyndigheder, der bruges af skyen, skal listen over certifikater for disse pålidelige certifikatmyndigheder være i Webex Device Connector-tillidslageret.

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

Der kræves også en liste over certifikatudstedercertifikater for Expressway-E i passageparret. Expressway-E kommunikerer med Webex-skyen ved hjælp af SIP med TLS, der håndhæves ved hjælp af gensidig godkendelse. Expressway-E stoler kun på opkald, der kommer fra og går til skyen, hvis CN eller SAN for det certifikat, der præsenteres af skyen under opsætning af TLS-forbindelse, matcher det emnenavn, der er konfigureret for DNS-zonen på Expressway ("callservice.webex.com"). Certifikatudstederen frigiver kun et certifikat efter en identitetskontrol. Ejerskabet af domænet callservice.webex.com skal dokumenteres for at få et certifikat signeret. Da vi (Cisco) ejer dette domæne, er DNS-navnet "callservice.webex.com" direkte bevis på, at den eksterne peer virkelig er Webex.

kalendertilslutter integrerer Webex med Microsoft Exchange 2013, 2016, 2019 eller Office 365 igennem en personefterligningskonto. Programpersonifikationsstyringsrollen i Exchange giver programmer mulighed for at udgive sig for at være brugere i en organisation, så de kan udføre opgaver på vegne af brugeren. Programpersoningsrollen skal konfigureres i Exchange og bruges i kalendertilslutningen som en del af Exchange-konfigurationen på Expressway-C-grænsefladen.

Exchange-repræsentationskontoen er Microsofts anbefalede metode til denne opgave. Expressway-C-administratorer behøver ikke at kende adgangskoden, da værdien kan indtastes i Expressway-C-grænsefladen af en Exchange-administrator. Adgangskoden vises ikke tydeligt, selv hvis -Expressway-C-administratoren har rodadgang til Expressway-C-boksen. Adgangskoden gemmes krypteret ved hjælp af den samme mekanisme til kryptering af legitimationsoplysninger som andre adgangskoder Expressway-C.

For yderligere sikkerhed skal du følge trinnene i Installationsvejledning til Cisco Webex-hybrid-kalendertjeneste for at aktivere TLS med henblik på at sikre EWS-forbindelser på ledningen.

For yderligere sikkerhed skal du følge trinnene i Implementer Expressway til Microsoft Exchange for at aktivere TLS med henblik på at sikre EWS-forbindelser på ledningen.