Du har kanskje problemer med å distribuere Cisco Webex-hybridtjenester i miljøet ditt. Eller du vil kanskje bare få en bedre forståelse av noen designmessige hensyn. Denne artikkelen kan fungere som en sjekkliste for å hjelpe deg med å forstå viktige hybridelementer, for eksempel brannmurhensyn, sertifikatmyndigheter og domeneeierskap.
Denne delen gir ekstra kontekst om viktige konfigurasjonselementer som er relatert til Cisco Webex-hybridtjenester.
Disse punktene er avgjørende hvis du vil distribuere Expressway-driftede Cisco Webex-hybridtjenester, for eksempel hybridsamtaletjenesten Aware/Connect og hybridkalendertjeneste. Vi har fremhevet disse elementene av følgende årsaker:
Vi ønsker å forklare dem, slik at du forstår rollen de har i en hybriddistribusjon, og slik at du føler deg trygg.
De er obligatoriske forutsetninger som sikrer en sikker distribusjon mellom skyen vår og det lokale miljøet ditt.
De bør behandles som aktiviteter før dag null: Det kan ta litt lengre tid å fullføre disse enn vanlig konfigurasjon i et brukergrensesnitt, så planlegg litt tid for å ordne disse elementene.
Etter at disse elementene har blitt ordnet i miljøet ditt, vil resten av konfigurasjonen av Cisco Webex-hybridtjenester gå problemfritt.
Distribusjon av Expressway-C og Expressway-E tillater anrop til og fra nettbasert teknologi for brannmurtraversering. Denne distribusjonen tar lokal anropskontroll på en sikker måte og knytter den til Cisco Webex.
Expressway-C og Expressway-E krever ikke at noen innkommende port åpnes i den demilitariserte sonen (DMZ) av brannmuren på grunn av brannmurtraverseringsarkitekturen. Men TCP SIP-signalporter og UDP-medieporter må åpnes innkommende på Internett-brannmuren for å la innkommende anrop komme gjennom. Du må gi tid til at den riktige porten skal åpnes i bedriftsbrannmuren.
For innkommende bedrift-til-bedrift-anrop (B2B) som bruker SIP-protokoll, må for eksempel TCP-port 5060 og 5061 (5061 brukes til SIP TLS) åpnes på den eksterne brannmuren, sammen med UDP-medieporter som brukes til tjenester som tale, video, innholdsdeling, dobbel video og så videre. Hvilke medieporter som skal åpnes, avhenger av antall samtidige anrop og antall tjenester.
Du kan konfigurere SIP-lytteporten på Expressway til en hvilken som helst verdi mellom 1024 og 65534. Samtidig må denne verdien og protokolltypen annonseres i de offentlige DNS SRV-postene, og den samme verdien må åpnes på Internett-brannmuren.
Selv om standarden for SIP TCP er 5060 og den er 5061 for SIP TLS, er det ingenting som hindrer bruk av forskjellige porter, som følgende eksempel viser.
- Eksempel
-
I dette eksemplet antar vi at port 5062 brukes til innkommende SIP TLS-anrop.
DNS SRV-posten for en klynge med to Expressway-servere ser slik ut:
- _sips._tcp.example.com SRV-tjenestested:
-
prioritet = 10
vekt = 10
port = 5062
svr vertsnavn = us-expe1.example.com
- _sips._tcp.example.com SRV-tjenestested:
-
prioritet = 10
vekt = 10
port = 5062
svr vertsnavn = us-expe2.example.com
Disse postene betyr at samtaler rettes mot us-expe1.example.com og us-expe2.example.com med lik belastningsdeling (prioritet og vekt) ved hjelp av TLS som transporttype og 5062 som lytteportnummer.
En enhet som er ekstern for nettverket (på Internett), og som foretar et SIP-anrop til en bruker av bedriftsdomenet (user1@example.com), må spørre DNS for å forstå hvilken transporttype som skal brukes, portnummeret, hvordan trafikken skal lastes inn og hvilke SIP-servere den skal sende anropet til.
Hvis DNS-oppføringen inneholder _sips._tcp angir oppføringen SIP TLS.
TLS er en klient-/serverprotokoll, og bruker i de vanligste implementeringene sertifikater til godkjenning. I et bedrift-til-bedrift-anropsscenario er TLS-klienten oppringningsenheten, og TLS-serveren er enheten som ble oppringt. Klienten bruker TLS til å kontrollere sertifikatet til serveren, og hvis sertifikatkontrollen mislykkes, kobler den fra anropet. Klienten trenger ikke et sertifikat.
TLS-spesifikasjonen angir imidlertid at serveren også kan kontrollere klientsertifikatet ved å sende en sertifikatforespørselsmelding til klienten under TLS-håndtrykkprotokollen. Denne meldingen er nyttig på en server-til-server-tilkobling, for eksempel ved oppringing som er opprettet mellom Expressway-E og Cisco Webex-skyen. Dette konseptet kalles TLS med gjensidig godkjenning og kreves for integrering med Cisco Webex.
Skyen kontrollerer Expressway-identiteten, og Expressway kontrollerer skyidentiteten. Hvis for eksempel skyidentiteten i sertifikatet (CN eller SAN) ikke samsvarer med det som er konfigurert på Expressway, brytes tilkoblingen.
Hvis gjensidig godkjenning er aktivert, ber Expressway-E alltid om klientsertifikatet. Som et resultat vil ikke Mobile and Remote Access (MRA) fungere, fordi sertifikater i de fleste tilfeller ikke distribueres på Jabber-klienter. Hvis oppringingsenheten ikke kan angi et sertifikat i et bedrift-til-bedrift-scenario, frakobles samtalen.
Vi anbefaler at du bruker en annen verdi enn 5061 for TLS med gjensidig godkjenning, for eksempel port 5062. Cisco Webex-hybridtjenester bruker samme SIP TLS-post som brukes for B2B. For port 5061 vil noen andre tjenester som ikke kan tilby et TLS-klientsertifikat, ikke fungere.
Bedrift-til-bedrift, Mobile and Remote Access og Cisco Webex-trafikk på samme Expressway-par
Anrop bedrift-til-bedrift og Mobile and Remote Access bruker port 5061 for SIP TLS, og Cisco Webex-trafikk bruker port 5062 for SIP TLS med gjensidig godkjenning.
Domeneeierskap er en del av identitetsbekreftelsen. Domenebekreftelse er et sikkerhetstiltak og identitetskontroll som Cisco Webex-skyen implementerer for å bevise at du er den du utgir deg som.
Identitetskontrollen utføres i to trinn:
Kontroll av domeneeierskap. Dette trinnet involverer tre typer domener og er en éngangs verifiseringskontroll:
E-postdomene
DNS-domene for Expressway-E
Domene for katalog-URI
Eierskapskontroll av Expressway-E DNS-navn. Dette trinnet utføres gjennom implementering av TLS med gjensidig godkjenning og innebærer bruk av offentlige sertifikater på både skyen og Expressway. I motsetning til domeneidentitetskontrollen utføres dette trinnet under alle oppringinger som foretas til og mottas fra skyen.
En historie som viser viktigheten av domeneeierskap
Cisco Webex-skyen utfører domeneeierskapet for å håndheve sikkerheten. Identitetstyveri er en mulig trussel hvis denne kontrollen ikke utføres.
Følgende artikkel beskriver hva som kan skje hvis en domeneeierkontroll ikke utføres.
En bedrift med DNS-domene satt til hacker.com kjøper Cisco Webex-hybridtjenester. Et annet selskap med domenet example.com bruker også hybridtjenester. En av de daglige lederne i selskapet Example.com heter Jane Roe og har katalog-URI-en jane.roe@example.com.
Administratoren for selskapet Hacker.com angir en av katalog-URI-ene sine som jane.roe@example.com og e-postadressen sin som jane.roe@hacker.com. Hun kan gjøre dette fordi skyen ikke sjekker SIP URI-domenet i dette eksemplet.
Deretter logger hun på Cisco Webex Teams med jane.roe@hacker.com. Fordi hun eier domenet, leses og besvares bekreftelses-e-posten, og hun kan logge på. Til slutt ringer hun en kollega – John Doe – ved å ringe opp john.doe@example.com fra Cisco Webex Teams-appen. John sitter på kontoret sitt og ser et anrop på videoenheten sin fra jane.roe@example.com. Dette er katalog-URI-en som er tilknyttet med denne e-postkontoen.
«Hun er i utlandet», tenker han. «Hun trenger kanskje noe viktig.» Han svarer på telefonen, og den falske Jane Roe ber om viktige dokumenter. Hun forklarer at enheten hennes er ødelagt, og fordi hun er på reise, ber hun ham om å sende dokumentene til sin private e-postadresse, jane.roe@hacker.com. På denne måten vil ikke selskapet oppdage at viktig informasjon ble lekket utenfor selskapet, før etter at Jane Roe kommer tilbake til kontoret.
Selskapet Example.com har mange metoder for å beskytte seg mot falske anrop som kommer fra Internett, men et av ansvarsområdene til Cisco Webex-skyen er å kontrollere at identiteten til alle som ringer fra Cisco Webex, er riktig og ikke forfalsket.
For å kunne kontrollere identiteten krever Cisco Webex at selskapet beviser at det eier domenene som brukes i hybridsamtaler. Hvis det ikke gjør det, vil det ikke fungere.
For å sikre dette eierskapet kreves totrinns domeneverifisering:
Bevis at selskapet eier e-postdomenet, Expressway-E-domenet, katalog-URI-domenet.
Alle disse domenene må være rutbare og kjent av offentlige DNS-servere.
DNS-administratoren må angi en DNS-tekstpost (TXT) for å bevise eierskapet. En TXT-post er en type ressurspost i DNS som brukes til å gi deg muligheten til å knytte vilkårlig og uformatert tekst til en vert eller et annet navn.
DNS-administratoren må angi TXT-posten i sonen der eierskapet må bevises. Etter dette trinnet, utfører Cisco Webex-skyen en TXT-postspørring for dette domenet.
Hvis TXT-spørringen er vellykket og resultatet samsvarer med tokenet som ble generert fra Cisco Webex-skyen, bekreftes domenet.
Som et eksempel må administratoren bevise at hun eier domenet «example.com», hvis hun vil at Cisco Webex-hybridtjenester skal fungere på domenet sitt.
- Gjennom https://admin.webex.com starter hun bekreftelsesprosessen ved å opprette en TXT-post som samsvarer med tokenet som Cisco Webex-skyen genererte:
- DNS-administratoren oppretter deretter en TXT-post for dette domenet med verdien satt til 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, som i følgende eksempel:
På dette tidspunktet kan skyen bekrefte at TXT-posten for domenet example.com samsvarer med tokenet.
- Skyen utfører et TXT DNS-oppslag:
Fordi TXT-verdien samsvarer med tokenverdien, beviser dette treffet at administratoren la til TXT-posten for sitt eget domene i den offentlige DNS-en, og at hun eier domenet.
Eierskapskontroll av Expressway-E DNS-navn.
Skyen må kontrollere at Expressway-E har en bekreftet identitet fra en av sertifikatmyndighetene som skyen stoler på. Expressway-E-administratoren må be om et offentlig sertifikat for sin Expressway-E til en av disse sertifikatmyndighetene. Sertifikatmyndigheten utfører en identitetsbekreftelsesprosess basert på en domenevalideringskontroll (for domenevaliderte sertifikater) eller organisasjonsvalideringskontroll (for organisasjonsvaliderte sertifikater) for å utstede sertifikatet.
Anrop til og fra skyen avhenger av sertifikatet som ble utstedt til Expressway-E. Hvis sertifikatet ikke er gyldig, avsluttes samtalen.
Expressway-C-kontaktverten må være registrert på Cisco Webex for at hybridtjenester skal fungere.
Expressway-C distribueres i det interne nettverket, og måten den registrerer seg i skyen på, er gjennom en utgående HTTPS-tilkobling – samme type som brukes for alle nettlesere som kobler til en webserver.
Registrering og kommunikasjon til Cisco Webex-skyen bruker TLS. Expressway-C er TLS-klienten, og Cisco Webex-skyen er TLS-serveren. Dermed kontrollerer Expressway-C serversertifikatet.
Sertifikatmyndigheten signerer et serversertifikat ved hjelp av sin egen privatnøkkel. Alle med den offentlige nøkkelen kan dekode signaturen og bevise at den samme sertifikatmyndigheten signerte sertifikatet.
Hvis Expressway-C må validere sertifikatet fra skyen, må den offentlige nøkkelen for sertifikatmyndigheten som signerte sertifikatet, brukes til å dekode signaturen. Sertifikatet for sertifikatmyndigheten inneholder en offentlig nøkkel. Hvis du vil klarere med sertifikatmyndighetene som brukes av skyen, må listen over sertifikater for disse klarerte sertifikatmyndighetene være i klareringslageret for Expressway. Ved å gjøre dette kan Expressway bekrefte at anropet virkelig kommer fra Cisco Webex-skyen.
Med manuell opplasting kan du laste opp alle relevante sertifikater fra sertifikatmyndigheter til klareringslageret til Expressway-C.
Med automatisk opplasting laster selve skyen opp disse sertifikatene i klareringslageret til Expressway-C. Vi anbefaler at du bruker automatisk opplasting. Sertifikatlisten kan endres, og automatisk opplasting garanterer at du får den mest oppdaterte listen.
Hvis du tillater automatisk installasjon av sertifikater fra sertifikatmyndigheter, omdirigert til https://admin.webex.com (administrasjonsportalen). Omadresseringen gjøres av Expressway-C selv uten brukermedvirkning. Du, som Cisco Webex-administrator, må godkjenne via en HTTPS-tilkobling. Kort tid etter skyver skyen CA-sertifikatene til Expressway-C.
Før sertifikatene lastes opp til klareringslageret for Expressway-C, kan ikke HTTPS-tilkoblingen opprettes.
For å unngå dette problemet er Expressway-C forhåndsinstallert med Cisco Webex-klarerte CA-sertifikater. Disse sertifikatene brukes bare til å konfigurere og validere den første HTTPS-tilkoblingen, og de vises ikke i klareringslisten for Expressway-C. Når sertifikatene til de klarerte sertifikatmyndighetene hentes fra skyen gjennom denne første HTTPS-tilkoblingen, er disse sertifikatene tilgjengelige for bruk over hele plattformen. Deretter vises de i klareringslisten for Expressway-C.
Krever administratortilgang til Expressway-C og til https://admin.webex.com. Disse tilkoblingene bruker HTTPS og er kryptert.
Sertifikater skyves fra skyen til Expressway ved hjelp av den samme krypterte tilkoblingen.
Denne listen viser sertifikatene for sertifikatmyndigheter som Cisco Webex-skyen bruker for øyeblikket. Denne listen kan endres 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 Class 2 Certificate Authority
C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - 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. - For authorized use only, CN=thawte Primary Root CA
C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority
Det kreves også en liste over sertifiseringsinstanssertifikater for Expressway-E i traverseringsparet. Expressway-E kommuniserer med Cisco Webex-skyen ved hjelp av SIP med TLS, håndhevet av gjensidig autentisering. Expressway-E klarerer samtaler som kommer fra og går til skyen, bare hvis tilkoblede nettverk eller SAN for sertifikatet som presenteres av skyen under TLS-tilkoblingsoppsettet, samsvarer med emnenavnet som er konfigurert for DNS-sonen på Expressway (callservice.ciscospark.com). Sertifikatmyndigheten vil bare frigi et sertifikat etter en identitetskontroll. Eierskapet til domenet callservice.ciscospark.com må bevises for at et sertifikat skal signeres. Fordi vi (Cisco) eier dette domenet, er DNS-navnet callservice.ciscospark.com direkte bevis på at den eksterne datamaskinen virkelig er Cisco Webex.
Kalendertilkobling integrerer Cisco Webex med Microsoft Exchange 2010, 2013, 2016 eller Office 365 via en representasjonskonto. Administrasjonsrollen for programrepresentasjon i Exchange gjør det mulig for programmer å representere brukere i en organisasjon for å utføre oppgaver på vegne av brukeren. Programrepresentasjonsrollen må konfigureres i Exchange og brukes i kalendertilkobling som en del av Exchange-konfigurasjonen på Expressway-C-grensesnittet.
Exchange-representasjonskontoen er Microsofts anbefalte metode for denne oppgaven. Expressway-C-administratorer trenger ikke å vite passordet, fordi verdien kan angis i Expressway-C-grensesnittet av en Exchange-administrator. Passordet vises ikke, selv om Expressway-C-administratoren har rottilgang til Expressway-C-boksen. Passordet krypteres og lagres med samme krypteringsmekanisme for legitimasjon som andre passord på Expressway-C.
Hvis du vil ha mer sikkerhet, følger du fremgangsmåten i distribusjonsveiledningen for hybridkalendertjenesten for Cisco Webex for å aktivere TLS for å sikre fysiske EWS-tilkoblinger.
