Az Expressway-C és az Expressway-E pár üzembe helyezése lehetővé teszi az internetre és az internetről érkező hívásokat tűzfal bejárési technológiák használatával . Ez az üzembe helyezés az, ami biztonságosan veszi a helyszíni hívásvezérlést, és összekapcsolja azt a CiscoWebex-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 a kiszolgáló és a kiszolgáló közötti kapcsolaton, például az Expressway-E és a Cisco Webex felhő között létrehozott ügyeleti kapcsolaton. Ezt a koncepciót TLS-nek nevezik kölcsönös hitelesítéssel, és a Cisco Webex-szel való integrációkor 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 Cisco 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.

Business-to-business, Mobile és Remote Access és Cisco Webex forgalom ugyanazon a gyorsforgalmi úton pár

A vállalkozások és a mobil és távelérési hívások az 5061-es portot használják a SIP TLS-hez, a Cisco Webex-forgalom pedig az 5062-es portot használja a 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 Cisco Webex felhő megvalósít annak bizonyítására, hogy Ön az, akinek mondja.

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.

Egy történet, amely megmutatja a domain tulajdonjogi ellenőrzésének fontosságát

A Cisco Webex felhő elvégzi a domain tulajdonjogi ellenőrzését 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.

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.

A "hacker.com" beállított DNS-tartományú vállalat megvásárolja a Cisco 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 Cisco Webex Teams-be 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, hogy tárcsázza john.doe@example.com a Cisco Webex Teams alkalmazásából jane.roe@example.com.

"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.

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

A személyazonosság ellenőrzéséhez a Cisco Webex megköveteli, hogy a vállalat bizonyítsa, hogy rendelkezik a hibrid hívásban használt domainekkel. Ha nem, nem fog 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 követően a Cisco Webex felhő txt rekord lekérdezést hajt végre az adott tartományhoz.

   • Ha a TXT-lekérdezés sikeres, és az eredmény megegyezik a Cisco Webex felhőből létrehozott jogkivonattal, a rendszer ellenőrzi a tartományt.

   • Például a rendszergazdának bizonyítania kell, hogy a "example.com" domain tulajdonosa, ha azt akarja, hogy a Cisco Webex Hybrid Services működjön a tartományán.

   • A https://admin.webex.comkeresztül elindítja az ellenőrzési folyamatot egy TXT rekord létrehozásával, amely megfelel a Cisco Webex felhő által létrehozott tokennek:

     

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

     

   • 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.

Az Expressway-C csatlakozó állomást regisztrálni kell a Cisco Webex-nek ahhoz, hogy a hibrid szolgáltatások működjenek.

A gyorsforgalmi út a belső hálózatban van üzembe helyezve, és a felhőbe való regisztráció módja egy kimenő HTTPS-kapcsolaton keresztül történik – ugyanaz a típus, amelyet a webkiszolgálóhoz csatlakozó böngészőkhöz használnak.

A Cisco Webex felhőbe történő regisztráció és kommunikáció TLS-t használ. Az Expressway-C a TLS kliens, a Cisco Webex felhő pedig a TLS-kiszolgáló. Mint ilyen, a Gyorsforgalmi út ellenőrzi a kiszolgáló 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 Gyorsforgalmi útnak ellenőriznie kell a felhő által biztosított tanúsítványt, akkor az aláírás dekódolására 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. Ahhoz, hogy bizalmat lehessen kialakítani a felhő által használt hitelesítésszolgáltatókkal, a megbízható tanúsítványhatóságok tanúsítványlistájának az expressway bizalmi tárolójában kell lennie. Ezzel az expressz út ellenőrizheti, hogy a hívás valóban a Cisco Webex felhőből érkezik-e.

Kézi feltöltéssel feltöltheti az összes vonatkozó hitelesítésszolgáltatói tanúsítványt az Expressway-C megbízhatósági tárolójába.

Automatikus feltöltéssel maga a felhő tölti fel ezeket a tanúsítványokat az Expressway-C bizalmi tárolójába. Javasoljuk, hogy automatikus feltöltést használjon. A tanúsítványlista változhat, és az automatikus feltöltés garantálja, hogy a legfrissebb listát kapja.

Ha engedélyezi a hitelesítésszolgáltatói tanúsítványok automatikus telepítését, a rendszer átirányítja https://admin.webex.com a (felügyeleti portálra). Az átirányítást maga az Expressway-C végzi, felhasználói beavatkozás nélkül. Önnek, mint Cisco Webex rendszergazdának HTTPS-kapcsolaton keresztül kell hitelesítenie magát. Nem sokkal ezután a felhő a hitelesítésszolgáltatói tanúsítványokat az Expressway-C-be tolja.

Amíg a tanúsítványokat fel nem töltik az Expressway-C megbízhatósági tárolóba, a HTTPS-kapcsolat nem hozható létre.

A probléma elkerülése érdekében az Expressway-C elő van telepítve a Cisco Webexmegbízható hitelesítésszolgáltatói tanúsítványaival. Ezek a tanúsítványok csak a kezdeti HTTPS-kapcsolat beállítására és érvényesítésére szolgálnak, és nem jelennek meg az Expressway-C megbízhatósági listában. Miután a megbízható tanúsítványhatóságok tanúsítványait lekérte a felhőből ezen a kezdeti HTTPS-kapcsolaton keresztül, ezek a tanúsítványok platformszintű használatra állnak rendelkezésre; ezután megjelennek az Expressway-C megbízhatósági listában.

Ez a lista azokat a hitelesítésszolgáltatói tanúsítványokat mutatja, amelyeket a Cisco Webex felhő jelenleg használ. Ez a lista a jövőben változhat:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Tanúsítvány hatóság

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Főtanúsítvány Hatóság - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis gyökér CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - Csak engedélyezett használatra CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

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 Cisco Webex felhővel kommunikál a TLS-szel ellátott SIP használatával, amelyet kölcsönös hitelesítéssel kényszerítenek ki. Az Expressway-E csak akkor bízik meg a felhőből érkező és onnan é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 megegyezik az Expressway DNS-zónájához konfigurált tárgynévvel ("callservice.ciscospark.com"). A hitelesítésszolgáltató csak személyazonosság-ellenőrzés után bocsát ki tanúsítványt. A callservice.ciscospark.com tartomány tulajdonjogát igazolni kell, hogy aláírt tanúsítványt kap. Mivel mi (Cisco) birtokoljuk ezt a domaint, a "callservice.ciscospark.com" DNS-névközvetlen bizonyíték arra, hogy a távoli társ valóban Cisco Webex.

A Calendar Connector a Cisco Webexet a Microsoft Exchange 2010, 2013, 2016 vagy Az Office 365 alkalmazással integrálja egy megszemélyesítési fiókon keresztül. Az Exchange alkalmazás megszemélyesítés-kezelési szerepe lehetővé teszi az alkalmazások számára, hogy a szervezet felhasználóinak adjanak ki feladatokat a felhasználó nevében. 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 interfész Exchange konfigurációjának 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áknak nem kell ismerniük 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 adminisztrátornak root hozzáférése van az Expressway-C dobozhoz. A jelszó titkosítva tárolódik, ugyanazzal a hitelesítő titkosítási mechanizmussal, mint az Expressway-C többijelszava.

A további biztonság érdekében kövesse a Cisco Webex hibrid naptárszolgáltatás telepítési útmutatójának lépéseit a TLS engedélyezéséhez az EWS-kapcsolatok vezetéken való biztosítása érdekében.