Hybrid Services 部署的重要項目

本區段額外提供了與 Cisco Webex Hybrid Services 相關的重要設定項目的內容。

如果您想成功部署Expressway託管，這些要點至關重要 Cisco Webex Hybrid Services， 如 混合通話服務 和混合日曆服務。 出於下列原因，我們著重強調這些要點：

  • 我們想要解釋這五個要點，以便您瞭解它們在混合部署中的角色，打消疑慮。

  • 它們是必要條件，確保在雲端與內部部署環境之間安全部署。

  • 它們應該視為前置零日活動： 較之一般設定，它們在使用者介面中的完成時間稍微長一些，因此要留出一些時間讓這些項目排序。

  • 在環境中給這些項目定址後，餘下的 Cisco Webex Hybrid Services 設定將會順利進行。

內部防火牆上的 TCP 埠 5062

Expressway-C 及 Expressway-E 配對部署允許使用防火牆遍訪技術進行網際網路通話。 此部署會安全接管內部部署通話控制，並將其連結至 Cisco Webex。

由於防火牆遍訪架構，Expressway-C 及 Expressway-E 不要求在非管制區 (DMZ) 防火牆中開放任何輸入埠。 但必須在網際網路防火牆上開放 TCP SIP 訊號輸入埠及 UDP 媒體輸入埠，才能讓來電進入。 必須留出時間，在企業防火牆上開放適當的埠。

下圖顯示了防火牆遍訪架構：

例如，對於使用 SIP 通訊協定的入埠企業對企業 (B2B) 通話，必須在外部防火牆上開放 TCP 埠 5060 和 5061（5061 用於 SIP TLS），同時還開放用於服務（例如語音、視訊、內容共用、雙視訊等）的 UDP 媒體埠。 要開放哪些媒體埠取決於並行呼叫數及服務數。

可以將 Expressway 上的 SIP 接聽埠設定為介於 1024 和 65534 之間的任何值。 同時，必須在公用 DNS SRV 記錄中公告此值及通訊協定類型，而且必須在網際網路防火牆上開啟這個值。

雖然 SIP TCP 的標準是 5060，而 SIP TLS 的標準是 5061，但不會阻止使用其他埠，如下列範例所示。

範例

在此範例中，我們假定埠 5062 用於入埠 SIP TLS 呼叫。

包含兩個 Expressway 伺服器的叢集的 DNS SRV 記錄看起來類似如下：

_sips._tcp.example.com SRV 服務位置：

優先順序 = 10

權數 = 10

埠 = 5062

SVR 主機名稱 = us-expe1.example.com

_sips._tcp.example.com SRV 服務位置：

優先順序 = 10

權數 = 10

埠 = 5062

SVR 主機名稱 = us-expe2.example.com

這些記錄表示通話會以相等負載共用（優先順序和權數）導向至 us-expe1.example.com 和 us-expe2.example.com，其中使用 TLS 作為傳輸類型，且使用 5062 作為接聽埠號。

如果裝置位於網路外部（在網際網路上）並且對公司網域使用者 (user1@example.com) 進行 SIP 呼叫，則必須查詢 DNS 以瞭解要使用的傳輸類型、埠號、流量負載共用的方式以及呼叫傳送至的 SIP 伺服器。

如果 DNS 項目包含 _sips._tcp，則項目會指定 SIP TLS。

TLS 是用戶端/伺服器通訊協定，在最常見的實作中，使用憑證進行驗證。 在企業對企業通話情境中，TLS 用戶端是呼叫裝置，而 TLS 伺服器是被呼叫裝置。 藉由 TLS，用戶端會檢查伺服器的憑證，如果憑證檢查失敗，則會中斷通話連線。 用戶端不需要憑證。

下圖顯示了 TLS 交握：

然而，TLS 規格說明伺服器也可以在 TLS 交握通訊協定期間，透過將「憑證要求」訊息傳送至用戶端來檢查用戶端憑證。 此訊息對於伺服器到伺服器連線很有用，例如在 Expressway-E 和 Cisco Webex 雲端之間建立通話。 此概念稱為雙向驗證的 TLS，在與 Cisco Webex 整合時是必要的。

呼叫方及被呼叫方都會檢查另一方的憑證，如下圖所示：

雲端會檢查 Expressway 身分，而 Expressway 會檢查雲端身分。 比方說，如果憑證中的雲端身分（CN 或 SAN）與 Expressway 上的設定不相符，則連線會中斷。

如果開啟雙向驗證，則 Expressway-E 總是會請求用戶端憑證。 因此，Mobile and Remote Access (MRA) 將無法運作，因為在大多數情況下，憑證不會部署在 Jabber 用戶端上。 在企業對企業情境中，如果呼叫實體無法提供憑證，則會中斷呼叫連線。

我們建議您將 5061 以外的值用於雙向驗證的 TLS，例如埠 5062。 Cisco Webex 混合服務使用 B2B 所使用的同一 SIP TLS 記錄。 如果是埠 5061，則其他無法提供 TLS 用戶端憑證的服務就無法運作。

企業對企業、Mobile and Remote Access 及 Cisco Webex 流量位於相同 Expressway 配對上

企業對企業及 Mobile and Remote Access 通話將埠 5061 用於 SIP TLS，而 Cisco Webex 流量將埠 5062 用於雙向驗證的 SIP TLS。

為什麼雲端會檢查網域所有權

在身分驗證程序中檢查網域所有權。 網域驗證是由 Cisco Webex 雲端實作的安全措施及身份檢查，用以證明您的身份。

分兩個階段執行身分檢查：

  1. 網域所有權檢查。 此步驟涉及三種網域，而且是一次性驗證檢查：

    • 電子郵件網域

    • Expressway-E DNS 網域

    • 目錄 URI 網域

  2. Expressway-E DNS 名稱所有權檢查。 透過實作雙向驗證的 TLS來執行此步驟，並且此步驟涉及在雲端及 Expressway 上使用公用憑證。 和網域身分檢查不同，此步驟是在呼叫雲端以及接聽來自雲端的呼叫期間執行。

顯示網域所有權檢查之重要性的故事

Cisco Webex 雲端會執行網域所有權檢查以強制執行安全性。 如果不執行此檢查，則身分盜竊是一種可能的威脅。

下列故事詳細說明了不執行網域所有權檢查時可能發生的情況。

DNS 網域設定為「hacker.com」的公司購買 Cisco Webex Hybrid Services。 另一家公司將自己的網域設定為「example.com」，也使用混合服務。 公司 Example.com 的一個總經理姓名是 Jane Roe，具有目錄 URI jane.roe@example.com。

Hacker.com 公司的管理員將她的其中一個目錄 URI 設為 jane.roe@example.com 並且將電子郵件地址設為 jane.roe@hacker.com。 她可以這樣做的原因是在本範例中，雲端不會檢查 SIP URI 網域。

接下來，她使用 jane.roe@hacker.com 來登入 Cisco Webex Teams。 因為她擁有網域，所以驗證電子郵件可以被閱讀及回覆，然後她可以登入。 最後，她透過從 Cisco Webex Teams 應用程式撥打 john.doe@example.com，給同事 John Doe 打電話。John 正坐在他的辦公室中，看到他的視訊裝置上有來自 jane.roe@example.com 的呼叫；這是與該電子郵件帳戶相關聯的目錄 URI。

「她出國了，」他想。 「她可能需要一些重要的東西。」 他接聽了電話，而假 Jane Roe 要了一些重要文件。 她解釋說她的裝置已毀損，但因為她在旅行，所以要他傳送文件至她的私人電子郵件地址 jane.roe@hacker.com。 這樣，公司只有在 Jane Roe 回到辦公室後才會意識到有重要資訊洩漏到公司外部。

公司 Example.com 可以採用許多方法來防範來自網際網路的詐騙電話，但 Cisco Webex 雲端的其中一項責任是確保從 Cisco Webex 呼叫的任何人的身份正確，不是偽造的。

為了檢查身分，Cisco Webex 會要求公司證明它擁有混合呼叫中使用的網域。 否則， 將不會運作。

需要執行兩個網域驗證步驟，以確保此所有權：

  1. 證明公司擁有電子郵件網域、Expressway-E 網域、目錄 URI 網域。

    • 所有這些網域對於公用 DNS 伺服器而言必須可路由並且已知。

    • 若要證明所有權，DNS 管理員必須輸入 DNS 文字記錄 (TXT)。 TXT 記錄是 DNS 中的資源記錄類型，可以用來將部分任意未格式化文字與主機名稱或其他名稱相關聯。

    • DNS 管理員必須在其所有權必須經過證明的區域中輸入該 TXT 記錄。 在該步驟後，Cisco Webex 雲端會針對該網域執行 TXT 記錄查詢。

    • 如果 TXT 查詢成功，而且結果與從 Cisco Webex 雲端產生的權杖相符，則會驗證網域。

    • 比方說，如果她想要 Cisco Webex Hybrid Services 在她的網域「example.com」上運作，則管理員必須證明她擁有該網域。

    • 藉由 https://admin.webex.com ，她開始執行驗證程序，方式是建立 TXT 記錄以比對 Cisco Webex 雲端所產生的權杖：
    • 然後，DNS 管理員為此網域建立 TXT 記錄，並將值設為 123456789abcdef123456789abcdef123456789abcdef123456789abcdef，如下列範例所示：

    • 此時，雲端可以驗證網域 example.com 的 TXT 記錄是否與權杖相符。

    • 雲端會執行 TXT DNS 查找：

    • 因為 TXT 值與權杖值相符，所以此相符證明了管理員已將她自己的網域 TXT 記錄新增至公用 DNS，而且她擁有該網域。

  2. Expressway-E DNS 名稱所有權檢查。

    • 雲端必須檢查 Expressway-E 具有雲端信任的其中一個憑證授權單位所確認的身分。 Expressway-E 管理員必須向其中一個憑證授權單位申請其 Expressway-E 的公用憑證。 為了頒發憑證，憑證授權單位會根據網域驗證檢查（針對網域驗證的憑證）或組織驗證檢查（針對組織驗證的憑證）執行身分驗證程序。

    • 呼叫雲端及從雲端呼叫相依於已頒發給 Expressway-E 的憑證。 如果憑證無效，則通話會中斷。

支援的憑證授權單位

必須向 Cisco Webex 註冊 Expressway-C 連接器主機，才能使 Hybrid Services 運作。

Expressway-C 已部署在內部網路中，而且向雲端註冊 Expressway-C 的方式是透過出埠 HTTPS 連線 — 此類型用於與 Web 伺服器相連的任何瀏覽器。

使用 TLS 向 Cisco Webex 雲端註冊並與其通訊。 Expressway-C 是 TLS 用戶端，而 Cisco Webex 雲端是 TLS 伺服器。 這樣，Expressway-C 會檢查伺服器憑證。

憑證授權單位會使用其自己的私密金鑰來簽署伺服器憑證。 具有公開金鑰的任何人都可以解碼該簽章，並證明該憑證是由相同的憑證授權單位簽署。

如果 Expressway-C 必須驗證雲端提供的憑證，則必須使用對該憑證進行簽署之憑證授權單位的公開金鑰來解碼簽章。 公開金鑰包含在憑證授權單位的憑證中。 若要與雲端所使用的憑證授權單位建立信任，則這些信任憑證授權單位的憑證清單必須位於 Expressway 的信任儲存庫中。 這樣，Expressway 就可以驗證呼叫是否真的來自 Cisco Webex 雲端。

藉由手動上傳，您可以將所有相關憑證授權單位憑證上傳至 Expressway-C 的信任儲存庫。

藉由自動上傳，雲端本身會上傳 Expressway-C 信任儲存庫中的那些憑證。 我們建議您使用自動上傳。 憑證清單可能會變更，並且自動上傳會保證您取得最新的清單。

如果您允許自動安裝憑證授權單位憑證，則會將您重新導向至 https://admin.webex.com（管理入口網站）。 重新導向是由 Expressway-C 本身完成，使用者無需干預。 作為 Cisco Webex 管理員，您必須透過 HTTPS 連線進行驗證。 之後不久，雲端會將 CA 憑證推送至 Expressway-C。

只有在將憑證上傳至 Expressway-C 信任儲存庫之後，才能建立 HTTPS 連線。

為了避免此問題，Expressway-C 會預先安裝 Cisco Webex 信任的 CA 憑證。 這些憑證只用來設定並驗證初始 HTTPS 連線，而且它們並不出現在 Expressway-C 信任清單中。 一旦透過此初始 HTTPS 連線從雲端提取信任憑證授權單位的憑證後，這些憑證便可以在平台範圍使用；然後，它們會出現在 Expressway-C 信任清單中。

此程序是安全的，原因如下：

  • 需要 Expressway-C 及 https://admin.webex.com 的管理員存取權。 這些連線使用 HTTPS，而且會加密。

  • 憑證是使用相同的加密連線，從雲端推送至 Expressway。

此清單顯示了 Cisco Webex 雲端目前使用的憑證授權單位憑證。 此清單將來可能會變更：

  • 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 Certificate Authority

  • C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

  • C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

  • C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - 僅供授權使用, CN=thawte Primary Root CA

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

遍訪配對中的 Expressway-E 也需要憑證授權單位憑證的清單。 Expressway-E 透過將 SIP 與由雙向驗證強制執行的 TLS 搭配使用，與 Cisco Webex 雲端進行通訊。 只有在 TLS 連線設定期間雲端所提供憑證的 CN 或 SAN，與設定給 Expressway 上 DNS 區域的主體名稱（「callservice.webex.com」）相符時，Expressway-E 才會信任進出雲端的呼叫。 只有在進行身分檢查之後，憑證授權單位才會發行憑證。 必須證明 callservice.webex.com 網域的所有權才能簽署憑證。 因為我們 (Cisco) 擁有該網域，所以 DNS 名稱「callservice.webex.com」可以直接證明遠端那一方真的是 Cisco Webex。

Exchange 模仿帳戶

行事曆連接器 透過模仿帳戶，將 Cisco Webex 與 Microsoft Exchange 2010、2013、2016 或 Office 365 整合。 Exchange 中的應用程式模仿管理角色可讓應用程式模仿組織中的使用者，以代表使用者執行任務。 應用程式模仿角色必須在 Exchange 中設定，而且用在 行事曆連接器 中，作為 Expressway-C 介面上 Exchange 設定的一部分。

Exchange 模仿帳戶是 Microsoft 為此任務推薦的方法。Expressway-C 管理員不需要知道密碼，因為 Exchange 管理員可以在 Expressway-C 介面中輸入此值。 密碼不會以明文顯示，即使 Expressway-C 管理員具有 Expressway-C 產品的 root 存取權亦如此。 該密碼使用與 Expressway-C 上其他密碼相同的認證加密機制來加密儲存。

為獲得額外的安全性，請遵循 Cisco Webex 混合行事曆服務的部署指南中的步驟，以啟用 TLS 以便保護 EWS 的有線連線。