內容保護的每一個機制都只解決一個特定問題，而它們解決的問題彼此不重疊。DRM 不防盜連，token 不防錄屏，浮水印不阻止任何事——它只讓你事後知道是誰。把這些機制當成可互相替代的「安全等級」是最常見的設計錯誤，結果是花了 DRM 的錢卻擋不住最常見的攻擊。
這一篇先把機制與它對應的威脅一一配對，再逐項標出能力邊界。下一篇用一份真實方案把它們組起來。
📖 學
一、先分清楚兩類威脅
盜刷（unauthorized pull／leeching）——沒有付費或沒有權限的人，直接拉你的流。特徵是流量放大：一個洩漏的播放網址可能被幾萬人同時拉，你的頻寬帳單先爆。
盜播（restreaming／再分發）——合法使用者拉一條流，然後重新編碼轉播給別人。特徵是流量正常：來源端看起來就是一個正常觀眾，一路流、合理碼率，用並發規則完全看不出來。
這兩類需要完全不同的防線，這是整個內容保護領域最重要的一條分界。
| 盜刷 | 盜播 | |
|---|---|---|
| 攻擊特徵 | 流量異常放大 | 流量完全正常 |
| 主要防線 | 訪問控制（鑑權、並發、撤銷） | 內容追源（forensic 浮水印） |
| 偵測方式 | 伺服器端可直接觀測 | 必須從外部發現盜播站點再回推 |
| 能否預防 | 可以大幅壓制 | 不能預防，只能追源與縮短存活時間 |
二、訪問控制層：防盜刷
盜連（hotlinking）防護——Referer／User-Agent 檢查。這幾乎沒有安全價值，兩者都是客戶端可任意偽造的標頭。它只能擋住最低階的嵌入，不能當成訪問控制。
Signed URL / Signed Cookie——把路徑、有效期、可選的 IP 或其他條件，用 HMAC-SHA256 或 RSA/ECDSA 簽名，CDN 邊緣驗簽後才放行。各大 CDN（CloudFront、Akamai、Cloudflare）都支援。
- Signed URL 的問題是 HLS 有很多檔案：一個清單、數百個分片、多個階梯、音軌、字幕。每個都要簽會讓清單變得巨大且難以快取。
- Signed Cookie 解決這個：一次下發 Cookie，覆蓋整個路徑前綴下的所有檔案。AWS CloudFront 的文件明確把這當成多檔案授權的建議作法。
- Cookie 的代價是跨站限制：iframe 嵌入、Safari 的第三方 Cookie 政策會讓它失效。優先用同站播放網域，跨站部署必須另外驗證。
Token 鑑權（JWT）——比 signed URL 表達力更強：可以帶入使用者 ID、權限範圍、裝置綁定等宣告。
JWT 的實作陷阱很具體，RFC 8725（JWT Best Current Practices）把它們列成清單，其中最該注意的幾條：
- 固定演算法白名單，不要信任 token 自己宣告的
alg（none攻擊與 HMAC/RSA 混淆攻擊都源於此）。 - 嚴格驗證
iss、aud、exp、nbf。 - 限制
kid的取用來源，不能讓 token 指定任意 URL 去抓公鑰。 - 不同用途的 token 不可互相兌換（登入 token 不該能當播放 token 用）。
短 TTL 是對抗重放的主要手段，但它有一個關鍵限制：TTL 到期不等於斷流。見下面第五節。
地理封鎖（geo-blocking）——用 IP 歸屬地判斷。它是合約與法規的要求（授權區域），不是安全機制。VPN 與代理可以繞過；商業 VPN 偵測服務宣稱能抓到大部分已知 VPN 範圍，但誤判會直接傷害合法使用者（企業 VPN、CGNAT、跨境旅行），而誤判率沒有中立資料。實務立場：地理封鎖要做，但不要把它當成防盜的主力，也不要用單一訊號直接封鎖。
三、加密層：防「中途被撈走」
| 機制 | 保護什麼 | 不保護什麼 |
|---|---|---|
| HTTPS/TLS | 傳輸過程被竊聽 | 合法接收者之後的任何行為 |
| DTLS-SRTP（WebRTC） | RTP 媒體傳輸機密性 | 不證明觀看權限——它是傳輸層 |
| AES-128（HLS） | 整個分片加密 | 金鑰取得後的一切 |
| SAMPLE-AES / cbcs | 逐樣本加密 | 同上，但相容 FairPlay |
最重要的一句話：加密只解決「傳輸中被撈走」，不解決「拿到之後做什麼」。
HLS 的 AES-128 有一個常被忽略的弱點：金鑰是透過清單裡的 URI 取得的，如果那個 URI 沒有獨立鑑權，整個加密就是裝飾。任何能拿到清單的人也能拿到金鑰。這是「上了加密還是被盜連」的典型成因。
WebRTC 的 DTLS-SRTP 與 HLS 的內容加密是兩套完全不同的機制，不能互換也不能類比。 前者保護傳輸、每條連線協商一次；後者保護內容、金鑰可以跨連線重用。RFC 8827 對 WebRTC 的安全模型有明確定義，其中也區分了 RTP 媒體與 Data Channel 兩條路徑的保護方式。
四、DRM：加密 ＋ 授權 ＋ 強制執行
DRM 比單純加密多了三件事：金鑰由授權伺服器控制發放、解密發生在受保護環境（理想上是硬體 TEE）、可以附加使用規則（輸出保護、同時播放數、到期時間）。
三大系統：
| DRM | 平台 | 加密模式 |
|---|---|---|
| Widevine | Android、Chrome、多數智慧電視 | cenc、cbcs |
| PlayReady | Windows、Xbox、部分電視 | cenc、cbcs |
| FairPlay | Apple 全平台（iOS/macOS/tvOS/Safari） | 僅 cbcs |
FairPlay 只支援 cbcs 這一點，決定了整個打包策略。 因為 Widevine 與 PlayReady 後來也都支援 cbcs，所以 CMAF ＋ cbcs 成為「打包一次、三家通吃」的作法——這是 2026 年的生產預設，也是為什麼 打包 那篇強調 CMAF 對成本的影響。在此之前必須為 FairPlay 單獨打一份。
Widevine 的安全等級分三級（L1 硬體 / L2 / L3 軟體）。L3 在軟體中解密，可以被繞過；只有 L1 才有硬體層保護。「我們上了 Widevine」這句話沒有資訊量，必須問強制要求哪一級，以及不滿足時是降級還是拒播。
DRM 的能力邊界必須說清楚：
- 它提高媒體提取與部分螢幕截圖的難度（搭配輸出保護可以擋住部分錄製路徑）。
- 它不能阻止外部攝影機對著螢幕拍。
- 它不能在撤銷後立刻清除已經發出的授權、金鑰與已緩衝的資料——這些各有自己的生命週期。
- 它完全不防盜連：盜連發生在拿到授權之前，那是訪問控制的職責。
五、一個關鍵的機制斷層：TTL 不等於斷流
這是整個領域最容易出錯的地方，值得單獨講。
短 TTL 的 token 只能阻止「新的請求」，不能中止「已經建立的連線」。
- HLS：因為是逐分片請求，token 過期後下一個分片請求會被拒 → 效果接近「到期即停」，延遲約等於一個分片長度。
- WebRTC：連線一旦建立，媒體就在 RTP 上持續流動，不會再去問授權伺服器。token 過期對它毫無影響，可以一直播下去。
所以在 WebRTC 架構下，必須由媒體節點執行伺服器端的「租約」：節點自己維護一個到期時間，到期沒有續租就主動停止發送並關閉連線。這不是可選的優化，是唯一能真正斷流的機制。使用者提供的方案文件把這一條列為首要技術缺口（「短 Token 不會自動斷開 WebRTC」），詳見 案例拆解。
同樣的道理適用於 CDN：CDN 的簽名授權不等於即時撤銷。簽名在有效期內就是有效的，CDN 沒有辦法知道你在後台把某個 session 停權了。要做到即時撤銷，必須額外設計撤銷狀態的傳播機制。
六、浮水印：唯一能處理盜播的機制
可見浮水印（visible / UI overlay）——在畫面上疊 logo 或使用者 ID。它的作用是威懾，而且在前端 DOM/Canvas 上做的版本可以被輕易移除或裁掉。不能當成追源依據。
Forensic watermarking（鑑識浮水印）——把一個不可見的識別碼嵌進媒體本身，事後可以從盜錄的影片中還原出來，進而知道洩漏來自哪個 session。
主流作法是 A/B 變體（server-side A/B watermarking）：
每個分片準備兩個版本：A 與 B（人眼無法分辨）
為每個 session 產生一個獨特的 A/B 序列，例如 A-B-B-A-B-A-A-B...
這個序列本身就是識別碼
從盜錄影片中讀出序列 → 對回 session
一個 32 位元的載荷可以涵蓋約 43 億個 session，而需要的識別時間 = 位元數 × 分片長度（再乘以容錯重複）。這直接推出兩個結論：
- 分片越短，識別越快（這是低延遲架構的意外好處）。
- 絕對不可能「幾秒就抓到」，除非載荷極短或分片極短。供應商宣稱的識別時間必須問清楚前提。
A/B 變體的結構性限制是：它依賴「分片」這個單位。 HLS/DASH 有分片，WebRTC 沒有。所以 OTT 的浮水印方案不能直接搬到 WebRTC——WebRTC 需要在媒體鏈路上做專門整合（逐會話編碼或供應商特製方案），而那把成本模型從「每條流一次」變成「每個觀眾一次」。這是低延遲與強保護之間最大的一塊缺口，也是 hub 待解問題裡的第一條。
攻擊面：裁切、縮放、重編碼、降幀率、疊圖層、多來源合謀（拿多份不同浮水印的拷貝混合以抹除標記）。供應商必須證明在這些攻擊下的檢出率與錯歸因率——錯歸因比漏檢更危險，因為它會導致封錯人。
七、機制與威脅的對應表
| 威脅 | 有效機制 | 無效機制 |
|---|---|---|
| 複製播放網址給別人 | 短 TTL token、signed cookie、並發限制 | DRM、浮水印 |
| 多人共用一個帳號 | 全局並發租約、裝置綁定 | 加密、DRM |
| 繞過 CDN 直接打源站 | 私有源站、邊緣到源站的身份驗證 | 隱藏網址（不是安全機制） |
| 從備用網域／低碼率流繞過 | 所有入口統一鑑權 | 只保護主入口 |
| 竊聽傳輸 | TLS、DTLS-SRTP、內容加密 | — |
| 從播放器提取媒體檔 | DRM（提高難度） | 單純 AES-128（金鑰可取得） |
| 合法帳號錄屏轉播 | forensic 浮水印 ＋ 盜播發現 | DRM、加密、並發限制（全部無效） |
| 外部攝影機翻拍 | 沒有技術解法，只有浮水印追源 | 全部 |
最後兩列是重點：它們是唯一需要浮水印的場景，也是唯一 DRM 幫不上忙的場景。
八、誠實的能力邊界
沒有任何技術能阻止合法觀看者錄製內容。 螢幕擷取可以被 DRM 的輸出保護擋掉一部分，但外部攝影機永遠拍得到。所有防盜播的工程目標都應該是可量化的控制效果——縮短盜播存活時間、提高盜播成本、讓洩漏可追溯——而不是阻止捕獲。
撤銷不能收回已經送出去的內容。 已下載的分片、已緩衝的幀、已錄下的畫面，撤銷之後依然存在。驗收時必須分開量「伺服器何時停止發送」與「客戶端畫面何時停住」，這是兩個不同的數字。
任何宣稱「100% 防盜」「幾秒必然識別」的產品說明都應該要求對方提供測試方法與樣本。 分級見 主張 vs 可佐證。
🧠 記
盜刷與盜播是兩類威脅，需要兩條防線：訪問控制 vs 內容追源，不能互相替代。
Referer 檢查沒有安全價值；signed cookie 比 signed URL 更適合 HLS 的多檔案結構。
加密只解決傳輸中被撈走；AES-128 的金鑰端點若無獨立鑑權，整個加密是裝飾。
TTL 到期不等於斷流——WebRTC 必須由媒體節點執行伺服器端租約。
CDN 簽名授權不等於即時撤銷，要另外設計撤銷傳播。
FairPlay 只支援 cbcs，所以 CMAF ＋ cbcs 是打包一次通吃三家的關鍵。
浮水印是唯一能處理盜播的機制，但它依賴分片，WebRTC 沒有現成方案。
沒有技術能阻止外部翻拍；目標是縮短存活時間與可追溯，不是阻止捕獲。
✍️ 實踐
對自己的服務做一次「入口盤點」，這是最常見漏洞的來源，約 30 分鐘：
- 列出所有可以取得媒體的 URL：master 清單、各階 media 清單、初始化分片、媒體分片、音軌、字幕軌、低碼率階、備用網域、測試環境。
- 對每一個，用一個沒有有效憑證的 curl 去打：
# 應該全部回 401/403，任何一個回 200 就是洞
curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" "<每個 URL>"- 特別測三個最常漏的：AES 金鑰端點、備用網域、直接打源站（繞過 CDN）。
- 再測一次「快取命中」的情況：同一個 URL 先用合法憑證請求一次（讓它進 CDN 快取），再用無效憑證請求——如果第二次回 200，代表鑑權發生在快取之後，等於沒有鑑權。
第 4 步是最容易出事也最難發現的一項，因為用單次測試完全看不出來。
🔗 延伸學習
- IETF RFC 8725 — JSON Web Token Best Current Practices——JWT 的實作陷阱清單，演算法白名單、
kid處理、用途隔離都在這裡。 - IETF RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP)——把 bearer token 升級成發送者綁定的標準作法。
- Apple — Content Protection for HTTP Live Streaming——FairPlay 與 HLS 的格式相容要求，cbcs 的權威依據。
- AWS — CloudFront Signed Cookies 文件——多檔案私有內容授權的標準作法與它的邊界。
- IETF RFC 8827 — WebRTC Security Architecture——DTLS-SRTP 與 Data Channel 的安全模型區分。