Valmistelut ennen Cisco Webex -hybridipalveluiden käyttöönottoa

list-menuOnko sinulla palautetta?
Sinulla saattaa olla ongelmia Cisco Webex Hybrid Servicesin käyttöönotossa ympäristössäsi. Tai haluat vain ymmärtää paremmin joitakin suunnitteluun liittyviä näkökohtia. Tämä artikkeli voi toimia tarkistuslistana, joka auttaa sinua ymmärtämään tärkeitä hybridi-asioita, kuten palomuuriin liittyviä näkökohtia, varmentajien myöntäjiä ja verkkotunnuksen omistajuutta.

Tässä osiossa on lisätietoa hybridipalveluihin liittyvistä keskeisistä määrityskohteista.

Nämä seikat ovat ratkaisevan tärkeitä, jos haluat ottaa hybridipuhelut onnistuneesti käyttöön Webex-laitteissa. Olemme korostaneet näitä kohtia erityisesti seuraavista syistä:

  • Haluamme selittää ne, jotta ymmärrät niiden roolin hybridikäyttöönotossa ja tunnet olosi rauhalliseksi.

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

  • Niitä tulisi kohdella kuten nollapäivää edeltäviä aktiviteetteja: Niiden suorittaminen voi kestää hieman kauemmin kuin tyypillinen käyttöliittymän konfigurointi, joten varaa aikaa näiden asioiden hoitamiseen.

  • Kun nämä asiat on käsitelty ympäristössäsi, hybridipalveluiden konfiguroinnin loppuosa sujuu ongelmitta.

Expressway-C- ja Expressway-E-parin käyttöönotto mahdollistaa puhelut Internetiin ja Internetistä käyttämällä palomuurin läpikulkutekniikoita. Tämä käyttöönotto yhdistää paikallisen puheluidenhallinnan turvallisesti Webexiin.

Expressway-C ja Expressway-E eivät vaadi saapuvan liikenteen porttien avaamista demilitarisoidun vyöhykkeen (DMZ) palomuurissa palomuurin läpikulkuarkkitehtuurin ansiosta. Mutta TCP SIP -signalointiportit ja UDP-mediaportit on avattava saapuvaan liikenteeseen internet-palomuurissa, jotta saapuvat puhelut pääsevät läpi. Sinun on odotettava, että yrityksesi palomuurissa avautuu sopiva portti.

Palomuurin läpikulkuarkkitehtuuri on esitetty seuraavassa kaaviossa:

Kaavio, joka näyttää palomuurin läpikulkuarkkitehtuurin

Esimerkiksi SIP-protokollaa käyttäville saapuville yritysten välisille (B2B) puheluille TCP-portit 5060 ja 5061 (5061 on käytössä SIP TLS:lle) on avattava ulkoisessa palomuurissa yhdessä UDP-mediaporttien kanssa, joita käytetään esimerkiksi ääni-, video-, sisällönjako- ja kaksoisvideopalveluihin. Avattavien mediaporttien valinta riippuu samanaikaisten puheluiden ja palveluiden määrästä.

Voit määrittää Expresswayn SIP-kuunteluportin arvoksi minkä tahansa arvon väliltä 1024–65534. Samanaikaisesti tämä arvo ja protokollatyyppi on mainostettava julkisissa DNS SRV -tietueissa, ja sama arvo on avattava internet-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 klusterin DNS SRV-tietue näyttää tältä:

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

prioriteetti = 10

paino = 10

satama = 5062

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

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

prioriteetti = 10

paino = 10

satama = 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 tasapuolisella kuormituksen jakamisella (prioriteetti ja painoarvo) käyttäen TLS:ää siirtotyyppinä ja 5062:ta kuunteluporttinumerona.

Laite, joka on verkon ulkopuolella (internetin kautta) ja joka soittaa SIP-puhelun yritysverkkotunnuksen käyttäjälle. (user1@example.com) täytyy kysyä DNS:ltä, mitä siirtotyyppiä käytetään, portin numero, miten liikenne jaetaan ja mille SIP-palvelimille puhelu lähetetään.

Jos DNS-merkinnässä on _sips._tcp, merkintä määrittää SIP TLS:n.

TLS on asiakas-palvelin-protokolla ja yleisimmissä toteutuksissa käytetään todennukseen varmenteita. Yritysten välisessä puhelutilanteessa TLS-asiakasohjelma on soittava laite ja TLS-palvelin on kutsuttava laite. TLS-salauksen avulla asiakas tarkistaa palvelimen varmenteen, ja jos varmenteen tarkistus epäonnistuu, se katkaisee puhelun. Asiakas ei tarvitse sertifikaattia.

TLS-kättely on esitetty seuraavassa kaaviossa:

TLS-kättelyn yleiskuvauskaaviosta

TLS-spesifikaatio kuitenkin toteaa, että palvelin voi myös tarkistaa asiakassertifikaatin lähettämällä asiakkaalle sertifikaattipyyntöviestin TLS-kättelyprotokollan aikana. Tämä viesti on hyödyllinen palvelinten välisessä yhteydessä, kuten Expressway-E:n ja Webex-pilvipalvelun välille muodostetussa puhelussa. Tätä konseptia kutsutaan TLS:ksi keskinäisellä todennuksella, ja se on pakollinen Webex-integraatiossa.

Sekä soittava että vastaanottava osapuoli tarkistavat toisen osapuolen varmenteen, kuten seuraava kaavio osoittaa:

Kaavio TLS-kättelystä keskinäisellä todennuksella, jossa sekä TLS-asiakas että TLS-palvelin tarkistavat toisen vertaisosan varmenteen

Pilvi tarkistaa Expresswayn identiteetin ja Expressway tarkistaa pilvipalvelun identiteetin. Jos esimerkiksi varmenteen (CN tai SAN) pilvi-identiteetti ei vastaa Expresswayssa määritettyä, yhteys katkeaa.

Jos molemminpuolinen todennus on käytössä, Expressway-E pyytää aina asiakasvarmennetta. Tämän seurauksena mobiili- ja etäkäyttö (MRA) ei toimi, koska useimmissa tapauksissa varmenteita ei ole otettu käyttöön Jabber-asiakasohjelmissa. Yritysten välisessä tilanteessa puhelu katkaistaan, jos soittaja ei pysty toimittamaan varmennetta.

Suosittelemme käyttämään molemminpuolisen todennuksen sisältävälle TLS:lle muuta arvoa kuin 5061, kuten porttia 5062. Webex Hybrid Services käyttää samaa SIP TLS -tietuetta kuin B2B. Portin 5061 tapauksessa jotkin muut palvelut, jotka eivät voi tarjota TLS-asiakassertifikaattia, eivät toimi.

Jos olemassa olevaa tietuetta käytetään jo yritysten väliseen viestintään, suosittelemme määrittämään yrityksen verkkotunnuksen aliverkkotunnuksen 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- ja etäkäyttö- sekä Webex-liikenne samalla Expressway-parilla

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

Verkkotunnuksen omistajuuden tarkistus on osa henkilöllisyyden varmennusta. Verkkotunnuksen vahvistus on Webex-pilvipalvelun toteuttama turvatoimenpide ja henkilöllisyyden tarkistus, jolla varmistetaan, että henkilöllisyys on se, joka väität olevasi.

Henkilöllisyystarkastus suoritetaan kahdessa vaiheessa:

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

    • Sähköpostiosoite

    • Expressway-E DNS-verkkotunnus

    • Hakemiston URI-verkkotunnus

  2. Expressway-E DNS-nimen omistajuuden tarkistus. Tämä vaihe suoritetaan TLS:n ja keskinäisen todennuksen avulla, ja siihen liittyy julkisten varmenteiden käyttö sekä pilvessä että Expresswaylla. Toisin kuin verkkotunnuksen identiteetin tarkistus, tämä vaihe suoritetaan kaikkien pilveen tehtyjen ja pilvestä vastaanotettujen puheluiden aikana.

Verkkotunnuksen omistajuuden tarkistuksen tärkeys

Webex-pilvipalvelu suorittaa verkkotunnuksen omistajuustarkistuksen turvallisuuden varmistamiseksi. Identiteettivarkaus on yksi mahdollinen uhka, jos tätä tarkistusta ei suoriteta.

Seuraava tarina kertoo, mitä voi tapahtua, jos verkkotunnuksen omistajuustarkistusta ei suoriteta.

Yritys, jonka DNS-verkkotunnukseksi on asetettu "hacker.com", ostaa Webex Hybrid Servicesin. Toinen yritys, jonka oma verkkotunnus on "example.com", käyttää myös hybridipalveluita. Yksi Example.com-yrityksen toimitusjohtajista on nimeltään Jane Roe, ja hänen hakemistonsa URI on jane.roe@example.com.

Hacker.com-yrityksen ylläpitäjä asettaa yhden hakemisto-URI-osoitteistaan arvoon jane.roe@example.com ja sähköpostiosoite, johon jane.roe@hacker.com. Hän voi tehdä niin, koska pilvi ei tarkista SIP URI -verkkotunnusta tässä esimerkissä.

Seuraavaksi hän kirjautuu Webex-sovellukseen tunnisteella jane.roe@hacker.com. Koska hän omistaa verkkotunnuksen, vahvistussähköposti luetaan ja siihen vastataan, ja hän voi kirjautua sisään. Lopulta hän soittaa kollegalleen, John Doelle, valitsemalla john.doe@example.com hänen Webex-sovelluksestaan. John istuu toimistossaan ja näkee videolaitteellaan puhelun tulevan jane.roe@example.com; se 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äärennös 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 hänen yksityiseen sähköpostiosoitteeseensa. jane.roe@hacker.com. Tällä tavoin yritys tajuaa vasta Jane Roen palattua toimistolle, että tärkeitä tietoja on vuotanut yrityksen ulkopuolelle.

Example.com-yrityksellä on monia tapoja suojautua internetistä tulevilta vilpillisiltä puheluilta, mutta yksi Webex-pilvipalvelun vastuista on varmistaa, että Webexistä soittavien henkilöllisyys on oikea eikä väärennetty.

Henkilöllisyyden tarkistamiseksi Webex vaatii yrityksen todistavan omistavansa hybridipuheluissa käytettävät verkkotunnukset. Jos näin ei ole, hybridipalvelut eivät toimi.

Tämän omistajuuden varmistamiseksi verkkotunnuksen vahvistusvaiheet ovat kaksi:

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

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

    • Omistajuuden todistamiseksi DNS-järjestelmänvalvojan on syötettävä DNS-tekstitietue (TXT). TXT-tietue on DNS-resurssitietuetyyppi, jota käytetään yhdistämään mielivaltainen ja muotoilematon teksti isäntänimeen tai muuhun nimeen.

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

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

    • Esimerkiksi järjestelmänvalvojan on todistettava omistavansa verkkotunnuksen "example.com", jos hän haluaa Webex Hybrid Servicesin toimivan verkkotunnuksellaan.

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

      Vahvista verkkotunnus -ikkuna, jossa viesti "Sinun on kopioitava ja liitettävä DNS-vahvistustunnus TXT-tietueosioon todistaaksesi, että omistat verkkotunnuksen" ja vahvistuspainike

    • DNS-järjestelmänvalvoja luo sitten tälle verkkotunnukselle TXT-tietueen, jonka arvoksi asetetaan 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, kuten seuraavassa esimerkissä:

      Tietuejoukon muokkausikkuna, jossa on täytetty TXT-tietuearvo

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

    • Pilvi suorittaa TXT-nimihaun:

      pilvi suorittaa TXT DNS -haun koodilla

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

  2. Expressway-E DNS-nimen omistajuuden tarkistus.

    • Pilvipalvelun on tarkistettava, että Expressway-E:llä on vahvistettu identiteetti joltakin pilven luottamasta varmentajasta. Expressway-E-järjestelmänvalvojan on pyydettävä Expressway-E:lleen julkinen varmenne yhdeltä näistä varmenteiden myöntäjistä. Varmenteen myöntämiseksi varmentaja suorittaa henkilöllisyyden varmennusprosessin, joka perustuu verkkotunnuksen validointitarkistukseen (verkkotunnuksen validoimille varmenteille) tai organisaation validointitarkistukseen (organisaation validoimille varmenteille).

    • Pilvipuhelut riippuvat Expressway-E:lle myönnetystä varmenteesta. Jos varmenne ei ole voimassa, puhelu katkeaa.

Webex-laiteliittimen on oltava yhteydessä Webexiin, jotta hybridipuhelut toimivat.

Webex-laiteliitin otetaan käyttöön sisäisessä verkossa, ja se kommunikoi pilven kanssa lähtevän HTTPS-yhteyden kautta – saman tyyppistä yhteyttä käytetään missä tahansa selaimessa, joka muodostaa yhteyden verkkopalvelimeen.

Viestintä Webex-pilveen käyttää TLS-salausta. Webex-laiteliitin on TLS-asiakasohjelma ja Webex-pilvipalvelu on TLS-palvelin. Näin ollen Webex-laiteliitin 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-laiteliittimen on vahvistettava pilven toimittama varmenne, sen on käytettävä varmenteen allekirjoittaneen varmentajavaltuutuksen julkista avainta allekirjoituksen dekoodaamiseen. Julkinen avain sisältyy varmentajan varmenteeseen. Jotta pilvipalvelun käyttämiin varmentajien kanssa voidaan muodostaa luottamus, näiden luotettavien varmentajien varmenteiden luettelon on oltava Webex-laiteliittimen luottamussäilössä.

Kun työkalu kommunikoi laitteiden kanssa, se käyttää antamiasi luotettavia varmenteita. Tällä hetkellä se onnistuu sijoittamalla ne [home folder]/.devicestool/certs-merkkiin.

Läpikulkuparin Expressway-E:lle vaaditaan myös varmentajien varmenteiden luettelo. Expressway-E kommunikoi Webex-pilven kanssa SIP-yhteyden ja TLS:n avulla, ja sitä valvotaan molemminpuolisella todennuksella. Expressway-E luottaa pilvestä tuleviin ja pilveen meneviin puheluihin vain, jos pilven TLS-yhteyden muodostamisen aikana esittämän varmenteen CN- tai SAN-nimi vastaa Expresswayn DNS-vyöhykkeelle määritettyä kohteen nimeä ("callservice.webex.com"). Varmentaja myöntää varmenteen vasta henkilöllisyystarkistuksen 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äkäyttäjä on todella Webex.

Kalenteriliitin integroi Webexin Microsoft Exchange 2013:een, 2016:een, 2019:ään tai Office 365:een henkilöllisyyden tunnistavan tilin kautta. Exchangen sovellusten tekeytymisen hallintarooli antaa sovelluksille mahdollisuuden tekeytyä organisaation käyttäjiksi ja suorittaa tehtäviä käyttäjän puolesta. Sovelluksen henkilöllisyyden käyttörooli on määritettävä Exchangessa, ja sitä käytetään kalenteriliittimessä osana Exchange-määritystä Expressway-C-rajapinnassa.

Exchangen henkilöllisyyden käyttöön tarkoitettu tili 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ääkäyttäjän oikeudet Expressway-C-koneeseen. Salasana tallennetaan salattuna samalla tunnistetietojen salausmekanismilla kuin muutkin Expressway-C:n salasanat.

Lisäturvaa varten ota TLS käyttöön noudattamalla Cisco Webex Hybrid Calendar Servicen käyttöönotto-oppaan ohjeita ja suojaa EWS-yhteydet langallisessa verkossa.

Lisäturvaa varten ota TLS käyttöön noudattamalla Ota Expressway Calendar Connector for Microsoft Exchange -kohdassa olevia ohjeita ja suojaa EWS-yhteydet langallisessa verkossa.

Oliko tästä artikkelista apua?
Oliko tästä artikkelista apua?