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

Ezek a pontok kulcsfontosságúak, ha sikeresen szeretné telepíteni a hibrid hívást Webex-eszközökhöz. 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 a tételeket kezelte a környezetében, a hibrid szolgáltatások konfigurációjának többi része zökkenőmentesen fog menni.

Az Expressway-C és Expressway-E páros telepítése lehetővé teszi az internetre irányuló és az internetről érkező hívásokat tűzfalbejárási technológiákhasználatával. Ez a telepítés biztonságosan összekapcsolja a helyszíni hívásvezérlést a Webex-szel.

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 hasznos szerverek közötti kapcsolatok esetén, például az Expressway-E és a Webex felhő között létrehozott hívás esetén. Ezt a koncepciót kölcsönös hitelesítéssel ellátott TLS-nek nevezik, és a Webex-szel való integrációhoz 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. 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állalatok közötti kommunikációhoz, javasoljuk, hogy a Control Hub-ban SIP-célként adjon meg a vállalati domain egy aldomainjét, és ennek következtében egy 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 

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

A vállalatközi (B2B) és mobil- és távoli hozzáférési (MRA) hívások az 5061-es portot használják SIP TLS-hez, a Webex forgalom pedig az 5062-es portot SIP TLS-hez kölcsönös hitelesítéssel.

A tartomány tulajdonjogának ellenőrzése a személyazonosság ellenőrzésének része. A domain-ellenőrzés egy biztonsági intézkedés és személyazonosság-ellenőrzés, amelyet a Webex felhő hajt végre annak igazolására, 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 domain tulajdonjogának ellenőrzésének fontossága

A Webex felhő a biztonság érvényesítése érdekében ellenőrzi a domain tulajdonjogá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 olyan cég, amelynek a DNS-tartománya „hacker.com”, megvásárolja a Webex Hybrid Services-t. 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 következővel: jane.roe@hacker.com. 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 a következő szám tárcsázásával: john.doe@example.com a Webex alkalmazásából. John az irodájában ül, és egy hívást lát a videoeszközén, ami a következő személytől érkezik: jane.roe@example.com; Ez az adott e-mail fiókhoz társított könyvtá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állalat számos módszerrel védekezik az internetről érkező csalárd hívások ellen, de a Webex felhő egyik feladata annak biztosítása, hogy a Webex-ről hívó személyek személyazonossága helyes és ne legyen hamisítva.

A személyazonosság ellenőrzéséhez a Webex megköveteli, hogy a vállalat igazolja, hogy a hibrid hívásokban használt domainek tulajdonosa. Ha nem, 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 hajt végre az adott domainhez.

   • Ha a TXT lekérdezés sikeres, és az eredmény megegyezik a Webex felhőből generált tokennel, a domain ellenőrzése megtörtént.

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

   • https://admin.webex.comA kapcsolóval elindítja az ellenőrzési folyamatot egy TXT rekord létrehozásával, amely megegyezik a Webex felhő által generált tokennel:

     

   • A DNS-adminisztrátor ezután létrehoz egy TXT rekordot ehhez a domainhez, amelynek értéke 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, ahogy az a következő példában is látható:

     

   • 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 eszközösszekötőnek 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ó módja egy kimenő HTTPS-kapcsolaton keresztül történik – ugyanazon a típusú kapcsolaton keresztül, amelyet bármely webkiszolgálóhoz csatlakozó böngésző használ.

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

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 a tanúsítványt aláíró hitelesítésszolgáltató nyilvános kulcsát kell használnia az aláírás dekódolásához. 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ó bizalom létesítéséhez a megbízható hitelesítésszolgáltatók tanúsítványainak listájának szerepelnie kell a Webex Device Connector megbízható tárolójában.

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 ezt úgy lehet megtenni, hogy [home folder]/.devicestool/certsa -be 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 SIP és TLS protokollon keresztül kommunikál a Webex felhővel, kölcsönös hitelesítéssel kikényszerítve. Az Expressway-E csak akkor bízik meg a felhőből érkező és oda irányuló hívásokban, ha a felhő által a TLS-kapcsolat beállításakor bemutatott tanúsítvány CN-je vagy SAN-ja megegyezik az Expressway DNS-zónájához konfigurált tulajdonos nevével ("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 domain tulajdonjogát igazolni kell a tanúsítvány aláírásához. Mivel a domain a miénk (Cisco), a "callservice.webex.com" DNS-név közvetlen bizonyíték arra, hogy a távoli partner valóban a 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 erre a feladatra. 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.