Tässä osiossa annetaan lisätietoa hybridipalveluihin liittyvistä tärkeimmistä määrityskohteista.

Nämä seikat ovat ratkaisevia, jos haluat ottaa Hybrid Callingin onnistuneesti käyttöön Webex-laitteissa. Olemme korostaneet näitä kohteita erityisesti seuraavista syistä:

• Haluamme selittää ne, jotta ymmärrät niiden roolin hybridikäytössä ja voit olla varma niistä.

• Ne ovat pakollisia edellytyksiä, jotka varmistavat turvallisen käyttöönoton pilvipalvelumme ja toimitilaympäristösi välillä.

• Niitä olisi käsiteltävä nollapäivää edeltävinä toimintoina: niiden tekeminen voi kestää hieman kauemmin kuin tyypillisen käyttöliittymän määrityksen tekeminen, joten varaa aikaa näiden kohteiden selvittämiseen.

• Kun nämä asiat on ratkaistu ympäristössäsi, loput Hybrid Services -määrityksestä sujuvat ongelmitta.

Expressway-C- ja Expressway-E-parin käyttöönotto mahdollistaa puhelut Internetiin ja Internetistä käyttäen palomuurin ylitystekniikoita. Tämä käyttöönotto ottaa turvallisesti tiloissa olevan puhelunohjauksen ja liittää sen Webexiin.

Expressway-C ja Expressway-E eivät vaadi minkään saapuvan portin avaamista DMZ-palomuurissa (demilitarisoitu vyöhyke) palomuuriarkkitehtuurin läpäisyarkkitehtuurin vuoksi. Internetin palomuurissa on kuitenkin avattava TCP-SIP-signalointiportit ja UDP-mediaportit, jotta saapuvat puhelut pääsevät läpi. Sinun on varattava aikaa siihen, että yrityksen palomuurissa avataan asianmukainen portti.

Palomuurin läpikulkuarkkitehtuuri on esitetty seuraavassa kaaviossa:

Esimerkiksi SIP-protokollaa käyttäviä saapuvia yritysten välisiä (B2B) puheluita varten ulkoisessa palomuurissa on avattava TCP-portit 5060 ja 5061 (5061:tä käytetään SIP TLS:ää varten) sekä UDP-mediaportit, joita käytetään esimerkiksi ääni-, video-, sisällönjako- ja kaksoisvideopalveluihin. Se, mitkä mediaportit avataan, riippuu samanaikaisten puheluiden ja palvelujen määrästä.

Voit määrittää Expresswayn SIP-kuunteluportiksi minkä tahansa arvon välillä 1024-65534. Samalla tämä arvo ja protokollatyyppi on ilmoitettava julkisissa DNS SRV-tietueissa, ja sama arvo on avattava Internetin palomuurissa.

Vaikka SIP TCP:n standardi on 5060 ja SIP TLS:n 5061, mikään ei estä eri porttien käyttöä, kuten seuraava esimerkki osoittaa.

Esimerkki

Tässä esimerkissä oletamme, että porttia 5062 käytetään saapuviin SIP TLS -puheluihin.

Kahden Expressway-palvelimen muodostaman klusterin DNS SRV-tietue näyttää seuraavalta:

_sips._tcp.example.com SRV-palvelun sijainti:

prioriteetti = 10

paino = 10

portti = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV-palvelun sijainti:

prioriteetti = 10

paino = 10

portti = 5062

svr hostname = us-expe2.example.com

Nämä tietueet tarkoittavat, että puhelut ohjataan osoitteisiin us-expe1.example.com ja us-expe2.example.com yhtä suurella kuormituksen jakamisella (prioriteetti ja painoarvo) käyttäen TLS:ää siirtotyyppinä ja 5062 kuunteluportin numerona.

Verkon ulkopuolella (Internetissä) olevan laitteen, joka soittaa SIP-puhelun yrityksen verkkotunnuksen käyttäjälle (user1@example.com), on kysyttävä DNS:ltä selvittääkseen, mitä siirtotyyppiä käytetään, portin numero, miten liikenne jaetaan ja mihin SIP-palvelimiin puhelu lähetetään.

Jos DNS-merkintä sisältää _sips._tcp, merkintä määrittää SIP TLS:n.

TLS on asiakas-palvelinprotokolla, ja yleisimmissä toteutuksissa se käyttää varmenteita todennukseen. Yritysten välisessä puheluissa TLS-asiakas on kutsuva laite ja TLS-palvelin on kutsuttu laite. TLS:n avulla asiakas tarkistaa palvelimen varmenteen, ja jos varmenteen tarkistus epäonnistuu, se katkaisee puhelun. Asiakas ei tarvitse varmennetta.

TLS-kättely on esitetty seuraavassa kaaviossa:

TLS-määrittelyssä todetaan kuitenkin, että palvelin voi myös tarkistaa asiakkaan varmenteen lähettämällä asiakkaalle varmennepyyntösanoman TLS-kättelyprotokollan aikana. Tämä viesti on hyödyllinen palvelimen ja palvelimen välisessä yhteydessä, kuten Expressway-E:n ja Webex-pilven välille muodostetussa puhelussa. Tätä konseptia kutsutaan TLS:ksi, jossa on keskinäinen todennus, ja sitä tarvitaan, kun se integroidaan Webexin kanssa.

Sekä kutsuva että kutsuttu osapuoli tarkistavat toisen osapuolen varmenteen, kuten seuraavasta kuvasta käy ilmi:

Pilvi tarkistaa Expresswayn identiteetin, ja Expressway tarkistaa pilven identiteetin. Jos esimerkiksi varmenteessa oleva pilvitunniste (CN tai SAN) ei vastaa Expresswayn määrityksiä, yhteys katkeaa.

Jos keskinäinen todennus on käytössä, Expressway-E pyytää aina asiakkaan varmenteen. Tämän seurauksena Mobile and Remote Access (MRA) ei toimi, koska useimmissa tapauksissa varmenteita ei ole otettu käyttöön Jabber-asiakkaissa. Yritysten välisessä skenaariossa puhelu katkaistaan, jos kutsuva taho ei pysty toimittamaan varmentetta.

Suosittelemme, että käytät keskinäisen todennuksen sisältävälle TLS:lle muuta arvoa kuin 5061, esimerkiksi porttia 5062. Webex Hybrid Services käyttää samaa SIP TLS -tietuetta kuin B2B-palvelut. Portin 5061 tapauksessa jotkin muut palvelut, jotka eivät voi tarjota TLS-asiakasvarmenteita, eivät toimi.

Jos olemassa olevaa tietuetta käytetään jo yritysten välisessä viestinnässä, suosittelemme, että Control Hubissa määritetään SIP-kohteeksi yrityksen verkkotunnuksen aliverkkotunnus ja näin ollen julkinen DNS SRV-tietue seuraavasti:

 Palvelu ja protokolla: _sips._tcp.mtls.example.com Prioriteetti: 1 Paino: 10 Portin numero: 5062 Kohde: us-expe1.example.com 

Business-to-Business-, mobiili- ja etäyhteys- sekä Webex-liikenne samalla pikaraitiotieparilla.

Yritysten väliset (B2B) ja mobiili- ja etäkäyttöpuhelut (MRA) käyttävät porttia 5061 SIP TLS:ää varten, ja Webex-liikenne käyttää porttia 5062 SIP TLS:ää varten keskinäisellä todennuksella.

Verkkotunnuksen omistajuuden tarkistus on osa henkilöllisyyden todentamista. Verkkotunnuksen vahvistus on Webex-pilven toteuttama turvatoimenpide ja henkilöllisyyden tarkistus, jolla osoitetaan, että olet se, joka sanot olevasi.

Identiteetin tarkistus suoritetaan kahdessa vaiheessa:

1. Verkkotunnuksen omistusoikeuden tarkistus. Tähän vaiheeseen kuuluu kolmenlaisia verkkotunnuksia, ja se on kertaluonteinen tarkistus:

   • Sähköpostiosoite

   • Expressway-E DNS-verkkotunnus

   • Hakemiston URI verkkotunnus

2. Expressway-E DNS-nimen omistajuuden tarkistus. Tämä vaihe suoritetaan toteuttamalla TLS, jossa on keskinäinen todennus, ja siihen liittyy julkisten varmenteiden käyttö sekä pilvipalvelussa että Expresswayssä. Toisin kuin toimialueen identiteetin tarkistus, tämä vaihe suoritetaan jokaisen pilvipalveluun tulevan ja sieltä vastaanotettavan puhelun aikana.

Verkkotunnuksen omistajuuden tarkistuksen merkitys

Webex-pilvi suorittaa verkkotunnuksen omistajuuden tarkistuksen turvallisuuden varmistamiseksi. Identiteettivarkaus on yksi mahdollinen uhka, jos tätä tarkistusta ei tehdä.

Seuraavassa tarinassa kerrotaan, mitä voi tapahtua, jos verkkotunnuksen omistajuuden tarkistusta ei suoriteta.

Yritys, jonka DNS-verkkotunnus on "hacker.com", ostaa Webex Hybrid Services -palvelut. Toinen yritys, jonka oma verkkotunnus on "example.com", käyttää myös hybridipalveluja. Yksi Example.com-yrityksen toimitusjohtajista on nimeltään Jane Roe, ja hänellä on hakemiston URI jane.roe@example.com.

Hacker.com-yrityksen ylläpitäjä asettaa yhdeksi hakemisto-URI:ksi jane.roe@example.com ja sähköpostiosoitteeksi jane.roe@hacker.com. Hän voi tehdä sen, koska pilvi ei tarkista SIP URI -verkkotunnusta tässä esimerkissä.

Seuraavaksi hän kirjautuu Webex App -sovellukseen osoitteessa jane.roe@hacker.com. Koska hän omistaa verkkotunnuksen, vahvistussähköposti luetaan ja siihen vastataan, ja hän voi kirjautua sisään. Lopuksi hän soittaa puhelun kollegalleen John Doe:lle valitsemalla Webex-sovelluksesta john.doe@example.com. John istuu toimistossaan ja näkee videolaitteessaan puhelun, joka tulee osoitteesta jane.roe@example.com; tämä on kyseiseen sähköpostitiliin liittyvä hakemisto-URI.

"Hän on ulkomailla", hän ajattelee. "Hän saattaa tarvita jotain tärkeää." Hän vastaa puhelimeen, ja väärennetty Jane Roe pyytää tärkeitä asiakirjoja. Hän selittää, että hänen laitteensa on rikki, ja koska hän on matkoilla, hän pyytää miestä lähettämään asiakirjat yksityiseen sähköpostiosoitteeseensa, jane.roe@hacker.com. Näin yritys huomaa vasta Jane Roen palattua toimistoon, että tärkeää tietoa on vuotanut yrityksen ulkopuolelle.

Yrityksellä Example.com on monia keinoja suojautua Internetistä tulevilta vilpillisiltä puheluilta, mutta yksi Webex-pilven tehtävistä on varmistaa, että Webexistä soittavan henkilön henkilöllisyys on oikea eikä sitä väärennetä.

Identiteetin tarkistamiseksi Webex vaatii, että yritys todistaa omistavansa hybridipuheluissa käytettävät verkkotunnukset. Jos näin ei ole, Hybrid Services ei toimi.

Tämän omistajuuden varmistamiseksi tarvitaan kaksi verkkotunnuksen varmennusvaihetta:

1. Todista, että yritys omistaa sähköpostialueen, Expressway-E-verkkotunnuksen ja Directory URI -verkkotunnuksen.

   • Kaikkien näiden verkkotunnusten on oltava reititettävissä ja julkisten DNS-palvelimien tiedossa.

   • Omistajuuden todistamiseksi DNS-ylläpitäjän on annettava DNS-tekstitietue (TXT). TXT-tietue on eräänlainen DNS-resurssitietue, jota käytetään tarjoamaan mahdollisuus yhdistää jokin mielivaltainen ja muotoilematon teksti isäntään tai muuhun nimeen.

   • DNS-ylläpitäjän on syötettävä kyseinen TXT-tietue vyöhykkeeseen, jonka omistusoikeus on todistettava. Tämän vaiheen jälkeen Webex-pilvi tekee TXT-tietueiden kyselyn kyseiselle verkkotunnukselle.

   • Jos TXT-kysely onnistuu ja tulos vastaa Webex-pilvestä luotua tunnusta, verkkotunnus tarkistetaan.

   • Esimerkiksi ylläpitäjän on todistettava, että hän omistaa verkkotunnuksen "example.com", jos hän haluaa Webex Hybrid Services -palvelujen toimivan hänen verkkotunnuksessaan.

   • Hän aloittaa todentamisprosessin https://admin.webex.com kautta luomalla TXT-tietueen, joka vastaa Webex-pilven luomaa tunnusta:

     

   • DNS-ylläpitäjä luo tälle verkkotunnukselle TXT-tietueen, jonka arvoksi on asetettu 123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef, kuten seuraavassa esimerkissä:

     

   • Tässä vaiheessa pilvi voi tarkistaa, että verkkotunnuksen example.com TXT-tietue vastaa tunnusta.

   • Pilvi suorittaa TXT DNS-haun:

     

   • Koska TXT-arvo vastaa tokenin arvoa, tämä vastaavuus todistaa, että järjestelmänvalvoja on lisännyt oman verkkotunnuksensa TXT-tietueen julkiseen DNS-järjestelmään ja että hän omistaa verkkotunnuksen.

2. Expressway-E DNS-nimen omistajuuden tarkistus.

   • Pilven on tarkistettava, että Expressway-E:llä on vahvistettu henkilöllisyys joltakin varmentajalta, johon pilvi luottaa. Expressway-E:n ylläpitäjän on pyydettävä Expressway-E:lle julkinen varmenne joltakin näistä varmentajista. Varmentaja suorittaa varmenteen myöntämistä varten henkilöllisyyden todentamisprosessin, joka perustuu toimialueen validointitarkistukseen (toimialueen validoitujen varmenteiden osalta) tai organisaation validointitarkistukseen (organisaation validoitujen varmenteiden osalta).

   • Puhelut pilveen ja pilvestä riippuvat Expressway-E:lle myönnetystä varmenteesta. Jos varmenne ei ole voimassa, puhelu keskeytetään.

Webex Device Connectorin on oltava yhteydessä Webexiin, jotta Hybrid Calling toimii.

Webex Device Connector otetaan käyttöön sisäverkossa, ja se kommunikoi pilvipalvelimen kanssa lähtevän HTTPS-yhteyden kautta - samaa tyyppiä käytetään missä tahansa selaimessa, joka muodostaa yhteyden verkkopalvelimeen.

Kommunikointi Webex-pilveen käyttää TLS:ää. Webex Device Connector on TLS-asiakas ja Webex-pilvi on TLS-palvelin. Näin ollen Webex Device Connector tarkistaa palvelimen varmenteen.

Varmentaja allekirjoittaa palvelinvarmenteen omalla yksityisellä avaimellaan. Kuka tahansa, jolla on julkinen avain, voi purkaa allekirjoituksen ja todistaa, että sama varmentaja on allekirjoittanut varmenteen.

Jos Webex Device Connectorin on validoitava pilven tarjoama varmenne, sen on käytettävä varmenteen allekirjoittaneen varmentajan julkista avainta allekirjoituksen purkamiseen. Julkinen avain sisältyy varmentajan varmenteeseen. Jotta pilvipalvelun käyttämiin varmenteiden myöntäjiin voidaan luottaa, näiden luotettujen varmenteiden myöntäjien varmenteiden luettelon on oltava Webex Device Connectorin luottamussäilössä.

Kun työkalu kommunikoi laitteiden kanssa, se käyttää antamiasi luotettavia varmenteita. Tällä hetkellä se tehdään sijoittamalla ne osoitteeseen [kotikansio]/.devicestool/certs.

Luettelo varmenteiden myöntäjien varmenteista tarvitaan myös Expressway-E:n reititinparissa. Expressway-E kommunikoi Webex-pilven kanssa käyttämällä SIP:tä TLS:llä, jota vahvistetaan keskinäisellä todennuksella. Expressway-E luottaa pilvipalvelusta tuleviin ja sinne meneviin puheluihin vain, jos pilven TLS-yhteyden muodostamisen aikana esittämän varmenteen CN- tai SAN-nimi vastaa Expresswayn DNS-vyöhykkeelle määritettyä aiheen nimeä ("callservice.webex.com"). Varmentaja luovuttaa varmenteen vasta henkilöllisyystarkastuksen jälkeen. Varmenteen allekirjoittaminen edellyttää, että callservice.webex.com-verkkotunnuksen omistusoikeus on todistettu. Koska me (Cisco) omistamme kyseisen verkkotunnuksen, DNS-nimi "callservice.webex.com" on suora todiste siitä, että etäyhteys on todella Webex.

kalenteriliitin integroi Webexin Microsoft Exchange 2013, 2016, 2019 tai Office 365 -palveluun henkilöitymistilin kautta. Sovelluksen henkilöitymisen hallinta Exchange-roolin avulla sovellukset voivat esiintyä organisaation käyttäjinä ja suorittaa tehtäviä käyttäjän puolesta. Sovelluksen henkilöitymisrooli on määritettävä Exchangeen, ja sitä käytetään kalenteriliittimessä osana Expressway-C-käyttöliittymän Exchange-konfiguraatiota.

Exchange impersonation -tili on Microsoftin suosittelema menetelmä tähän tehtävään. Expressway-C-ylläpitäjien ei tarvitse tietää salasanaa, koska Exchange-ylläpitäjä voi syöttää arvon Expressway-C-käyttöliittymään. Salasanaa ei näytetä selvästi, vaikka Expressway-C:n ylläpitäjällä olisikin pääkäyttäjän oikeudet Expressway-C-laatikkoon. Salasana tallennetaan salattuna käyttäen samaa salausmekanismia kuin muutkin Expressway-C:n salasanat.

Lisäturvaa saat noudattamalla Cisco Webex Hybrid Calendar Service -palvelun Deployment Guide for Cisco Webex Hybrid Calendar Service -oppaan vaiheita TLS:n ottamiseksi käyttöön EWS-yhteyksien suojaamiseksi langan välityksellä.

Lisäturvaa varten noudata kohdan Deploy Expressway Calendar Connector for Microsoft Exchange vaiheita TLS:n ottamiseksi käyttöön EWS-yhteyksien suojaamiseksi langan välityksellä.