架構
SDP v3.0 改了什麼：從單封包授權到身分原生
2026 年 5 月，雲端安全聯盟（CSA）把《軟體定義邊界架構指南》更新到 SDP v3.0。如果你正在評估 ZTNA，這份文件值得看的理由不是它又列了一次零信任原則，而是它把一件事寫死了：單封包授權不再是 SDP 的定義。
這句話聽起來像規格書內部的措辭調整，實際上它決定了招標文件該怎麼寫。過去幾年，「有沒有 SPA」幾乎是判斷一套產品算不算真 SDP 的唯一問法；v3.0 之後，這個問法會漏掉一整類實作，也會讓一些其實沒做到零信任的東西過關。
這篇文章拆的是新版改了哪幾件事、為什麼改，以及改完之後評估與導入要跟著調整什麼。SDP 本身的三個角色與運作流程寫在軟體定義邊界（SDP）是什麼、怎麼運作，這裡不重複。
SDP v3.0 到底改了哪幾件事
SDP v3.0 於 2026 年 5 月 5 日發布，相對於 2022 年的 v2.0 規格，改動集中在「SDP 是什麼」這個層級，而不是參數與欄位。以下是七項主要變更，以及它們各自會影響你哪一份文件。
| 改了什麼 | 具體內容 | 影響到你的哪一份文件 |
|---|---|---|
| 以身分為中心 | 從「使用者到應用」擴張為「任何實體到任何實體」 | 架構藍圖與身分治理範圍 |
| 實作機制不只一種 | 從 SPA 單一路徑改為含身分原生覆蓋網路等多種做法 | 招標書的技術評估條件 |
| 使用場景大幅擴張 | 納入 AI／ML、代理式 AI、IoT、OT、邊緣與混合多雲 | 導入範圍與分期規劃 |
| 實作框架結構化 | 交易流探索、政策生成、持續驗證都有可重複的步驟 | 導入計畫與驗收標準 |
| 引入自動化與 AI 輔助 | 流量自動探索、政策建議、漂移偵測與生命週期管理 | 維運人力估算與稽核流程 |
| 補上實務部署範式 | 給出實際部署模式與範例，而非只有原則 | 架構決策紀錄 |
| 釐清架構定位 | 明確界定 SDP 在零信任裡的位置與邊界 | 對經營層與稽核單位的說明 |
其中第二項是真正的分水嶺，後面整整兩節都在談它。
為什麼靜態邊界撐不住：問題出在生命週期
固定的網路邊界不是被雲端「取代」了，是被生命週期淘汰的。混合雲、行動辦公、IoT 與營運技術設備、跨區部署的應用程式，加上 AI／ML 工作負載，這些東西共同的特徵不是分散，而是短暫。
容器在幾秒內擴出又銷毀；無伺服器函式為了一次請求而存在；代理式 AI 會自主跨網域呼叫外部 API 與內部服務，一段工作流裡可能生出十幾個臨時身分。靜態控制面對這種節奏會發生兩件事：手寫的防火牆規則與存取控制清單持續累積成難以稽核的規則叢林，而規則與實際環境之間則出現策略漂移——清單上還開著的那條路，對應的工作負載已經不在了。
傳統遠端存取的另一半問題是隱式信任：只要通過邊界驗證，內網就預設可信。這個假設讓一組被盜的憑證可以直接換成橫向移動的起點。零信任架構要拆掉的就是這個預設，NIST 與 CISA 零信任成熟度模型都把它列為第一條原則。SDP 拆它的方式是把順序倒過來：先認證，後連線；認證不過，資源在網路上等於不存在。
SDP v3.0 沒有改掉這個前提。它改的是達成這個前提的手段可以有幾種。
單封包授權從「定義」降級為「其中一種機制」
單封包授權（SPA）用一個帶密碼學保護的訊息完成預先授權，在驗證通過之前，受保護的服務對外完全不回應。驗證通過之後才輪到雙向 TLS（mTLS）建立實際的資料連線。它擋掉的是偵察階段：服務探測、連接埠掃描、以及針對未修補服務的自動化利用，全部在連線建立之前就失效。這套機制在 v3.0 裡仍然是有效的，只是它被還原成它本來的身分——一種實作技術。
v3.0 明確列出了 SPA 在現代環境裡的五項限制：
- 需要專用用戶端。 BYOD 裝置與資源受限的 IoT 設備往往裝不上。
- NAT 與防火牆穿越。 以 UDP 承載的 SPA 在受限網路可能直接被丟掉，需要 TCP 或 HTTPS 的備援路徑。
- 金鑰外洩的波及面。 共享密鑰模型一旦外流，必須協同換鑰。
- 高頻工作負載的開銷。 每條連線都要付一次成本，對短連線與高頻率的服務互動而言太重。
- 維運可見性。 「暗」的服務也讓自己人難以排錯，監控要另外設計。
這些限制推動實作往「連線定義、身分原生」的方向走。v3.0 具名納入了兩條路徑：網路基礎設施隱藏協定（NHP）把握手搬到會話層，用 Noise 協定框架與基於身分的密碼學取代共享密鑰，隱藏的範圍從連接埠擴大到網域與 IP；身分原生連線（IFC）則放棄以 IP 為中心的思維，把身分、服務與政策當成主要抽象，並提供 SDK 讓零信任直接嵌進應用程式裡。
- 逐連線的授權動作
- 持續存在的身分隧道
- 端點持有的密碼學身分
圖說文字版
同一個「先認證，後連線」的要求，兩種實作路徑的結構差異：單封包授權逐連線重跑，身分原生覆蓋網路登錄一次之後由身分決定可達性。
左側：SPA（每一條連線各自敲一次門）
- 用戶端裝有專用軟體，送出一個帶密碼學保護的單封包授權訊息。
- 閘道預設全丟，驗證通過之前不對任何流量回應。
- 驗證通過後才建立一條 mTLS 連線到受保護服務。
- 一條折回用戶端的迴圈箭頭標示：下一條連線要把整段流程重跑一次。
- 底下列出三項限制：需要專用用戶端，BYOD 與受限 IoT 裝不上；UDP 型式在受限網路可能被擋；短連線、高頻率的工作負載開銷偏重。
右側：身分原生（登錄一次，之後由身分決定）
- 端點持有密碼學身分，以出站連線登錄到身分覆蓋網路。
- 覆蓋網路對外沒有入站監聽，連線方向一律由端點往外。
- 已授權的兩個服務（ERP、API 服務）各有一條持續存在的隧道。
- 第三個服務（財務系統）未獲授權，圖上不是被拒絕，而是根本沒有路徑。
- 底下列出三項特性：服務、工作負載、AI 代理都是一等身分；隧道持續存在，不必逐連線重談；政策在連線存活期間持續評估。
實務上的意義很直接：評估一套產品時，該問的不是「有沒有 SPA」，而是「未授權者能不能探測到這個服務」，以及「達成這件事的代價落在誰身上」。 前者是安全結果，後者決定 BYOD、IoT 與雲端函數能不能一起納進來。
SDP 與微隔離的界線，畫在第一個封包上
安全團隊解釋 SDP、ZTNA 與微隔離怎麼分工時常常卡住，原因幾乎都一樣：用「南北向 vs 東西向」去框這三個詞。v3.0 換了一個更有用的座標——分界不是流量方向，而是連線的第一個封包。
- 連線定義的隔離（SDP／身分原生 ZTNA） 管的是「誰可以建立連線」。它在連線成形之前就把未授權者擋掉，成果是攻擊面縮小。
- 拓撲定義的隔離（傳統微隔離） 管的是「流量建立之後可以流到哪裡」。它在立足點出現之後限制擴散，成果是爆炸半徑遏制。
- 連線定義的隔離：連線成形之前
- 拓撲定義的隔離：連線成形之後
- 攻擊者被擋下的位置
圖說文字版
把兩種隔離擺在同一條連線的時間軸上：分界不是流量方向，而是第一個封包。
時間軸
- 左端標示「連線建立前」，右端標示「連線建立後」。
- 正中央一條金色虛線標示分界點：第一個封包。
左半邊：連線定義的隔離（SDP／身分原生 ZTNA）
- 管的是「誰可以建立連線」。
- 成果：攻擊面縮小、認證前零暴露。
- 隔離單位是服務或應用的身分。
- 跨雲、跨資料中心、跨 OT 區都成立。
- 一個外部攻擊者的探測線在分界點之前就被打叉擋下，標註「連線建立不起來」。
右半邊：拓撲定義的隔離（傳統微隔離）
- 管的是「流量可以流到哪裡」。
- 成果：橫向移動遏制、爆炸半徑縮小。
- 隔離單位是工作負載、網段、埠、協定。
- 作用範圍限於單一網路或控制域之內。
- 一個已有立足點的攻擊者往右擴散，被打叉擋下，標註「走不出這個區段」。
底部
- 服務本身就是第一級身分時，SDP 執行的已經是微隔離——兩層是重疊，不是二選一。
把兩者的差異逐項攤開，選型時要對照的是這張表：
| 維度 | 連線定義的隔離 | 拓撲定義的隔離 |
|---|---|---|
| 主要成果 | 攻擊面縮小、最小權限存取 | 橫向移動遏制、爆炸半徑縮小 |
| 隔離單位 | 服務或應用的身分 | 工作負載、網段、埠、協定 |
| 信任模型 | 每條連線都要明確授權 | 區段內預設可通 |
| 認證前暴露 | 沒有，服務是暗的 | 同區段內可見 |
| 邊界感知 | 跨雲、跨資料中心、跨 OT 區 | 限於單一網路或控制域 |
| 政策表達方式 | 誰、連什麼服務、在什麼條件 | 來源、目的、埠、協定 |
| 變更節奏 | 事件驅動（登入、姿態、風險） | 生命週期驅動（部署、拓撲） |
兩者重疊的地方在 v3.0 裡講得很清楚：當服務本身就是第一級身分時，SDP 執行的已經是微隔離。 所以架構師可以用一組簡單的心智模型收尾——SDP 是第一個封包的守衛，微隔離是連線之後的爆炸半徑遏制。三種遠端存取架構在資料路徑與存取粒度上的逐項比較另外寫在傳統 VPN、閘道式 ZTNA 與 SDP 架構比較。
導入的第一步不是寫規則，是把流量畫出來
v3.0 把實作框架獨立成一整章，第一句話就是先界定保護面，不要先寫規則。保護面指的是資料、應用、資產與服務（DAAS）的集合——先講清楚要保護什麼，再談怎麼保護。
交易流對映接在保護面之後，分五個可重複的回合進行，而且它會折回起點。
- 五個依序進行的回合
- 可驗收的產物
圖說文字版
交易流對映的五個回合，以及它應該產出的三份可驗收東西。
五個回合（依序，最後折回第一個）
- 一、界定保護面：列出 DAAS 元素。
- 二、探索實際流量：誰、用什麼、走哪條。
- 三、分類與標籤：貼上業務語意。
- 四、建模存取路徑：畫出現況與目標。
- 五、驗證與迭代：先報告模式再執行。
- 第五步有一條折回第一步的箭頭，標註「漂移與新相依回到模型：這是一條迴圈，不是一次性專案」。
三份可驗收的產物
- 標註過的流量清冊。
- 應用層的流程圖。
- 風險與成熟度矩陣。
有兩個細節值得單獨拿出來講。
第一，先跑報告模式再執行。 政策建議先以 report-only 產出，確認沒有合法流量被誤擋，再切成實際執行。這一步省下來的是上線當天的服務中斷。
第二，AI 輔助的探索與政策生成是建議，不是自動執行。 v3.0 在這裡寫得很保守：自動化可以聚類流量、標記服務、預測最小權限集合，但變更套用之前要有人審。這條分界值得寫進你自己的維運規範裡。
OT 與邊緣：先把控制器失聯那天想清楚
工業控制系統的優先序和 IT 不一樣：安全與可用性排在機密性前面，而且很多流程在廣域網路斷線時必須繼續跑。把 SDP 帶進工廠與邊緣環境，需要的不是同一套架構縮小版，是不同的失效設計。
v3.0 給的調整方向可以收斂成四件事：
- 控制器下放到區域內。 在 Level-3／DMZ 放一個輕量控制器實例，廣域網路中斷時本地授權照常運作，恢復後再與中央同步。
- 本地政策快取。 邊緣閘道保留一份精簡的決策引擎，讓已授權的流量在控制器離線時還能持續數小時。
- 安全側的失效邏輯要寫清楚。 安全側故障開放、唯讀降級、人工旁通，選哪一個是業務決策不是技術決策，而且要對得上 IEC 62443 的安全條款。控制器失聯時「全開」與「全關」都是錯的。
- 裝不了代理的設備走旁掛閘道。 由一台直列式閘道在外側終結 SDP，內側仍以原本的工業協定溝通，韌體一行都不用改。
這一段的重點不是技術細節，是順序：在 OT 環境裡，失效模式要在選型階段就談定，不是上線前一週才發現。
Secure by Design：SDP 是內建，不是外掛
前 CISA 局長 Jen Easterly 在 2024 年提出的那句話——「我們不需要更多的資安產品，我們需要更安全的產品」——成了 Secure by Design 倡議的主軸。v3.0 花了一節把 SDP 對到這個框架上，理由是 SDP 的三項特徵剛好都是「內建」而非「事後補」：服務預設拒絕、對網際網路不開任何埠、每一條微隧道都被認證授權並留下身分層級的紀錄。
這一節也點名了幾個讓工程團隊可以把零信任「嵌」進產品的開源途徑：覆蓋網路層的身分原生連線 SDK，以及服務對服務層的 SPIFFE／SPIRE——後者發的是工作負載的密碼學身分，讓應用程式可以用程式化的方式取得自己的身分憑證。
所以評估供應商時，除了功能清單之外還有三個結構性的問題值得問：
控制平面與資料平面是不是真的分離？ 控制器只做授權決策、不在資料路徑上，這同時決定了頻寬瓶頸在哪裡，以及誰在技術上碰得到你的資料。
有沒有做到零入站暴露？ 受保護端如果還需要開一個對外的埠讓別人連進來，那條埠就是新的攻擊面。
非人身分算不算一等公民？ 服務、工作負載、排程作業、AI 代理能不能用和人一樣的方式取得身分並被授權，決定了這套東西能不能跟著你的架構走下去。
汰換既有 VPN 的盤點、並行與分批驗證路徑寫在 VPN 替代方案怎麼選、怎麼汰換；Merak 採用的即是本文所述的 SDP 架構，規格與部署方式在 Merak 產品頁。
名詞對照與延伸閱讀
| 名詞 | 一句話解釋 | 出處 |
|---|---|---|
| SDP v3.0 | CSA 2026 年發布的 SDP 架構指南第三版 | CSA SDP 架構指南 v3 |
| 軟體定義邊界（SDP） | 先驗證身分才讓資源可達的架構 | 軟體定義邊界是什麼、怎麼運作 |
| 零信任架構 | 不以網路位置作為信任依據的架構原則 | 何謂零信任架構 |
| 隱式信任 | 通過邊界之後就預設可信的假設 | NIST SP 800-207 |
| 策略漂移 | 規則與實際環境隨時間脫節 | CSA SDP 架構指南 v3 |
| 橫向移動 | 攻擊者在內網從一台主機擴散到下一台 | MITRE ATT&CK TA0008 |
| 單封包授權（SPA） | 用一個帶簽章的封包完成預先授權 | CSA SDP 規格 v2.0 |
| 網路基礎設施隱藏協定（NHP） | 在會話層完成驗證並隱藏網域與 IP | CSA Stealth Mode SDP |
| Noise 協定框架 | 建立加密通道的一組握手模式 | Noise Protocol Framework |
| 基於身分的密碼學（IBC） | 直接用身分字串當公鑰的密碼系統 | Identity-based cryptography |
| 身分原生連線（IFC） | 以身分而非 IP 為主要抽象的連線模型 | CSA SDP 架構指南 v3 |
| 雙向 TLS（mTLS） | 連線兩端都出示憑證的 TLS 用法 | Mutual authentication |
| 拓撲定義的隔離 | 管流量建立之後可以流到哪裡 | Network segmentation |
| 微隔離 | 把隔離做到工作負載或服務層級 | CSA SDP 架構指南 v3 |
| 保護面（DAAS） | 要保護的資料、應用、資產與服務 | CSA 交易流對映 |
| 交易流對映 | 先盤出實際流量再據以訂政策 | CSA 交易流對映 |
| 最小權限原則 | 只給剛好夠用的權限 | Principle of least privilege |
| 安全側故障開放 | 控制器失聯時以安全為先維持運作 | NIST SP 800-82 Rev.3 |
| IEC 62443 | 工業自動化與控制系統的資安標準 | ISA/IEC 62443 系列標準 |
| Secure by Design | 把安全內建進產品而不是事後外掛 | CISA Secure by Design |
| SPIFFE／SPIRE | 給工作負載發密碼學身分的開源框架 | SPIFFE |
| 控制平面 / 資料平面 | 做決定的部分與搬資料的部分分離 | Forwarding plane |
| 零信任成熟度模型 | 分階段評估零信任落地程度的框架 | CISA Zero Trust Maturity Model |
既然防火牆與 VPN 仍然有它們的用處，為什麼要現在動 SDP？因為這兩樣東西的成本已經從採購移到維運：防火牆規則在動態環境裡長成難以稽核的規則叢林，而 VPN 給出的廣泛網路可達性，正是勒索軟體橫向移動最省力的路徑。SDP v3.0 沒有要求你在一個週末內換掉所有基礎設施，它給的是一個優先序——先保護高價值資產與混合雲工作負載，再逐步把隱式信任從架構裡拔乾淨。
本文的圖示為說明用的簡化架構：控制器的高可用拓撲、NHP 與 SPA 的完整欄位定義、以及各家實作在政策快取與失效模式上的差異，為了清楚起見已經略去，實際行為以各自的規格文件為準。如果你想針對特定環境討論這套架構怎麼落地，歡迎透過聯絡我們提出。