Expressway-C- og Expressway-E-parudrulningen giver mulighed for opkald til og fra internettet ved hjælp af teknologier til passage gennem firewall. Denne udrulning er det, der på sikker vis tager din lokale opkaldskontrol og forbinder den til Cisco 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.example.com SRV-serviceplacering:

prioritet = 10

vægtning = 10

port = 5062

svr-hostnavn = us-expe1.example.com

_sips._tcp.example.com SRV-serviceplacering:

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-fortegnelsen indeholder _sips._tcp, specificerer fortegnelsen 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 besked er nyttig på en server-til-server-forbindelse, f.eks. ved opkald, der er etableret mellem Expressway-E og Cisco WebEx-skyen. Konceptet kaldes TLS med gensidig godkendelse og er påkrævet ved integration med Cisco 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. Cisco WebEx Hybridtjenester bruger den samme SIP TLS-post, som der bruges til B2B. Med hensyn til port 5061 vil nogle andre tjenester, der ikke kan levere et TLS-klientcertifikat, ikke virke.

Business-to-business-, Mobil- og Fjernadgangs- samt Cisco WebEx-trafik på samme Expressway-par

Business-to-business- samt Mobil- og Fjernadgangsopkald bruger port 5061 til SIP TLS, og Cisco WebEx-trafik bruger port 5062 til SIP TLS med gensidig godkendelse.

Domæneejerskabskontrollen er en del af identitetsbekræftelsen. Domænebekræftelse er et sikkerhedstiltag og en identitetskontrol, som Cisco WebEx-skyen anvender til at bevise, at du virkelig er den, du siger, du er.

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.

En historie, der viser vigtigheden af domæneejerskabskontrol

Cisco WebEx-skyen udfører domæneejerskabskontrollen for at opretholde sikkerheden. 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 et DNS-domæne indstillet til "hacker.com" køber Cisco WebEx-hybridtjenester. 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.

Herefter logger hun ind på Cisco Webex Teams med jane.roe@hacker.com. Da hun ejer domænet, læses og besvares bekræftelses-e-mailen, og hun kan logge ind. Endeligt foretager hun et opkald til en kollega, John Doe, ved at ringe til john.doe@example.com fra sin Cisco Webex Teams-app. John er på sit kontor og ser et opkald på sin videoenhed, der kommer fra jane.roe@example.com; det er den register-URI, der er tilknyttet denne 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 kan beskytte sig imod bedrageriske opkald fra internettet på mange måder, men det er Cisco WebEx-skyens ansvar at sikre, at identiteten for ethvert opkald fra Cisco WebEx er korrekt og ikke er forfalsket.

For at kontrollere denne identitet kræver Cisco WebEx, at virksomheden beviser, at den ejer de domæner, der bruges ved hybridopkald. Hvis den ikke gør dette, vil ikke virke.

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 Cisco WebEx-skyen en TXT-postforespørgsel for det domæne.

   • Hvis TXT-anmodningen lykkes, og resultatet matcher den token, der blev genereret fra Cisco WebEx-skyen, bekræftes domænenavnet.

   • Som eksempel skal administratoren bevise, at hun ejer domænet "example.com", hvis hun ønsker, at Cisco WebEx-hybridtjenester skal fungere på domænet.

   • Hun begynder bekræftelsesprocessen på https://admin.webex.com ved at oprette en TXT-post, der matcher den token, som Cisco 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.

Expressway-C-forbindelseshosten skal være registreret til Cisco WebEx, for at hybridtjenester kan virke.

Expressway-C udrulles i det interne netværk, og måden, den registrerer til skyen på, er igennem en udgående HTTPS-forbindelse – den samme type, som anvendes til alle browsere som bliver forbundet til en webserver.

Registrering til og kommunikation med Cisco WebEx-skyen sker med TLS. Expressway-C er TLS-klient, og Cisco WebEx-skyen er TLS-server. Derfor kontrollerer Expressway-C 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 Expressway-C skal bekræfte certifikatet fra skyen, skal den bruge den offentlige nøgle fra den certifikatudsteder, der signerede certifikatet, til at afkode signaturen. Der findes en offentlig nøgle i certifikatet fra certifikatudstederen. For at skabe tillid til den certifikatudsteder, der bruges af skyen, skal listen over certifikater fra disse betroede certifikatudstedere være i Expresswayens tillidslager. Ved at gøre dette kan Expresswayen kontrollere, om opkaldet rent faktisk kommer fra Cisco WebEx-skyen.

Ved hjælp af manuel overførsel kan du overføre alle relevante certifikatudstedercertifikater til Expressway-C's tillidslager.

Med automatisk overførsel overfører skyen selv disse certifikater i Expressway-C's tillidslager. Vi anbefaler, at du bruger automatisk overførsel. Certifikatlisten kan ændres, så automatisk overførsel sikrer, at du får den mest opdaterede liste.

Hvis du tillader automatisk installation af certifikatudstedercertifikater, videresendes du til https://admin.webex.com (administrationsportalen). Omdirigeringen udføres af Expressway-C uden nogen brugerintervention. Som Cisco WebEx-administrator skal du godkende ved hjælp af en HTTPS-forbindelse. Kort tid efter sender skyen CA-certifikatet til Expressway-C.

HTTPS-forbindelsen kan ikke etableres, før certifikaterne er overført til Expressway-C's tillidslager.

For at undgå dette problem er der allerede installeret Cisco WebEx-betroede CA-certifikater i Expressway-C. Disse certifikater bruges kun til at konfigurere og validere den første HTTPS-forbindelse, og de vises ikke i Expressway-C's tillidsliste. Når de betroede certifikatudstederes certifikater hentes fra skyen igennem denne første HTTPS-forbindelse, er disse certifikater tilgængelige til brug på tværs af hele platformen; derefter er de synlige i Expressway-C's tillidsliste.

Denne liste viser de certifikatudstedercertifikater, som Cisco WebEx-skyen i øjeblikket bruger. Denne liste kan blive ændret i fremtiden:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Klasse 2-certifikatudsteder

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Rodcertifikatudsteder - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - Kun til autoriseret brug, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Klasse 3 Offentlig, primær certifikatudsteder

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

Kalendertilslutter integrerer Cisco WebEx med Microsoft Exchange 2010, 2013, 2016 eller Office 365 igennem en personifikationskonto. 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. Programpersonifikationsrollen skal konfigureres i Exchange og bruges i Kalendertilslutter som del af Exchange-konfigurationen på Expressway-C-brugergrænsefladen.

Exchange-personifikationskontoen 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 i krypteret tilstand med den samme mekaniske metode til kryptering af legitimationsoplysninger, som bruges til andre adgangskoder, på 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.