Tässä osiossa on lisätty konteksti keskeisistä määrityskohteista, jotka liittyvät hybridipalveluihin.

Nämä kohdat ovat ratkaisevan tärkeitä, jos haluat ottaa Hybrid Calling käyttöön Webex-laitteille onnistuneesti. Olemme korostaneet näitä kohteita erityisesti seuraavista syistä:

• Haluamme selittää ne, jotta ymmärrät heidän roolinsa hybridi-käyttöönotossa ja tunnet olosi rauhalliseksi.

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

• Niitä tulisi käsitellä päivää edeltävinä nollatoimintoina: niiden suorittaminen voi kestää hieman kauemmin kuin käyttöliittymän tyypilliset määritykset, joten anna aikataulu näiden kohteiden lajittelulle.

• Kun nämä kohteet on käsitelty ympäristössäsi, muut Hybrid Services -määritykset sujuvat sujuvasti.

Expressway-C- ja Expressway-E- parin käyttöönotto sallii puhelut Internetiin ja Internetistä palomuurin läpikulkutekniiko illa. Tämä käyttöönotto vie turvallisesti paikallisen puhelunhallinnan ja yhdistää sen Webexiin.

Expressway-C ja Expressway-E eivät vaadi saapuvan portin avaamista demilitarisoidun alueen (DMZ) palomuurissa palomuurin läpikulkuarkkitehtuurin vuoksi. Mutta TCP SIP -signalointiportit ja UDP- mediaportit on avattava saapuvilla Internet- palomuurilla, jotta saapuvat puhelut pääsevät läpi. Sinun on annettava aikaa, jotta asianmukainen portti av ataan yrityksen palomuurissa.

Palomuurin läpikulkuarkkitehtuuri on esitetty seuraavassa kaaviossa:

Esimerkiksi SIP-protokollaa käyttävissä saapuvissa B2B-puheluissa TCP-portit 5060 ja 5061 (5061 käytetään SIP TLS: ssä) on avattava ulkoisessa palomuurissa yhdessä UDP-mediaporttien kanssa, joita käytetään esimerkiksi puhe-, video-, sisällön jakaminen, kaksoisvideo- ja niin edelleen. Avattavat mediaportit riippuvat samanaikaisten puhelujen määrästä ja palveluiden määrästä.

Expresswayn SIP-kuunteluportin voi määrittää minkä tahansa arvon välillä 1024—65534. Samanaikaisesti tämä arvo ja protokollatyyppi on ilmoitettava julkis issa DNS SRV tietueissa, ja sama arvo on avattava Internetin palomuurissa.

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

Esimerkki

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

Kahden Expressway-palvelimen kluster DNS SRV in tietue näyttää tältä:

_sippaa. _tcp.example .com SRV palvelun sijainti:

priority = 10

weight = 10

port = 5062

svr isäntänimi = us-expe1.example.com

_sippaa. _tcp.example .com SRV palvelun sijainti:

priority = 10

weight = 10

port = 5062

svr isäntänimi = us-expe2.example.com

Nämä tietueet tarkoittavat, että puhelut ohjataan osoitteisiin us-expe1.example.com ja us-expe2.example.com tasaisella kuorman jakolla (prioriteetti ja paino) käyttämällä TLS: ää siirtotyyppinä ja 5062 kuunteluportin numerona.

Laitteen, joka on verkon ulkopuolella (Internetissä) ja joka soittaa SIP-puhelun yrityksen verkkotunnuksen käyttäjälle (user1@example.com), on kysy ttävä DNS:stä, mitä siirtotyyppiä käytetään, porttin umero, kuinka liikenne jaetaan ja mihin SIP- palvelimiin puhelu lähetetään.

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

TLS on asiakas-palvelin-protokolla, ja yleisimmissä toteutuksissa se käyttää varment eita todennukseen. Yritysten välisessä puhelus kenaariossa TLS-asiakas on soittava laite ja TLS-palvelin on nimeltään laite. TLS: llä asiakas tarkistaa palvelimen varmenteen, ja jos varmenteen tarkistus epäonnistuu, se katkaisee puhelun. Asiakas ei tarvitse sertifikaattia.

TLS-kädenpuristus on esitetty seuraavassa kaaviossa:

TLS-määrityksessä todetaan kuitenkin, että palvelin voi tarkistaa asiakas varmenteen myös lähettämällä varmennepyyntö viestin asiakkaalle TLS- kättelyprotokollan aikana. Tämä viesti on hyödyllinen palvelimen ja palvelimen välisessä yhteydessä, kuten puhelussa, joka on muodostettu Expressway-E: n ja Webex-pilven välillä. Tätä käsitettä kutsutaan TLS: ksi keskinäisellä todennuksella, ja sitä vaaditaan integroitaessa Webexiin.

Sekä soittavat että kutsutut osapuolet tarkistavat toisen vertaisvarmenteen, kuten seuraava kaavio osoittaa:

Pilvi tarkistaa Expressway-identiteetin ja Expressway tarkistaa pilviidentiteetin. Jos esimerkiksi varmenteen pil vitunnus (CN tai SAN) ei vastaa Expresswayn määritettyjä tietoja, yhteys katkeaa.

Jos keskinäinen todennus on käytössä, Expressway-E pyytää aina asiakasvarmennetta. Tämän seurauksena Mobile ja Remote Access (MRA) eivät toimi, koska useimmissa tapauksissa varmenteita ei oteta käyttöön Jabber- asiakkaissa. Jos soittava entiteetti ei pysty antamaan varmennetta yritysten välisessä skenaariossa, puhelu katkeaa.

Suosittelemme, että käytät muuta arvoa kuin 5061 TLS : lle, jossa on keskinäinen todennus, kuten portti 5062. Webex Hybrid Services käyttää samaa SIP TLS-tietuetta, jota käytetään B2B- palvelussa. Jos kyseessä on portti 5061, jotkin muut palvelut, jotka eivät pysty tarjoamaan TLS-asiakasvarmentetta , eivät toimi.

Jos olemassa olevaa tietuetta käytetään jo yritysten väliseen viestintään, suosittelemme määrittämään yrityksen toimialueen aliverkkotunn uksen SIP-kohteeksi Control Hubissa ja siten julkisen DNS SRV tietueen seuraavasti:

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

Yritysten välinen, mobiili- Remote Access ja Webex-liikenne samassa Expressway-parissa

Business-to-business (B2B) ja mobiili- ja Remote Access (MRA) - puhelut käyttävät porttia 5061 SIP TLS: ään ja Webex-liikenne käyttää porttia 5062 SIP TLS: ään keskinäisellä todennuksella.

Verkkotunnuksen omistajuuden tarkistus on osa henkilöllisyyden todentamista. Verkkotunnuksen vahvistus on tietoturvatoimi ja henkilöllisyyden tarkistus, jonka Webex-pilvi toteuttaa todistaakseen, että olet kuka sanot olevasi.

Henkilöllisyyden tarkistus suoritetaan kahdessa vaiheessa:

1. Verkkotunnuksen omistajuuden tarkistus. Tämä vaihe sisältää kolmen tyyppisiä verkkotunnuksia ja se on kertaluonteinen tarkistus:

   • Sähköpostiverkkotunnus

   • Expressway-E DNS-verkkotunnus

   • Hakemiston URI-verkkotunnus

2. Expressway-E DNS-nimen omistajuuden tarkistus. Tämä vaihe suoritetaan ottamalla käyttöön TLS keskinäisellä todennuksella, ja siihen sisältyy julkisten varmenteiden käyttö sekä pilvessä että Expresswayllä. Toisin kuin verkkotunnuksen henkilöllisyyden tarkistus, tämä vaihe suoritetaan minkä tahansa pilveen soitetun ja sieltä vastaanotetun puhelun aikana.

Verkkotunnuksen omistajuuden tarkistuksen merkitys

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

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

Yritys, jonka DNS-verkkotunnus on ”hacker.com”, ostaa Webex Hybrid Services -palvelun. Toinen yritys, jonka oma verkkotunnus on ”example.com”, käyttää myös hybridipalveluita. Yksi Example.com-yhtiön toimitusjohtajista on nimeltään Jane Roe ja sillä on hakemisto URI jane.roe@example.com.

Hacker.com-yrityksen ylläpitäjä asettaa yhden hakemistonsa 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-sovellukseen osoitteella 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 kollegalleen John Doelle soittamalla osoitteeseen john.doe@example.com Webex-sovelluksestaan. John istuu toimistossaan ja näkee videolaitteellaan puhelun, joka tulee osoitteesta jane.roe@example.com; se on kyseiseen sähköpostitiliin liittyvä hakemiston URI.

”Hän on ulkomailla”, hän ajattelee. Ehkä hän tarvitsee jotain tärkeää.” Hän vastaa puhelimeen, ja väärennetty Jane Roe pyytää tärkeitä asiakirjoja. Hän kertoo, että hänen laitteensa on rikki, ja koska hän on matkalla, hän pyytää miestä lähettämään asiakirjat yksityiseen sähköpostiosoitteeseensa jane.roe@hacker.com. Näin yritys tajuaa vasta Jane Roen palattua toimistoon, että tärkeitä tietoja on vuotanut yrityksen ulkopuolelle.

Yrityksellä Example.com on monia tapoja suojautua Internetistä tulevilta vilpillisiltä puheluilta, mutta yksi Webex-pilven vastuista on varmistaa, että Webexistä soittavan henkilön henkilöllisyys on oikea eikä väärennetty.

Henkilöllisyyden tarkistamiseksi Webex vaatii, että yritys todistaa omistavansa Hybrid Calling -sovelluksessa käytetyt verkkotunnukset. Jos se ei toimi, hybridipalvelut eivät toimi.

Tämän omistajuuden varmistamiseksi tarvitaan kaksi toimialueen vahvistusvaihetta:

1. Todista, että yritys omistaa sähköpostiverkkotunnuksen, Expressway-E-verkkotunnuksen, hakemiston URI-verkkotunnuksen.

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

   • Omistajuuden todistamiseksi DNS-järjestelmänvalvojan on annettava DNS-tekstitietue (TXT). TXT-tietue on DNS: n resurssitietue, jota käytetään tarjoamaan mahdollisuuden liittää mielivaltainen ja muotoilematon teksti isäntään tai muuhun nimeen.

   • DNS-järjestelmänvalvojan on syötettävä kyseinen TXT-tietue vyöhykkeelle, jonka omistajuus on todistettava. Tämän vaiheen jälkeen Webex-pilvi suorittaa TXT-tietuekyselyn kyseiselle toimialueelle.

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

   • Esimerkiksi järjestelmänvalvojan on osoitettava omistavansa verkkotunnuksen ”example.com”, jos hän haluaa, että Webex Hybrid Services toimii hänen toimialueellaan.

   • Kä yttämällä https://admin.webex.com hän aloittaa vahvistusprosessin luomalla TXT-tietueen, joka vastaa Webex-pilven luomaa tunnusta:

     

   • Tämän jälkeen DNS-järjestelmänvalvoja luo tälle toimialueelle TXT-tietueen, jonka arvo on 123456789abcdef123456789abcdef 123456789abcdef123456789abc def, kuten seuraavassa esimerkissä:

     

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

   • Pilvi suorittaa TXT-DNS-haun:

     

   • Koska TXT-arvo vastaa tunnuksen arvoa, tämä vastaavuus osoittaa, että järjestelmänvalvoja lisäsi oman toimialueensa TXT-tietueen julkiseen DNS-palveluun ja että hän omistaa toimialueen.

2. Expressway-E DNS Nimen omistajuuden tarkistus.

   • Pilven on tarkistettava, että Expressway-E: llä on vahvistettu henkilöllisyys yhdeltä varmenteen viranomaiselta, johon pilvi luottaa. Expressway-E-järjestelmänvalvojan on pyydettävä Expressway-E-laitteelleen julkinen varmenne jollekin näistä varmenteiden viranomaisista. Varmenteen myöntämiseksi varmenteen myöntäjä suorittaa henkilöllisyyden tarkistusprosessin, joka perustuu toimialueen tarkistukseen (toimialueen vahvistetuille varmenteille) tai organisaation vahvistuksen tarkistukseen (organisaation vahvistetuille varmenteille).

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

Webex-laiteliittimen on kommunikoitava Webexin kanssa, jotta hybridipuhelut toimivat.

Webex Device Connector otetaan käyttöön sisäisessä verkossa, ja tapa, jolla se kommunikoi pilven kanssa, tapahtuu lähtevän HTTPS-yhteyden kautta - samaa tyyppiä, jota käytetään kaikissa selaimissa, jotka muodostavat yhteyden verkkop alvelimeen.

Viestintä Webex-pilveen käyttää TLS: ää. Webex Device Connector on TLS-asiakas ja Webex-pilvi on TLS-palvelin. Webex Device Connector tarkistaa palvelinvarmenteen.

Varmenteen myöntäjä allekirjoittaa palvelinvarmenteen omalla yksityisellä avaimellaan. Kuka tahansa, jolla on julkinen avain, voi purkaa allekirjoituksen ja todistaa, että sama varmenteen myöntä jä allekirjoitti kyseisen varmenteen.

Jos Webex Device Connectorin on vahvistettava pilven antama varmenne, sen on käytettävä varmenteen allekirjoittaneen varmenteen viranomaisen julkista avainta allekirjoituksen purkamiseen. Jul kinen avain sisältyy varmenteen myöntäjän varmenteeseen. Lu ottamuksen luomiseksi pilven käyttämien varmenteiden myöntäjien kanssa luotettujen varmenteiden luettelon on oltava Webex Device Connector -luottamusvarastossa.

Kun olet yhteydessä laitteisiin, työkalu käyttää antamiasi luotettuja varmenteita. Tällä hetkellä tapa tehdä se on sijoittaa ne sisään [home folder]/.devicestool/certs.

Expressway-E: lle vaaditaan myös luettelo varmenteen myöntäjän varmenteiden varmenteista poikkiparissa . Expressway-E kommunikoi Webex-pilven kanssa käyttämällä SIP ja TLS: ää, joka pakotetaan keskinäisellä todennuksella. Expressway-E luottaa pilvestä tuleviin ja pilveen meneviin puheluihin vain, jos pilven TLS-yhteyden määrityksen aikana esittämän varmenteen CN tai SAN vastaa Expresswayn DNS-vyöhykkeelle määritettyä otsik konimeä (”callservice.webex.com”). Varmenteen myöntäjä vapauttaa varmenteen vasta henkilöllisyyden tarkistuksen jälkeen. Callservice.webex.com-verkkotunnuksen omistajuus on todistettava, jotta varmenne voidaan allekirjoittaa. Koska me (Cisco) omistamme kyseisen verkkotunnuksen, DNS-nimi ”callservice.webex.com” on suora todiste siitä, että etävertaisverkko on todella Webex.

kalenteriliitin integroi Webexin Microsoft Exchange 2013-, 2016-, 2019- tai Office 365:een esiintymistilin kautta. Sovelluksen esiintymisen hallintarooli Exchangessa antaa sovelluksille mahdollisuuden esiintyä organisaation käyttäjinä suorittamaan tehtäviä käyttäjän puolesta. Sovelluksen esiintymisrooli on määritettävä Exchangessa, ja sitä käytetään kalenteriliittimessä osana Exchange-määrityksiä Expressway-C-käyttöliittymässä.

Exchange-esiintymistili on Microsoftin suosittelema menetelmä tähän tehtävään. Expressway-C-järjestelmänvalvojien ei tarvitse tietää salasanaa, koska Exchange-järjestelmänvalvoja voi syöttää arvon Expressway-C-käyttöliittymään. Salasanaa ei näytetä selvästi, vaikka Expressway-C-järjestelmänvalvojalla olisi pääoikeudet Expressway-C-ruutuun. Salasana tallennetaan salattuina käyttäen samaa tunnistetietojen salausmekanismia kuin muut Expressway-C: n salasanat.

Turvallisuuden lisäämiseksi noudata Cisco Webexhybridikalenteripalvelun käyttöönotto-oppaan ohjeita ja ota TLS käyttöön langan EWS-yhteyksien suojaamiseksi.

Turvallisuuden lisäämiseksi noudata kohdassa Expressway Calendar Connector -sovelluksen käyttöönotto ohjeita, Microsoft Exchange jotta TLS voidaan suojata johdon EWS-yhteyksien suojaamiseksi.