安全性概觀
Microsoft eCDN 是符合 M365 規範的服務。 這表示它會遵循任何其他 M365 服務所維護的所有相同安全性標準。
本檔強調幾篇適用于視訊串流傳遞的安全性專屬文章。
Microsoft eCDN 是混合式解決方案,這表示 Microsoft eCDN 會與傳統 HTTP 伺服器結合使用,同時仍會利用現有的安全性基礎結構 (已就緒的權杖、金鑰、Cookie 等 ) 。
就通訊而言,有兩個主要通道:
在對等之間;對等會透過 WebRTC 資料通道彼此連線,這是透過 DTLS 加密使用 SCTP 通訊協定的安全通道。
在每個檢視器與 Microsoft eCDN 後端之間,透過使用 TLS 加密的安全 WebSocket 連線。
這兩個通道都使用業界標準的網路安全性通訊協定,因此在兩個檢視者之間傳送的資料,或在每個檢視器與服務後端之間傳送的中繼資料都無法遭到入侵。
除了上述功能之外,服務還具有可根據個別需求啟用的其他安全性功能,如下所述。
檢視器驗證
一般而言,任何檢視器都可以連線到 Microsoft eCDN 後端,並參與 P2P 網路。 這在大部分的使用案例中是可接受的,但有些客戶可能偏好限制哪些檢視者可以連線到服務。
在這些情況下,後端可以直接驗證檢視者,以及可能已經存在於內容提供者端的任何驗證機制。 Microsoft eCDN 已備妥驗證機制,可防止未經授權的檢視者存取點對點網路上存在的內容和任何中繼資料。
網域允許清單
封鎖大部分不想要的檢視者參與對等互連的最快且最簡單方式,是明確允許列出檢視器可從中連線到服務後端的特定網域。 這表示會封鎖嘗試從其他非允許清單網域連線到服務的檢視者。
逐步指南:
移至管理主控台中的協力廠商平臺設定 頁面 。
在 [網站允許清單] 方塊) (載入服務腳本的網域,如下所示。
這就對了! 任何嘗試從未列出的網域連線到具有租使用者識別碼之服務的檢視器都會遭到封鎖。
終端使用者 IP 允許清單
系統管理員可以封鎖不想要的檢視者參與對等互連的另一個方法是只允許從預先定義的公用 IP 清單存取服務。 這類似于上述的「網域允許清單」功能,但這次我們允許將檢視者的公用 IP 列入清單。
逐步指南:
移至管理主控台中的 [安全性設定 ] 頁面 。
在 [使用者 IP 允許清單] 方塊中,以其中一種支援的格式新增所需的公用 IP 或 IP 範圍,如下所示。
這就對了! 任何嘗試以您的租使用者識別碼與不允許 IP 連線到服務的檢視器都會遭到封鎖。
支援的格式:
單一 IP - 在新行中輸入每個 IP,或按一下每個 IP 後面的 [新增 IP] 按鈕,逐一新增 IP。 範例:1.1.1.1
CIDR - 輸入 CIDR,代表您想要列入允許清單的 IP 範圍。 範例:1.1.1.1/24
JSON (以外的所有格式,必須自行新增) 可以混合並比對,方法是以新行分隔它們。
內容保護
大部分平臺都有多種方式可防止存取不想要的檢視者來保護串流。 Microsoft eCDN 會辨識這點,因此不會變更任何現有的內容保護機制。
如同沒有 Microsoft eCDN,每個使用者必須向伺服器驗證自己,而且只有在驗證成功時,伺服器才會將資訊清單檔案傳送至檢視器,而檢視者會接著開始要求區段播放資料流程。
以下是最常見的保護設定清單:
會話啟動時的驗證
在此情況下,每個會話都是從要求檢視器提供其認證的伺服器開始。 如果這些認證有效,伺服器會將資訊清單檔案傳送至檢視器,而視訊播放程式會開始向 HTTP 伺服器要求區段和其他資訊清單。 Microsoft eCDN 不會將自己插入此驗證程式,而且無論是否部署 Microsoft eCDN,檢視器都必須通過相同的驗證閘道。 只有獲授權watch特定資料流程的檢視者可以參與該資料流程的 P2P 共用,而且他們只會在實際監看串流時共用。
資訊清單 URI 權杖化
Microsoft eCDN 也遵守資訊清單層級上存在的任何現有 URI 權杖化機制。
使用 Microsoft eCDN 時,所有資訊清單要求都會直接傳送至 HTTP 伺服器,因此會以相同方式對平臺後端進行驗證。
URI 定時權杖化
在此情況下,資訊清單 URL 具有額外的權杖,其會將檢視器使用者代理程式的詳細資料編碼 (IP 位址、到期時間等 ) 。 惡意使用者可以將資訊清單 URL 散發給未經授權的檢視者,但這些檢視者將無法存取資料流程,因為資訊清單 URL 已權杖化,且 HTTP 伺服器拒絕任何驗證嘗試 - 可能是因為 IP 位址或其他使用者代理程式不相符,或因為時間過期。 使用 Microsoft eCDN 時,所有資訊清單要求都會直接傳送至 HTTP 伺服器,因此驗證無法遭到入侵。
加密
透過內容加密,使用者必須就地完成現有的驗證,並存取解密金鑰。 Microsoft eCDN 無法存取解密金鑰,也不會變更其散發和保護的方式。 Microsoft eCDN 與不同的內容保護設定和支援標準無關,例如 AES-128。
例如,假設 HLS 資料流程受到 AES-128 加密保護,未經授權的檢視者將無法watch資料流程,因為他們無法存取解密金鑰。
金鑰可以透過許多方式傳送給使用者,例如,透過資訊清單、與頁面配套,或甚至使用自訂程式碼動態要求。
Microsoft eCDN 不會將自己插入此程式,而且無論是否部署 Microsoft eCDN,金鑰都會使用相同的機制傳遞給視訊播放程式。
Drm
DRM 使用案例與加密使用案例類似,唯一的差異在於授權和金鑰是由 DRM 機制散發,而不是由廣播者散發。 此外,Microsoft eCDN 也不會干擾授權或金鑰的散發,因此不會危害它們。