Ez a szakasz további kontextust biztosít a hibrid szolgáltatásokhoz kapcsolódó kulcsfontosságú konfigurációs elemekről.

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

• Szeretnénk elmagyarázni őket, hogy megértsék a szerepüket a hibrid telepítésben, és megnyugodjanak.

• Ezek kötelező előfeltételek, amelyek biztonságos üzembe helyezést biztosítanak felhőnk és a helyszíni környezet között.

• Ezeket a nulladik napi tevékenységekként kell kezelni: egy kicsit tovább tarthatnak, mint a felhasználói felület tipikus konfigurációja, ezért lehetővé teszik az időkeret rendezését.

• Miután ezeket az elemeket a környezetében kezelte, a hibrid szolgáltatások konfigurációjának többi része zökkenőmentesen fog működni.

Az Expressway-C és az Expressway-E pár üzembe helyezése lehetővé teszi az internetre irányuló és az internetről indított hívásokat tűzfalbejárási technológiák használatával. Ez az üzembe helyezés biztonságos módon veszi át a helyszíni hívásvezérlést, és csatlakoztatja azt a Webexhez.

Az Expressway-C és az Expressway-E nem követeli meg, hogy a tűzfal átszeletes architektúrája miatt a demilitarizált zóna (DMZ) tűzfalán bármilyen bejövő portot megnyisson. A TCP SIP jelzőportokat és az UDP médiaportokat azonban az internetes tűzfalon befelé kell megnyitni, hogy a bejövő hívások átjönjenek. Időt kell hagynia arra, hogy a megfelelő port megnyíljon a vállalati tűzfalon.

A tűzfal átjárási architektúrája az alábbi ábrán látható:

A SIP protokollt használó bejövő vállalkozások (B2B) hívások esetén például az 5060-as és az 5061-es TCP-portot (az 5061-et a SIP TLS-hez használják) meg kell nyitni a külső tűzfalon, valamint az olyan szolgáltatásokhoz használt UDP médiaportokat, mint a hang, a videó, a tartalommegosztás, a kettős videó stb. A megnyitandó médiaportok az egyidejű hívások számától és a szolgáltatások számától függenek.

Beállíthatja, hogy a SIP-lehallgató port az Expressway-en bármilyen érték legyen 1024 és 65534 között. Ugyanakkor ezt az értéket és a protokolltípust a nyilvános DNS SRV-rekordokban kell hirdetni, és ugyanezt az értéket meg kell nyitni az internetes tűzfalon.

Bár a SIP TCP és a SIP TLS 5061 szabványa 5060, 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 port bejövő SIP TLS-hívásokhoz használatos.

A dns SRV rekord egy klaszter két Expressway szerverek így néz ki:

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

prioritás = 10

súly = 10

port = 5062

svr hostname = us-expe1.example.com

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

prioritás = 10

súly = 10

port = 5062

svr hostname = us-expe2.example.com

Ezek a rekordok azt jelentik, hogy a hívások us-expe1.example.com irányulnak, és us-expe2.example.com azonos terhelésmegosztással (prioritás és súly), a TLS-t használva átviteli típusként és 5062-t figyelő portszámként.

A hálózaton kívüli (az interneten) kívüli eszköznek, amely SIP-hívást kezdeményez a vállalati tartomány (user1@example.com) felhasználójához, le kell kérdeznie a DNS-t, hogy megértse, melyik átviteli típust kell használni, a portszámot, hogyan kell betölteni-megosztani a forgalmat, és mely SIP-kiszolgálóknak kell elküldenie a hívást.

Ha a DNS-bejegyzés tartalmazza _sipsa elemet , a_tcpbejegyzés SIP TLS-t ad meg.

A TLS egy ügyfél-kiszolgáló protokoll, és a leggyakoribb implementációkban tanúsítványokat használ a hitelesítéshez. A vállalkozások közötti hívás esetén a TLS-ügyfél a hívóeszköz, a TLS-kiszolgáló pedig a hívott eszköz. A TLS használatával 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ása az alábbi ábrán látható:

A TLS-specifikáció azonban azt állítja, hogy a kiszolgáló a TLS kézfogási protokoll során tanúsítványkérelem üzenet küldésével is ellenőrizheti az ügyféltanúsítványt. Ez az üzenet kiszolgáló–kiszolgáló kapcsolaton hasznos, például az Expressway-E és a Webex felhő között létrehozott hívásban. Ezt a koncepciót TLS-nek hívják kölcsönös hitelesítéssel, és a Webexszel való integráláskor szükséges.

Mind a hívó, mind a hívott felek ellenőrzik a másik társ tanúsítványát, amint azt az alábbi ábra mutatja:

A felhő ellenőrzi az expressz út identitását, a gyorsforgalmi út pedig a felhő identitását. Ha például a tanúsítványban (CN vagy SAN) lévő felhőidentitás nem egyezik meg az expresswayen konfigurálttal, a kapcsolat megszakad.

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 mobil- és távelérés (MRA) nem fog működni, mert a legtöbb esetben a tanúsítványok nincsenek telepítve a Jabber-ügyfeleken. Vállalkozásról vállalatra vonatkozó forgatókönyv esetén, ha a hívó entitás nem tud tanúsítványt biztosítani, a hívás megszakad.

Javasoljuk, hogy a TLS-hez az 5061-es értéktől eltérő értéket használjon kölcsönös hitelesítéssel, például az 5062-es porttal. 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 más szolgáltatás, amely nem tud TLS-ügyféltanúsítványt biztosítani, nem fog működni.

Ha egy meglévő rekordot már használnak a vállalkozások közötti kommunikációhoz, azt javasoljuk, hogy a vállalati tartomány egy altartományát SIP-célállomásként a Control Hubban, majd egy nyilvános DNS SRV-rekordot adjon meg, az alábbiak szerint:

 Szolgáltatás és protokoll: _sips._tcp.mtls.example.com Prioritás: 1 Súly: 10 Portszám: 5062 Cél: us-expe1.example.com 

Vállalatközi, mobil és távoli hozzáférés és Webex-forgalom ugyanazon az Expressway-páron

A vállalkozások közötti (B2B) és a mobil és távoli hozzáférés (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 kölcsönös hitelesítéssel rendelkező SIP TLS-hez.

A tartomány tulajdonjogának ellenőrzése a személyazonosság ellenőrzésének része. A tartományellenőrzés biztonsági intézkedés, és a személyazonosság-ellenőrzés, amelyet a Webex-felhő annak bizonyítására hajt végre, hogy Ön az, akinek mondja magát.

Az identitásellenőrzés két szakaszban történik:

1. Domain tulajdonjog ellenőrzése. Ez a lépés három típusú tartományt foglal magában, és egyszeri ellenőrzési ellenőrzés:

   • E-mail tartomány

   • Gyorsforgalmi út-E DNS-tartomány

   • Címtár URI-tartománya

2. Expressway-E DNS név tulajdonjogának ellenőrzése. Ez a lépés a TLS kölcsönös hitelesítéssel történő megvalósításával történik, és magában foglalja a nyilvános tanúsítványok használatát mind a felhőben, mind az expressz úton. A tartományidentitás-ellenőrzéstől eltérően ez a lépés a felhőbe irányuló és onnan érkező hívás során történik.

A tartomány tulajdonjogának ellenőrzése

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

Az alábbi történet részletezi, hogy mi történhet, ha nem hajtják végre a tartomány tulajdonjogának ellenőrzését.

Egy „hacker.com” DNS-tartománnyal rendelkező vállalat megveszi a Webex Hybrid Services szolgáltatást. Egy másik vállalat, amelynek saját domainje "example.com" -re van állítva, szintén hibrid szolgáltatásokat használ . A Example.com cég egyik ügyvezetője Jane Roe, és az URI jane.roe@example.com könyvtárral rendelkezik.

A vállalat rendszergazdája Hacker.com egyik könyvtári URI-ját jane.roe@example.com, az e-mail-címet pedig jane.roe@hacker.com. 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 alkalmazásba a jane.roe@hacker.com címen. Mivel övé a domain, az ellenőrző e-mailt elolvassák és megválaszolják, és bejelentkezhet. Végül felhívja egy kollégáját, John Doe-t, ha a Webex alkalmazáson keresztül tárcsázza a john.doe@example.com címet. John az irodájában ül, és meglát egy hívást a videóeszközén a jane.roe@example.com-tól; ez az e-mail fiókhoz társított címtár URI.

"Külföldön van" - gondolja. Lehet, hogy valami fontosra van szüksége." Felveszi a telefont, és a hamis Jane Roe fontos dokumentumokat kér. Elmagyarázza, hogy a készüléke elromlott, és mivel utazik, arra kéri, hogy küldje el a dokumentumokat a privát e-mail címére, jane.roe@hacker.com. Ily módon a vállalat csak miután Jane Roe visszatér az irodába, rájön, hogy fontos információk szivárogtak ki a vállalaton kívül.

Az Example.com vállalatnak számos módja van az internetről érkező csalárd hívások elleni védelmére, de a Webex felhő egyik felelőssége annak biztosítása, hogy a Webexből hívó bármely személy személyazonossága helyes legyen, és ne legyen hamisítva.

A személyazonosság ellenőrzéséhez a Webex megköveteli, hogy a vállalat igazolja, hogy a Hybrid Calling szolgáltatásban használt tartományok tulajdonosa. Ha nem, akkor a hibrid szolgáltatások nem fognak működni.

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

1. Bizonyítsa be, hogy a vállalat tulajdonában van az e-mail tartomány, Expressway-E tartomány, Címtár URI tartomány.

   • Mindezeknek a tartományoknak átirányíthatóknak és nyilvános DNS-kiszolgálók által ismertnek kell lenniük.

   • A tulajdonjog igazolásához a DNS-rendszergazdának MEG KELL adnia egy DNS-szöveges rekordot (TXT). A TXT-rekord a DNS-ben található erőforrásrekordok egy típusa, amely lehetővé teszi tetszőleges és formázatlan szöveg társítását egy állomáshoz vagy más névhez.

   • A DNS-rendszergazdának be kell írnia azt a TXT-rekordot abba a zónába, amelynek tulajdonjogát bizonyítani kell. Ezt a lépést követően a Webex felhő TXT-rekordlekérdezést végez az adott tartományra vonatkozóan.

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

   • Például a rendszergazdának bizonyítania kell, hogy ő az „example.com” tartomány tulajdonosa, ha azt szeretné, hogy a Webex Hybrid Services a tartományán működjön.

   • https://admin.webex.comsegítségével elindítja az ellenőrzési folyamatot azáltal, hogy létrehoz egy TXT-rekordot, amely megegyezik a Webex felhő által generált tokennel:

     

   • A DNS-rendszergazda ezután létrehoz egy TXT-rekordot ehhez a tartományhoz, amelynek értéke 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, a következő példában foglaltak szerint:

     

   • Ezen a ponton a felhő ellenőrizheti, hogy a tartomány TXT-rekordja example.com megegyezik-e a jogkivonattal.

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

     

   • Mivel a TXT érték megegyezik a jogkivonat értékével, ez az egyezés bizonyítja, hogy a rendszergazda hozzáadta a saját tartományához használt TXT-rekordot a nyilvános DNS-hez, és hogy övé a tartomány.

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 identitással a felhő által megbízható hitelesítésszolgáltató egyik hitelesítésszolgáltatójától. Az E gyorsforgalmi út adminisztrátorának nyilvános tanúsítványt kell kérnie az E gyorsforgalmi útról az említett hitelesítésszolgáltató hatóságának egyikéhez. A tanúsítvány kiállításához a hitelesítésszolgáltató személyazonosság-ellenőrzési folyamatot hajt végre egy tartományérvényesítési ellenőrzés (tartomány által érvényesített tanúsítványok esetében) vagy a szervezet érvényesítésének ellenőrzése (szervezet által érvényesített tanúsítványok esetében).

   • A felhőbe irányuló és onnan érkező hívások az E gyorsforgalmi útra kiadott tanúsítványtól függenek. Ha a tanúsítvány érvénytelen, a hívás el lesz dobva.

A Webex Device Connectornak kommunikálnia kell a Webexszel a Hybrid Calling működéséhez.

A Webex Device Connector a belső hálózaton van telepítve, és a felhővel való kommunikáció módja egy kimenő HTTPS kapcsolaton keresztül történik – ugyanaz a típus, mint bármely webkiszolgálóhoz kapcsolódó böngésző esetében.

A Webex Clouddal folytatott kommunikáció TLS-t használ. A TLS-ügyfél a Webex Device Connector, a Webex felhő pedig a TLS-kiszolgáló. Így a Webex Device Connector ellenőrzi a kiszolgálótanúsítványt.

A hitelesítésszolgáltató saját privát kulcsával írja alá a kiszolgálótanúsítványt. Bárki, aki rendelkezik nyilvános kulccsal, dekódolhatja az aláírást, és bizonyíthatja, hogy ugyanaz a hitelesítésszolgáltató írta alá a tanúsítványt.

Ha a Webex Device Connectornak érvényesítenie kell a felhő által biztosított tanúsítványt, akkor az aláírás dekódolásához a tanúsítványt aláíró hitelesítésszolgáltató nyilvános kulcsát kell használnia. A nyilvános kulcsot a hitelesítésszolgáltató tanúsítványa tartalmazza. A felhő által használt hitelesítésszolgáltatókkal való megbízhatóság létrehozásához a megbízható hitelesítésszolgáltatók tanúsítványainak listájának a Webex Device Connector megbízhatósági tárolójában kell lennie.

Az eszközökkel való kommunikáció során az eszköz az Ön által megadott megbízható tanúsítványokat használja. Jelenleg úgy lehet ezt megtenni, hogy a [kezdőlap]/.devicestool/certs könyvtárba helyezzük őket.

A traversal párban az E gyorsforgalmi úthoz is szükség van a hitelesítésszolgáltatói tanúsítványok listájára. Az Expressway-E a Webex felhővel SIP TLS használatával kommunikál, kölcsönös hitelesítés által kényszerítve. Az Expressway-E csak akkor megbízható a felhőből érkező és a felhőbe irányuló hívásokban, ha a felhő által a TLS-kapcsolat beállítása során bemutatott tanúsítvány CN- vagy SAN-je megegyezik az Expresswayen a DNS-zónához konfigurált tárgynévvel („callservice.webex.com”). A hitelesítésszolgáltató csak személyazonosság-ellenőrzés után bocsát ki tanúsítványt. A callservice.webex.com tartomány tulajdonjogát bizonyítani kell a tanúsítvány aláírásához. Mivel mi (a Cisco) tulajdonában van ez a tartomány, a „callservice.webex.com” DNS-név közvetlenül bizonyítja, hogy a távoli társ valóban Webex.

A naptár-összekötő egy megszemélyesítési fiókon keresztül integrálja a Webexet a Microsoft Exchange 2013, 2016, 2019 vagy az Office 365 rendszerrel. Az Exchange alkalmazás-megszemélyesítés-kezelési szerepköre lehetővé teszi az alkalmazások számára, hogy megszemélyesítsék a szervezet felhasználóit, hogy a felhasználó nevében végezzenek feladatokat. Az alkalmazás megszemélyesítési szerepkörét az Exchange-ben kell konfigurálni, és a naptár-összekötőben az Expressway-C felületen található Exchange-konfiguráció részeként kell használni.

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

A további biztonság érdekében kövesse a Cisco Webex Hybrid Calendar Service telepítési útmutatójának lépéseit, hogy engedélyezze a TLS-t a vezetékes EWS-kapcsolatok biztosításához.

A további biztonság érdekében kövesse az Expressway Calendar Connector for Microsoft Exchange lépéseit a TLS engedélyezéséhez, hogy biztosítsa a EWS-kapcsolatokat a vezetéken.