Ez a szakasz további összefüggéseket tartalmaz a hibrid szolgáltatásokhoz kapcsolódó kulcsfontosságú konfigurációs elemekről.

Ezek a pontok kulcsfontosságúak, ha sikeresen szeretné telepíteni a Hybrid Calling for Webex eszközökre. Ezeket a tételeket különösen a következő okok miatt emeltük ki:

• Szeretnénk megmagyarázni őket, hogy megértse a hibrid telepítésben betöltött szerepüket, és megnyugvást érezze magát.

• Ezek kötelező előfeltételek biztosítják a biztonságos telepítést a felhőnk és az Ön helyszíni környezete között.

• Ezeket a nap előtti nulla tevékenységként kell kezelni: ezek teljesítése egy kicsit hosszabb ideig tarthat, mint a felhasználói felület tipikus konfigurációja, ezért adjon időkeretet ezeknek az elemeknek a rendezéséhez.

• Miután ezeket az elemeket kezelték a környezetében, a hibrid szolgáltatások többi konfigurációja zökkenőmentesen megy végbe.

Az Expressway-C és Expressway-E pár telepítése lehetővé teszi az internethez érkező és onnan történő hívásokat tűzfalátviteli technológi ákkal. Ez a telepítés biztonságosan átveszi a helyszíni hívásvezérlést, és összek apcsolja a Webex-hez.

Az Expressway-C és az Expressway-E nem igényel semmilyen bejövő port megnyitását a demilitarizált zóna (DMZ) tűzfalon a tűzfal transzferarchitektúrája miatt. De a TCP SIP jelzőportokat és az UDP médiaportokat bejövő módon kell megnyitni az internetes tűzfalon, hogy a bejövő hívások átjöjjenek. Idő t kell hagynia a megfelelő port megnyitásához a vállalati tűzfal on.

A tűzfal áthaladási architektúráját a következő ábra mutatja :

Például SIP protokollt használó bejövő vállalkozások közötti (B2B) hívások esetén az 5060-as és 5061-es TCP portokat (a SIP TLS-hez 5061-es használat) kell megnyitni a külső tűzfalon, valamint olyan szolgáltatásokhoz használt UDP-médiaportokkal együtt, mint a hang, a videó, a tartalommegosztás, a kettős videó stb. A megnyitandó médiaportokat az egyidejű hívások számától és a szolgáltatások számától függ.

Az Expressway SIP-hallgatóportját úgy konfigurálhatja, hogy bármilyen érték legyen 1024 és 65534 között. Ugyanakkor ezt az értéket és a protokoll típusát hirdetni kell a nyilvános DNS SRV nyilvántartások ban, és ugyanezt az értéket meg kell nyitni az internetes tűzfalon.

Bár a SIP TCP szabványa 5060 és a SIP TLS 5061 esetében, semmi sem akadályozza meg a különböző portok használatát, amint azt az alábbi példa mutatja.

Példa

Ebben a példában feltételezzük, hogy az 5062-es portot a bejö vő SIP TLS hívásokhoz használják.

A két Expressway szerverből álló klaszter DNS SRV rekordja így néz ki:

_kortyokat. _tcp.example .com SRV szolgáltatás helye:

priority = 10

weight = 10

port = 5062

svr gazdnév = us-expe1.example.com

_kortyokat. _tcp.example .com SRV szolgáltatás helye:

priority = 10

weight = 10

port = 5062

svr gazdnév = us-expe2.example.com

Ezek a felvételek azt jelentik, hogy a hívásokat az us-expe1.example.com és az us-expe2.example.com címre irányítják, egyenlő terheléselosztással (prioritás és súly) , szállítási típusként TLS-t és 5062 hallgatási portszámot használva.

A hálózaton kívüli eszköznek (az interneten), és amely SIP-hívást kezdeményez a vállalati domain felhasználójához (user1@example.com), lekérdeznie kell a DNS-ről, hogy megértse, melyik szállítási típust kell használni, a portszá mot, hogyan kell betölteni a forgalmat, és mely SIP-kisz olgálókra küldje el a hívást.

Ha a DNS-bejegyzés tartalmazza a _sips-t. _tcp, a bejegyzés meg adja a SIP TLS-t.

A TLS egy kliens-kiszolgáló protokoll, és a leggyakoribb implementációkban tanúsítványokat használ a hitelesítéshez. Vállalkozás-üzleti hívási forgatókönyv esetén a TLS-kliens a hívó eszköz, a TLS-kiszolgál ó pedig a hívott eszköz. A TLS-szel az ügyfél ellenőrzi a kiszolgáló tanúsítványát, és ha a tanúsítványellenőrzés sikertelen, leválasztja a hívást. Az ügyfélnek nincs szüksége tanúsítványra.

A TLS kézfogás a következő ábrán látható:

A TLS-specifikáció azonban kimondja, hogy a kiszolgáló ellenőrizheti az ügyféltanúsítványt is, ha tanúsítványkérési üzenetet küld az ügyfélnek a TLS kézfogási protokoll során. Ez az üzenet hasznos egy szer ver-szerver kapcsolaton, például híváskor, amelyet az Expressway-E és a We bex felhő között hoztak létre. Ezt a koncepciót kölcsönös hitelesítéssel rendelkező TLS-nek hívják, és a Webex-szel való integráláskor szükséges.

Mind a hívó, mind a hívott fél ellenőrzi a másik partner tanúsítványát, amint azt az alábbi ábra mutatja:

A felhő ellenőrzi az Expressway azonosságát, az Expressway pedig a fel hő azonosságát. Ha például a tanúsítvány felhő azonossága (CN vagy SAN) nem egyezik meg az Expressway konfigurálásával, a kapcsolat megszűnik.

Ha a kölcsönös hitelesítés be van kapcsolva, az Expressway-E mindig kéri az ügyféltanúsí tványt. Ennek eredményeként a Mobile és Remote Access (MRA) nem fog működni, mivel a legtöbb esetben a tanúsítványok nem kerülnek telepítésre a Jabber klienseken. Vállalkozás közötti forgatókönyv esetén, ha a hívó entitás nem tud tanúsítványt nyújtani, a hívás lekapcsolódik.

Javasoljuk, hogy kölcsönös hitelesítéssel rendelkező TLS-hez 5061-től eltérő értéket használ jon, például az 5062-es port. A Webex Hybrid Services ugyanazt a SIP TLS-rekordot használja, mint a B2B esetében. Az 5061-es port esetében néhány olyan szolgáltatás, amely nem tud TLS ügyféltanúsítványt biztosítani, nem fog működni.

Ha egy meglévő rekor dot már használnak vállalkozások közötti kommunikációhoz, javasoljuk, hogy a Control Hub SIP-célpontjaként adja meg a vállalati tartomány altartományát, következésképpen pedig nyilvános DNS SRV rekordot, az alábbiak szerint:

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

Business-business, Mobile és Webex forgal Remote Access om ugyanazon a gyorsforgalmi páron

Az üzleti vállalkozások közötti (B2B), valamint a mobil és Remote Access (MRA) hívások az 5061-es portot használják a SIP TLS-hez, a Webex forgalom pedig az 5062-es portot használja a SIP TLS-hez kölcsönös hitelesítéssel.

A tartománytulajdonossági ellenőrzés az identitás-ellenőrzés része. A tartomány-ellenőrzés egy biztonsági intézkedés és identitás-ellenőrzés, amelyet a Webex felhő bevezet annak bizonyítására, hogy Ön az, akit mond.

A személyazonosság ellenőrzése két szakaszban történik:

1. Domaintulajdon ellenőrzése. Ez a lépés háromféle tartományt foglal magában, és egyszeri ellenőrzési ellenőrzést jelent:

   • E-mail domain

   • Expressway-E DNS-tartomány

   • Címtár URI domain

2. Expressway-E DNS név tulajdonjogának ellenőrzése. Ezt a lépést a TLS kölcsönös hitelesítéssel történő megvalósításával hajtják végre, és magában foglalja a nyilvános tanúsítványok használatát mind a felhőn, mind a gyorsforgalmi úton. A tartományazonosság ellenőrzésével ellentétben ezt a lépést a felhőbe irányuló és onnan fogadott hívások során hajtják végre.

A domain tulajdonjog ellenőrzésének fontossága

A Webex felhő elvégzi a tartománytulajdonossági ellenőrzést a biztonság érvényesítése érdekében. A személyazonosság-lopás az egyik lehetséges fenyegetés, ha ezt az ellenőrzést nem hajtják végre.

A következő történet részletezi, hogy mi történhet, ha nem hajtják végre a tartománytulajdonosi ellenőrzést.

Egy cég, amelynek DNS-tartománya „hacker.com” értékre van állítva, megvásárolja a Webex Hybrid Services szolgáltatásokat. Egy másik cég, amelynek saját domainje „example.com” -ra van beállítva, szintén hibrid szolgáltatásokat használ. Az Example.com cég egyik vezérigazgatója Jane Roe, és rendelkezik az URI jane.roe@example.com címtárral.

A Hacker.com cég adminisztrátora címtár egyik URI-jét állítja be a jane.roe@example.com címre, az e-mail címet pedig a jane.roe@hacker.com címre. Ezt azért teheti meg, mert a felhő ebben a példában nem ellenőrzi a SIP URI tartományt.

Ezután bejelentkezik a Webex App-ba az jane.roe@hacker.com címen. Mivel ő tulajdonosa a domain, az ellenőrző e-mailt elolvass ák és válaszolják, és bejelentkezhet. Végül felhívott egy kollégáját, John Doe-t azzal, hogy a Webex alkalmazásból hív ja a john.doe@example.com címet. John az irodájában ül, és videókészülékén egy hívást lát, amely a jane.roe@example.com címről érkezik; ez az e-mail fiókhoz társított könyvtár URI.

„Külföldön van” - gondolja. „Lehet, hogy szüksége van valami fontosra.” Felveszi a telefont, és a hamis Jane Roe fontos dokumentumokat kér. Elmagyarázza, hogy a készüléke meghibásodott, és mivel utazik, megkéri tőle, hogy küldje el a dokumentumokat a privát e-mail címére, a jane.roe@hacker.com címre. Ily módon a cég csak azután jön rá, hogy Jane Roe visszatért az irodába, hogy fontos információk szivárogtak ki a cégen kívül.

Az Example.com cégnek számos módja van az internetről érkező csalárd hívások ellen, de a Webex felhő egyik felelőssége annak biztosítása, hogy a Webex-ről hívók személyazonossága helyes és nem hamisított.

A személyazonosság ellenőrzéséhez a Webex megköveteli, hogy a vállalat bizonyítsa, hogy a hibrid hívásban használt domainek tulajdonosa. Ha nem, akkor a hibrid szolgáltatások nem fognak működni.

A tulajdonjog biztosításához a két tartományellenőrzési lépésre van szükség:

1. Bizonyítsa be, hogy a vállalat birtokolja az e-mail tartományt, az Expressway-E tartományt, a Directory URI tartományt.

   • Ezeknek a domaineknek útválaszthatónak kell lenniük és ismertnek kell lenniük a nyilvános DNS-szerverek által.

   • A tulajdonjog igazolásához a DNS-rendszergazdának be kell írnia egy DNS-szöveges rekordot (TXT). A TXT rekord egyfajta erőforrás-rekord a DNS-ben, amelyet arra használnak, hogy bizonyos tetszőleges és formázatlan szövegek társítását biztosítsák egy gazdához vagy más névhez.

   • A DNS-rendszergazdának be kell írnia ezt a TXT rekordot abban a zónában, amelynek tulajdonjogát bizonyítani kell. Ezt a lépést követően a Webex felhő TXT rekordlekérdezést hajt végre az adott tartományhoz.

   • Ha a TXT lekérdezés sikeres, és az eredmény megegyezik a Webex felhőből létrehozott tokennel, a tartomány ellenőrzésre kerül.

   • Például az adminisztrátornak bizonyítania kell, hogy a „example.com” domain tulajdonosa, ha azt akarja, hogy a Webex Hybrid Services működjön a domainjén.

   • A https://admin.webex.com oldalon keresztül megkezdi az ellenőrzési folyamatot egy TXT rekord létrehozásával, amely megfelel a Webex felhő által generált tokennek:

     

   • A DNS-rendszergazda ezután létrehoz egy TXT rekordot ehhez a tartományhoz 123456789abcdef123456789abcdef 123456789abcdef123456789abc def értékkel, mint az alábbi példában:

     

   • Ezen a ponton a felhő ellenőrizheti, hogy az example.com domain TXT rekordja megegyezik-e a tokennel.

   • A felhő TXT DNS-keresést hajt végre:

     

   • Mivel a TXT érték megegyezik a token értékével, ez az egyezés bizonyítja, hogy a rendszergazda hozzáadta a saját tartományának TXT rekordját a nyilvános DNS-hez, és hogy ő tulajdonosa a tartománynak.

2. Expressway-E DNS-név tulajdonjogának ellenőrzése.

   • A felhőnek ellenőriznie kell, hogy az Expressway-E rendelkezik-e megerősített azonosítóval az egyik tanúsítvánnyal rendelkező hatóságtól, amelyben a felhő megbízik. Az Expressway-E rendszergazdájának nyilvános tanúsítványt kell kérnie az Expressway-E számára az egyik ilyen tanúsítványhatósághoz. A tanúsítvány kiállításához a tanúsítványhatóság azonosságellenőrzési folyamatot hajt végre, amely tartományérvényesítési ellenőrzés (tartományi hitelesített tanúsítványok esetén) vagy szervezeti érvényesítési ellenőrzés (szervezet által hitelesített tanúsítványok esetén) alapján történik.

   • A felhőbe érkező és onnan érkező hívások az Expressway-E számára kiadott tanúsítványtól függenek. Ha a tanúsítvány nem érvényes, a hívás leáll.

A Webex eszközcsatlakozónak kommunikálnia kell a Webex-szel ahhoz, hogy a hibrid hívás működjön.

A Webex Device Connector a belső hálózaton van telepítve, és a felhővel való kommunikáció egy kimenő HTTPS-kapcsolat on keresztül történik - ugyanazt a típust használják bármely böngésző nél, amely csatlakozik egy webkiszolgálóhoz.

A Webex felhővel való kommunikáció TLS-t használ. A Webex Device Connector a TLS-kliens, a Webex felhő pedig a TLS-kiszolgáló. Mint ilyen, a Webex Device Connector ellenőrzi a kiszolgáló tanúsítványát.

A tanúsítvánnyal rendelkező hatóság saját magánkulccsal ír alá egy kiszolgálótanúsítványt. Bárki, aki rendelkezik nyilvános kulccsal, dekódolhatja ezt az aláírást, és bizonyíthatja, hogy ugyanaz a tanúsítvány ható sága írta alá a tanúsítványt

Ha a Webex Device Connectornak ellenőriznie kell a felhő által biztosított tanúsítványt, az aláírás dekódolásához a tanúsítványt aláíró hatóság nyilvános kul csát kell használnia. A tanúsító hatóság tanúsítványában nyilvános kulcs található. Ahhoz, hogy bizalmat teremtsen a felhő által használt tanúsítványhatóságokkal szemben, a megbízható tanúsítvánnyal rendelkező hatóságok tanúsítványainak listájának a Webex Device Connector megbízhatósági tárolóban kell lennie.

Az eszközökkel való kommunikáció során az eszköz megbízható tanúsítványokat használ, amelyeket megadott. Jelenleg ezt úgy tehetjük meg, hogy behelyezzük őket [home folder]/.devicestool/certs.

A tanúsítvánnyal rendelkező hatósági tanúsítványok listája is szükséges az Expressway-E esetében a járatpárban . Az Expressway-E kommunikál a Webex felhővel a SIP és TLS-sel, kölcsönös hitelesítéssel kényszerítve. Az Expressway-E csak akkor bízik meg a felhőből érkező és a felhőbe érkező hívásokban, ha a felhő által a TLS-kapcsolat beállítása során bemutatott tanúsítvány CN vagy SAN értéke megegyezik az Expressway DNS-zónájához konfigurált tárgynévvel („callservice.webex.com”). A tanúsító hatóság csak személyazonossági ellenőrzés után bocsátja ki a tanúsítványt. A tanúsítvány aláírásához bizonyítani kell a callservice.webex.com domain tulajdonjogát. Mivel mi (Cisco) birtokoljuk ezt a tartom ányt, a „callservice.webex.com” DNS-név közvetlen bizonyíték arra, hogy a távoli peer valóban Webex.

A naptárcsatlakozó egy megszemélyesítési fiókon keresztül integrálja a Webex-et a Microsoft Exchange 2013, 2016, 2019 vagy Office 365-hez. Az Exchange alkalmazás-megszemélyesítés-kezelő szerepköre lehetővé teszi az alkalmazások számára, hogy a szervezet felhasználóinak személyeskedjenek meg, hogy a felhasználó nevében feladatokat hajtsanak végre. Az alkalmazás megszemélyesítési szerepét az Exchange-ben kell konfigurálni, és az Expressway-C interfész Exchange-konfigurációjának részeként a naptárcsatlakozóban használható.

Az Exchange-megszemélyesítési fiók a Microsoft által ajánlott módszer ehhez a feladathoz. Az Expressway-C rendszergazdáknak nem kell ismerniük a jelszót, mert az értéket az Expressway-C felületen egy Exchange rendszergazda beírhatja. A jelszó nem jelenik meg egyértelműen, még akkor sem, ha az Expressway-C rendszergazda root hozzáféréssel rendelkezik az Expressway-C mezőhöz. A jelszót titkosítva tárolják ugyanazzal a hitelesítő titkosítási mechanizmussal, mint az Expressway-C többi jelszavát.

További biztonság érdekében kövesse a Cisco Webexhibrid naptárszolgáltatás telepítési útmutatójának lépéseit a TLS-t a vezetéken történő EWS-kapcsolatok biztosítása érdekében.

További biztonság érdekében kövesse az Expressway Calendar Connector telep ítése részben található lépéseket, Microsoft Exchange hogy engedélyezze a TLS-t a vezetéken történő EWS-kapcsolatok biztosításához.