部署 Cisco Spark Hybrid Services 之前要準備的五個重要事項

Document created by Cisco Localization Team on Feb 4, 2017
Version 1Show Document
  • View in full screen mode
 

為什麼這五個要點對於 Cisco Spark Hybrid Services 部署很重要

 

本文件額外提供了與 Cisco Spark Hybrid Services 相關的五個重要設定項目的背景。

  

如果要成功部署 Expressway 託管的 Cisco Spark Hybrid Services(「通話服務感知」、「通話服務連線」及「行事曆服務」),這五個要點很重要。 出於下列原因,我們著重強調這五個要點:

  
  •  

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

      

  •  

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

      

  •  

    它們應該視為零日活動: 較之一般設定,它們在使用者介面中的對齊時間稍微長一些,因此要留出一些時間讓這些項目排序。

      

  •  

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

      

  

內部防火牆上的 TCP 埠 5062

 

Expressway-C 及 Expressway-E 配對部署允許使用防火牆遍訪技術進行網際網路通話。 此部署透過 Cisco Collaboration Cloud,將您的內部部署通話控制與 Cisco Spark 安全地連結在一起。

由於防火牆遍訪架構,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.comus-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 Collaboration Cloud 之間建立通話。 此概念稱為雙向驗證的 TLS,在與 Cisco Spark 整合時是必要的。

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


 

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

 

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

 

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

     

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

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

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

在身分驗證程序中檢查網域所有權。 網域驗證是由 Cisco Collaboration Cloud 實作的安全措施及身分檢查,用以證明您的身分。

 

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

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

     

    • 電子郵件網域

       

    • Expressway-E DNS 網域

       

    • 目錄 URI 網域

       

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

     

       

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

Cisco Collaboration Cloud 會執行網域所有權檢查以強制執行安全性。 身分盜竊是可能的威脅,但不在此檢查的範圍內。

 

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

 

DNS 網域設定為「hacker.com」的公司購買了 Cisco Spark Hybrid Services。 另一家公司將自己的網域設為「example.com」,也使用 Hybrid Services。 公司 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 Spark。 因為她擁有網域,所以驗證電子郵件可以被閱讀及回覆,然後她可以登入。 最後,她可以透過從 Cisco Spark 用戶端撥打 john.doe@example.com,給同事 John Doe 打電話。 John 正坐在他的辦公室中,看到他的視訊裝置上有來自 jane.roe@example.com 的呼叫;這是與該電子郵件帳戶相關聯的目錄 URI。

 

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

 

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

 

為了檢查身分,Cisco Spark 會要求公司證明它擁有 Spark 混合通話中使用的網域。 如果不能證明,則 Cisco Spark Hybrid Services 無法運作。

 

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

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

      

    •  

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

        

    •  

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

        

    •  

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

        

    •  

      如果 TXT 查詢成功,而且結果與從 Cisco Collaboration Cloud 產生的權杖相符,則會驗證網域。

        

    •  

      例如,如果她想要 Cisco Spark 和 Cisco Spark Hybrid Services 在她的網域「example.com」上運作,則管理員必須證明她擁有該網域。

        

    •  
      藉由管理入口網站,她開始執行驗證程序,方式是建立 TXT 記錄以比對 Cisco Collaboration Cloud 所產生的權杖:


        
    •  
      然後,DNS 管理員為此網域建立 TXT 記錄,並將值設為 123456789abcdef123456789abcdef123456789abcdef123456789abcdef,如下列範例所示:


        
    •  

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

        

    •  
      雲端會執行 TXT DNS 查找:


        
    •  

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

        

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

      

    •  

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

        

    •  

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

        

    

支援的憑證授權單位

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

 

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

 

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

 

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

 

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

 

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

 

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

 

如果您允許自動安裝憑證授權單位憑證,則會將您重新導向至 Cisco Cloud Collaboration Management(管理入口網站)。 重新導向是由 Expressway-C 本身完成,使用者無需干預。 作為 Cisco Spark 管理員,您必須透過 HTTPS 連線進行驗證。 之後不久,雲端會將 CA 憑證推送至 Expressway-C。

 

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

 

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

 
此程序是安全的,原因如下:
  •  

    需要 Expressway-C 及 Cisco Cloud Collaboration Management 的管理員存取權 (admin.ciscospark.com)。 這些連線使用 HTTPS,而且會加密。

      

  •  

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

      

   

此清單顯示了 Cisco Collaboration Cloud 目前使用的憑證授權單位憑證。 此清單將來可能會變更:

  • 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 Collaboration Cloud 進行通訊。 只有在 TLS 連線設定期間雲端所提供憑證的 CN 或 SAN,與設定給 Expressway 上 DNS 區域的主體名稱(「callservice.ciscospark.com」)相符時,Expressway-E 才會信任進出雲端的呼叫。 只有在進行身分檢查之後,憑證授權單位才會發行憑證。 必須證明 callservice.ciscospark.com 網域的所有權才能簽署憑證。 因為我們 (Cisco) 擁有該網域,所以 DNS 名稱「callservice.ciscospark.com」可以直接證明遠端那一方真的是 Cisco Collaboration Cloud。

 

Exchange 模仿帳戶

 

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

Exchange 模仿帳戶是 Microsoft 針對此任務建議的方法。 使用模仿帳戶透過 Exchange Web 服務 (ESW) 進行存取是安全的,因為:

  • 存取權未提供給使用者,而且可以在線路上透過 TLS 來保護 EWS 連線。

     

  • 只能透過 EWS 來使用帳戶;如果使用者可以存取具有模仿權限的帳戶,則將需要撰寫 EWS 應用程式來存取使用者的信箱,並且無法透過信箱用戶端來直接存取信箱。

     

  • 模仿帳戶密碼以加密形式儲存在 Expressway-C 上。

     

  

因此,Expressway-C 管理員不需要知道密碼,因為 Exchange 管理員可以在 Expressway-C 介面中輸入此值。 密碼不會以明文顯示,即使 Expressway-C 管理員具有 Expressway-C 產品的 root 存取權亦如此。

 

安全性會確保僅 Expressway-C 應用程式使用該密碼。

 

多重 Expressway 部署

Expressway-C 連接器主機最多可以與六個伺服器形成一個叢集。 在多個 Unified CM 叢集位於不同區域的情境中,您可以部署多個 Expressway-C 叢集(每個 Unified CM 叢集一個 Expressway-C 叢集),僅提供區域備援。 如果其中一個 Expressway-C 節點關閉,則叢集中的其他節點會連線至 Cisco Collaboration Cloud 及 Unified CM。 目前無法提供地理性備援。

用於 SIP 信號和媒體的 Expressway-C 及 Expressway-E

   

您的多個 Expressway-C 及 Expressway-E 叢集可以位於不同區域。 Unified CM 使用最近的 Expressway 叢集,根據分割區和呼叫搜尋空間設定,進行從 Unified CM 到 Cisco Collaboration Cloud 的外撥呼叫。

  

對於撥入呼叫,您必須瞭解如何在網際網路邊緣的不同 Expressway-E 叢集之間分割流量。

  
  •  

    如果網際網路邊緣部署在相同的資料中心或者相同區域,則可能會在 DNS SRV 層級進行負載平衡。 例如,如果企業網路包含三個用於 Spark 混合通話的網際網路邊緣(每個邊緣所含的叢集有兩個 Expressway-E 和 Expressway-C 節點),則 _sips._tcp.example.com 將包含所有六個 Expressway-E 記錄(3 個 Expressway-E 乘以 2),它們的優先順序和權數相同。 此設定會在各個 Expressway-E 及 Expressway-C 叢集上平均分配來自 Cisco Collaboration Cloud 的通話。

      

  •  

    如果跨不同的區域部署網際網路邊緣,則最佳解決方案是使用 Geo DNS 服務。

      

    Geo DNS 服務是由許多 DNS 提供者提供,根據 Geo DNS 的能力來檢查來源 IP 位址、瞭解該 IP 位址所屬的國家或地區,以及將要求轉遞至物理位置最靠近該區域的邊緣。 請注意,給 Expressway-E 撥打的混合通話來自 Cisco Collaboration Cloud,而不是直接來自 Spark 用戶端。 因此,來源 IP 位址是 Cisco Collaboration Cloud 使用的其中一個 IP 位址。

      

    根據此分類以及 Geo DNS 上的設定,通話會傳送至物理位置最接近呼叫 IP 位址所屬區域的 Expressway-E。

      

  
例如,AWS Geo DNS 服務是使用下列方式進行設定:


  

建立 SRV 記錄後,便會套用「位置」標籤並指定國家/地區。 來自雲端且 IP 位址屬於相同位置(本範例為義大利)的呼叫會傳送至 emea-expe1.example.com。 可以根據區域數來建立許多 SRV 記錄。

  

Geo DNS 設定取決於 DNS 提供者,而且此設定範例僅供參考之用。

  
如果是兩個不同的 Expressway-C 及 Expressway-E 叢集部署在 US(美國)和 EMEA(歐洲、中東、非洲),則 DNS SRV 記錄 _sips._tcp.example.com 會設定為屬於兩個不同的區域。 使用 AWS 需要 _sips._tcp.example.com 的兩個 DNS SRV 記錄,如下列範例所示:


  

這樣,離開 US Cisco Collaboration Cloud 的通話會進入 US 的 Expressway-E,而且只有在 US 的 Expressway-E 叢集不可用時,才會使用 EMEA 的 Expressway-E 叢集。 如果通話離開 EMEA 的 Cisco Collaboration Cloud,則會進入位於 EMEA 的 Expressway-E 叢集,而且只有在 EMEA 叢集不可用時,才使用 US 叢集。

  
 

Attachments

    Outcomes