架構
軟體定義邊界（SDP）是什麼、怎麼運作
軟體定義邊界（SDP）要處理的問題，一句話就講得完：你的 VPN 閘道現在正在被掃。
不是被針對。是因為它有一個公網位址、有一個開著的埠，而全世界的掃描器每天都把整個 IPv4 位址空間跑過一遍。它們不需要知道你是誰，只需要知道那個位址上有東西會回應。
SDP 換掉的就是「會回應」這三個字。它不是把防火牆規則寫得更嚴，而是把順序倒過來：先證明你是誰，服務才存在；證明不了，那個位址上就什麼都沒有——連拒絕都不會回。
這篇文章拆的是這個順序實際上怎麼做到：三個角色、五個步驟、一個封包，最後一段講它擋不住什麼。三種遠端存取架構的逐項比較寫在傳統 VPN、閘道式 ZTNA 與 SDP 架構比較，這裡只談 SDP 內部。
軟體定義邊界到底定義了什麼
軟體定義邊界不是一個形容詞，它是一份有規格書的架構。雲端安全聯盟從 2014 年開始維護 SDP 規格，目前是 v2.0；NIST SP 800-207 把它列為實作零信任架構的其中一條路徑。所以「這家的 SDP 和那家的 SDP 是不是同一件事」是有答案的：看它有沒有這三個角色，以及那一條規則。
三個角色：
- SDP 控制器 —— 唯一做決定的地方。它掌握身分、裝置狀態與政策，回答「這個身分現在可以連到哪些資源」。
- 發起主機（IH） —— 使用者裝置上的用戶端。它持有一組X.509 憑證，代表這個人與這台裝置。
- 接受主機（AH） —— 擋在每一個受保護資源前面的節點。ERP 前面一個、檔案伺服器前面一個。
一條規則：預設全丟（drop-all）。接受主機的預設行為是丟棄所有進來的封包，而且它自己不開任何對外的埠——它是主動出站連到控制器的。
- 控制平面：授權在這裡發生
- 資料平面：mTLS 直連
- 這次沒有被授權的資源
圖說文字版
一張圖說明 SDP 規格定義的三個角色，以及授權與資料為什麼走在兩條不同的路徑上。
三個角色
- SDP 控制器：位於上方，負責身分、裝置與政策，並算出這個身分被授權的 AH 清單。
- 發起主機（IH）：左下方，使用者裝置上的用戶端，持有使用者憑證與裝置憑證。
- 接受主機（AH）：右側三台，分別擋在 ERP、檔案伺服器與財務系統前面，全部預設全丟、對外不開任何埠。
控制平面（虛線）
- ① AH 開機時就以出站連線註冊到控制器，對外不開任何埠。
- ② IH 向控制器出示身分與裝置憑證，取回被授權的 AH 清單。
- ③ 控制器算出這個身分被授權的 AH。
- ④ 控制器通知那幾台 AH：接受這個 IH 的連線。
資料平面（實線）
- ⑤ IH 直接與 ERP 前面的 AH、以及檔案伺服器前面的 AH 建立雙向 TLS 通道。
- 流量不經過控制器，控制器不在資料路徑上。
- 財務系統前面的第三台 AH 沒有任何連線：它有註冊、也在運作，但對這個 IH 不存在。
圖上的五個步驟裡，第五步是最容易被忽略、但影響最大的一步：控制器不在資料路徑上。它只參與授權決策，之後的流量是發起主機與接受主機點對點跑。這件事同時決定了頻寬瓶頸在哪、以及誰有技術能力碰到你的資料——後面會再回來談。
為什麼掃描器看不到 SDP 後面的服務
先講清楚一般防火牆做的事。一台設定嚴格的防火牆收到不該收的封包時，通常會回一個 TCP RST，或是一個 ICMP 目的地不可達。這是「拒絕」。拒絕也是一種回應，而回應就是資訊：對方知道那個位址上有一台活著的機器，只是這個埠不開。
網路服務探測這個階段要的就是這種資訊。它先問「誰會回話」，再問「回話的是什麼」。預設全丟改變的是第一個問題的答案。
- 未授權的探測，全部丟棄
- 接受主機的預設全丟規則
- 通過驗證之後才存在的通道
圖說文字版
同一台 AH 的同一道預設全丟規則，上下兩排是它面對未授權探測與合法用戶端時的兩種結果。
上排：掃描器
- 掃描器沒有身分也沒有金鑰，對應 ATT&CK 的 T1046 服務探測。
- 它對三個埠送出 TCP SYN：443、22、3389。
- 三個封包全部被丟棄。
- 回來的是：沒有 SYN-ACK、沒有 RST、沒有 ICMP。
- 掃描器得到的結論是這個位址上什麼都沒有，因此這個位址不會進入目標清單。
下排：已註冊的用戶端
- 用戶端持有裝置憑證，並與 AH 共享單封包授權（SPA）金鑰。
- 它先送出一個 SPA 封包，走 UDP，只有一個封包，不需要先建立連線。
- 驗證通過之後，AH 才在規則上開一個口。
- 開的範圍只有這個來源 IP，而且只有被授權的那個埠。
- 接著雙方進行 mTLS 交握，連到 AH 後面的資源。
要看出來的事
- 兩排面對的是同一道規則，AH 沒有在分辨誰是好人。
- 差別只在於有沒有一個通過驗證的單封包先到。
- 沒有有效的單封包授權，AH 連拒絕都不會回。
對掃描器來說，「不回應」和「這個位址上沒有主機」在觀測上是同一件事。它不會停下來研究，因為它同時在掃幾千萬個位址，沒有理由在一個沒反應的位址上多花時間。結果是這台機器不會進入目標清單，後面整條利用鏈——找版本、比對漏洞、嘗試預設憑證——就沒有起點。
這也是為什麼攻擊面盤點裡「應該關掉但業務上關不掉」的那些項目，處置方式通常不是加固，而是改成授權後才可達。外部遠端服務長年是初始入侵的主要途徑之一，原因就是它必須對全世界開著。
單封包授權和連接埠敲門差在哪
會問這個問題的人通常已經知道連接埠敲門：客戶端依序敲幾個關著的埠，防火牆看到正確的順序就開門。想法一樣，但它有幾個真的會出事的問題——敲門的順序是固定的、明文的，任何看得到流量的人都能記下來重放一次；而且順序需要好幾個封包，本身就是一個可被觀察的模式。
單封包授權（SPA）把這件事收斂成一個封包。它走 UDP，不需要先建立連線，所以在 TCP 三向交握發生之前就已經被驗證完畢——驗不過的封包在協定堆疊很前面就被丟掉了。
- 封包實際帶的欄位
- 這些欄位擋掉的攻擊
圖說文字版
一個單封包授權封包的欄位排列，以及每一組欄位分別擋掉哪一種攻擊。
封包欄位（由左至右）
- 用戶端識別碼（client ID）：誰在請求。
- 一次性計數器（HOTP counter）：每次遞增。
- 時間戳（timestamp）：有效期很短。
- 來源 IP（source address）：從哪裡送出。
- 要求的服務與埠（service + port）：要開什麼。
- HMAC 簽章：用共享金鑰算出。
- 整包走 UDP，是單一封包，不需要先建立連線。
重放：攔到封包再送一次
- 計數器每次遞增，時間戳有效期短。
- 同一個封包不會被接受第二次。
偽造：亂送一個碰運氣
- 沒有共享金鑰就算不出 HMAC。
- 驗不過就直接丟，不回應。
挪用：換個位址或換個服務
- 封包綁死來源位址與目標服務。
- 通過之後也只開那一個埠。
要看出來的事
- 驗證發生在 TCP 交握之前。
- 驗不過就沒有下一步，也沒有任何回應。
三個欄位群各自負責一件事：
| 要擋的攻擊 | 連接埠敲門 | 單封包授權 |
|---|---|---|
| 重放攻擊 | 錄下順序就能重放 | 計數器與時間戳讓封包只能用一次 |
| 偽造封包 | 猜順序即可 | 沒有金鑰算不出 HMAC |
| 挪用到別處 | 開的是整個埠 | 綁定來源位址與指定服務 |
計數器的作法沿用 HOTP 的遞增邏輯：每個用戶端與接受主機各自維護一個計數器，用過的值不再接受。時間戳再壓縮一次有效窗口。兩者加起來的效果是，就算有人完整錄下了那個封包，重送也沒有用。
來源位址那個欄位還順手處理掉另一件事：就算有人偽造來源位址送出一個有效封包，接受主機開的口也是給那個被偽造的位址，不是給實際送封包的人。
一個常見的誤解要在這裡擋掉：SPA 不是加密機制。它只決定「要不要讓這個來源看到這個服務」。真正的機密性與雙向身分驗證由後面的雙向 TLS（mTLS）負責，兩層是分開的，不能互相取代。
控制平面與資料平面分開，換到什麼、付出什麼
把授權決策與資料傳輸拆成控制平面與資料平面，是 SDP 和閘道式 ZTNA 最實質的分岔點。閘道式架構裡，所有流量都經過那台閘道；SDP 裡，控制器只發一張通行證，之後就退場。
換到三件事：
- 沒有中央頻寬瓶頸。 加人不會讓所有人一起變慢，因為沒有一條大家共用的管線。
- 廠商不在資料路徑上。 這在跨境傳輸評估與特許行業的稽核裡，通常比任何效能數字都好用——「技術上有沒有能力接觸到」和「合約上承諾不接觸」是兩個層級的答案。
- 就近連線。 同一棟樓裡的兩個節點不需要繞到某個區域閘道再繞回來。
付出的代價也要講清楚：控制器變成新連線的關鍵路徑。控制器掛掉的時候，已建立的連線通常還活著，但新的授權發不出去。這代表控制器的高可用設計不是選配，而是架構評估的必問項——否則你只是把一個對外開埠的單點故障換成另一個不開埠的單點故障。
另外，控制器本身要讓發起主機連得到。實作上通常把它也放在單封包授權後面，或用其他方式收斂它的暴露面，但它終究不是「零暴露」——這一點值得在評估時直接問廠商。
一條連線只通到一個資源
VPN 通過驗證之後發的是一個內網位址，於是可達範圍是一個網段。SDP 通過授權之後建立的是一條到單一接受主機的通道，於是可達範圍就是那一個服務。
差別在事故發生時才看得出來。同一組被盜的帳號，在網段模型裡可以往同網段的每一台機器試；在 SDP 裡，它能碰到的就是那個身分本來被授權的那幾個服務，橫向移動沒有可以延伸的面。這是最小權限原則第一次真的落在網路層——過去它多半只落在應用程式的角色設定裡。
要注意的是，粒度細本身不會自動變安全，它只是讓「授權了什麼」變成一件必須寫清楚的事。政策寫得爛的 SDP，和網段開太寬的 VPN，結果可以一樣糟。逐連線授權的完整機制、以及政策容易寫錯的地方，寫在 Merak 零信任網路是怎麼運作的。
軟體定義邊界擋不住什麼
任何不講限制的架構說明都不值得讀。以下幾點應該在評估階段就攤開：
- 端點被入侵，這套機制就從內部被繞過。 憑證與 SPA 金鑰放在裝置上。裝置被完全控制的時候，攻擊者不需要打穿 AH，他就是那個合法的 IH。裝置姿態檢查與端點防護仍然是必要的，不是可選的。
- 不處理應用層的漏洞。 通過授權之後，那個應用還是那個應用。SQL 注入、失效的存取控制、有漏洞的元件，不會因為連線方式改變而消失。
- 不取代應用內的權限模型。 SDP 回答「這個身分能不能連到這個服務」，服務內部誰能看哪一筆資料，仍然是應用程式自己的責任。
- 憑證生命週期是持續成本。 發卡、輪替、離職撤銷、憑證撤銷狀態查詢——這些流程沒有建起來，憑證只是換一種形式的長期密碼。
- 既有的網路監控會出現盲點。 端對端加密意味著中間節點看不到內容，原本靠閘道側檢查流量的監控與資料外洩防護需要改到端點側或應用側。
- 裝不了任何東西的環境不適用。 老舊設備、封閉系統，通常要靠一台獨立節點在前面承接，這是額外的部署工。
導入前先回答的四個問題
接受主機放在哪裡？ 每一台主機上裝一個，粒度最細但部署量最大；或用一台前置節點承接一整組服務，部署快但那個節點後面就是一個小網段。這個選擇通常會分批混用。
控制器託管在哪、由誰運維？ 自建、廠商代管、或混合。這題同時牽動可用性責任與合規論述，值得在報價階段就問清楚。
第一批搬哪些服務？ 選使用者少、影響面清楚、而且目前對外暴露的那幾個——通常是遠端桌面與管理介面。
並行期怎麼設計？ VPN 不會在一個週末內關掉。盤點、並行、分批、驗證的實際路徑寫在 VPN 替代方案怎麼選、怎麼汰換；Merak 採用的就是本文描述的 SDP 架構，各項規格與部署方式在 Merak 產品頁。
名詞對照與延伸閱讀
| 名詞 | 一句話解釋 | 出處 |
|---|---|---|
| 軟體定義邊界（SDP） | 先驗證身分才讓資源可達的架構 | NIST 詞彙 |
| SDP 規格 | SDP 三個角色與流程的原始規格 | CSA SDP 工作小組 |
| 零信任架構 | 不以網路位置作為信任依據的架構原則 | 何謂零信任架構 |
| SDP 控制器 | 掌握身分與政策、做授權決定的角色 | CSA SDP 規格 v2.0 |
| 發起主機（IH） | 使用者裝置上發起連線的用戶端 | CSA SDP 規格 v2.0 |
| 接受主機（AH） | 擋在受保護資源前面的節點 | CSA SDP 規格 v2.0 |
| 預設全丟（drop-all） | 未授權封包一律丟棄且不回應 | CSA SDP 規格 v2.0 |
| X.509 憑證 | 公鑰與其持有者身分的標準格式 | RFC 5280 |
| 網路服務探測 | 找出目標上有哪些服務會回應 | MITRE ATT&CK T1046 |
| 外部遠端服務 | 從對外的遠端存取服務進入內部 | MITRE ATT&CK T1133 |
| 連接埠敲門 | 依序敲固定埠序列來開門的舊作法 | Port knocking |
| 單封包授權（SPA） | 用一個帶簽章的封包完成預先授權 | CSA SDP 規格 v2.0 |
| UDP | 不需建立連線的傳輸協定 | RFC 768 |
| TCP 三向交握 | 建立 TCP 連線的三個步驟 | RFC 9293 |
| 重放攻擊 | 錄下有效訊息之後再送一次 | Replay attack |
| HMAC | 用共享金鑰算出的訊息驗證碼 | RFC 2104 |
| HOTP | 以遞增計數器為基礎的一次性密碼 | RFC 4226 |
| 偽造來源位址 | 偽裝封包來源位址的手法 | IP address spoofing |
| 雙向 TLS（mTLS） | 連線兩端都出示憑證的 TLS 用法 | Mutual authentication |
| 控制平面 / 資料平面 | 做決定的部分與搬資料的部分分離 | Forwarding plane |
| 單點故障 | 單一元件失效導致整體失效 | Single point of failure |
| 橫向移動 | 攻擊者在內網從一台主機擴散到下一台 | MITRE ATT&CK TA0008 |
| 最小權限原則 | 只給剛好夠用的權限 | Principle of least privilege |
| 憑證撤銷狀態查詢 | 確認一張憑證是否已被撤銷 | RFC 6960 |
本文的圖示為說明用的簡化架構：控制器的高可用拓撲、SPA 封包的完整欄位定義、以及不同實作在計數器與時間窗上的差異，為了清楚起見已經略去，實際行為以各自的規格文件為準。如果你想針對特定環境討論這套架構怎麼落地，歡迎透過聯絡我們提出。