零信任架構-軟體定義邊界

運用"雲端服務"加速企業的數位轉型願景

23 min readJan 25, 2024

本文將介紹CSA(雲端安全聯盟)所發展出來的零信任架構解決方案 — SDP(Software-Defined Perimeter)軟體定義邊界的一些簡介。SDP的基本原則是ABCD:

Assume nothing
Believe nobody
Check everything
Defeat threats

本文將分為以下四個單元介紹:

SDP的效益與概念
傳統架構的問題與SDP的解決方案
核心原則、底層技術與架構
SDP部署模型基礎

SDP的效益與概念

定義與功能

CSA將SDP定義成能保護所有OSI model中的每一層。SDP實踐中，SDP會隱藏(在最前端設立一個 drop-all防火牆)數位資產並使用單一封包透過將control plane和data planes分離的方式建立信任通訊連線。在這個通訊連線中連線雙方會相互驗證。

SDP會在任何需要的地方部署防護邊界，例如在一個系統之中邏輯組件所包含的基礎設施。在連接系統之前，SDP要求使用者必須在經過驗證的裝置上以加密方式登入。SDP會將多種控制方式整合在一起，從應用程式、防火牆、加密、IAM、Session管理到裝置管理。

原則

SDP的原則是依照最小特權(Least privilege)與權責分離(separation of duties)進行其架構設計。基本的組件如下:

在drop-all 防火牆使用動態規則
隱藏伺服器與服務
在連線建立之前進行驗證
SPA(Single Packet Authorization) 與(或) mTLS
細部化的存取控制
裝置驗證

SDP的技術效益

效益一: 減少攻擊面
現行的網路架構(Client-to-Server)都是先對其建立網路連線，之後才開始做驗證。也就是說一但建立起連線，攻擊的可能性就瞬間拉高。SDP將此過程反轉 — 先驗證再建立連線，連線建立只有在authentication/validation/authroization完成後才會進行。在SDP的控制下，使用者/終端裝置不再有一般性的存取，而是用Policies來檢查與確保某些資源可以被存取。

效益二: 在存取前先驗證/授權
SDP本質上是覆蓋在實體和虛擬基礎架構上的綜合軟體。SDP使用Drop-all gateway的方式來確保所有的連線都要在驗證與授權之後才會發生。而這種方式就會需要把 control planes與 data planes進行分離，以強化其安全性。而SDP的設計是細緻度存取控制是隱含的。所以如前所述，沒有drop-all能力是無法建置"受信任的連線"的。SDP的架構是預先存取審查和基於角色/屬性的細緻化權限。

傳統架構的安全控制都是獨立存在的，這造成了組織會花很多時間跟精力進行管理，尤其是在現在日益複雜與動態的商業世界中。相較於以Ip-based(client-to-server)的連接方式，SDP用的是connection-based安全架構。這個意思是，相較於用白名單的IP清單方式，SDP是要持續不斷檢查每一個網路連線的情況。也就是說SDP是基於一種以connection為中心的安全性設計，而這種設計是不會在乎在底層的Infra是在內部還是外部。SDP會在TCP/TLS這一類的連線建立之前對其control plane進行驗證，這種做法確保了雙邊通訊的端點都是可受信任的。

效益三:中心化的IAM
傳統架構中，在真的存取到資源之前有非常多的安全檢查需要進行，如建立VPN然後通過防火牆或次世代防火牆接下來可能是IPS等等。所以前端安全性問題需要更新一次，而不是多次，而SDP則集中了這些管控簡化了維護的複雜度，因為所有的規則全部集中於一個地方而不是個別管理。

效益四:開放式的規範
這意味著SDP可以客製化，並且容易與第三方系統/平台/符合進行整合。

SDP的業務效益

組織實行SDP可以從以下三方面取的業務效益:

效益一:強化現有的資安投資
組織在資安方面進行了大量投資，為的就是要能及時回應資安事件/事故。例如弱點、補丁、配置等管理都是為了強化系統本身的安全防護能力，EDR伴隨而來的威脅情資可以讓組織了解未授權的使用者是誰?他們做了甚麼樣的連線。更有錢的組織可能會建立自己的SOC來集中控管這些資安設備/服務。

SDP 透過預防性和回應性(preventive and reactive)安全能力幫助優化安全投資。SDP的預防性能力不是只有IP-based的方式，而是跨越不同的資安攻擊面向。

效益二:成本與勞力的節約

降低授權和支援的成本
降低營運的複雜度與只依賴傳統的資安工具
可以減少或取代傳統很貴的網路專線或MPLS線路，這將造成組織在對不同的網路連線方式的選擇性變多，但同時卻保持安全性
也因為集中式的管控，資安人力就不需要這麼多的配置

效益三: 減少合規檢查範圍
如同前述，SDP(ZTA)將減少攻擊面，升高細部控制與micro-sgementation。這些都能減少組織在做合規檢查的範圍。例如:

更好地控制受監管資料的處理/儲存位置
限制對資料的物理/邏輯存取
對who-does-what-when-why有更細部的紀錄與監控

傳統架構的缺陷與SDP的解決方案

本節我們將會討論現今網路安全架構上的多種缺陷，而SDP 可防止因這些缺陷而造成的威脅。SDP則整合或取代業界採用的解決方案。SDP關注以下三個重點:

1.防護邊界的變化

由於虛擬網路的大量使用，已逐漸取代的舊有、固定式的網路，而傳統的解決方案是用資安設備Load balancer或Firewall(城牆與護城河)來隔離組織內部(信任)/外部(不信任)的網路。

網路協定的設計一開始就沒有將安全考量在內，而是以方便為主。但是現今的行動裝置或IoT讓固定的網路邊界在驗證上造成了很大的挑戰。IT環境與架構的不斷變動、企業的裝置可能處於任何地方也持續對這些舊有的安全方法造成挑戰，新的運算模式與威脅讓舊方法不再有效。SDP 提供軟體覆蓋的方式，可在需要的時間/地點動態建立虛擬邊界。

2.使用IP地址的挑戰

傳統的網路存取是使用IP位置建立連線，但並沒有經過授權。這是因為IP地址沒有使用"使用者身分"這樣的概念。IP是先建立連結，但沒有對其連結的裝置做信任驗證，這是因為TCP/IP是讓一個能雙向通訊且不受信任的裝置對其受信任的裝置開始對話。

IP的變動是常態(尤其在雲端的世界中)，我們不應把它當成錨點。但是使用類似傳統防火牆的清單規則可能因為經常更改IP而可能產生資安問題的發生。另外未受管控或沒在資產清單上的裝置可能成為惡意攻擊者的跳板。再來使用NAT的功能則讓資安的問題更加劇。而SDP的資安管控則完全不需要用到TCP/IP。

3.整合安全控制

組織通常會整合安全控制(一大堆的資安設備與解決方案)以實現合規性，而針對以Application infrastructure為中心的安全防護進行全面的安全控制是高度困難的，現行能做到這些整的大概是SIEM，但這一類的平台最多也只做到資料整合與分析。這一類的平台將不同的安全流關聯起來以獲得更深入的洞察是會消耗大量資源的。

這些資安設備或解決方案需要單一信任來源則，這需要使用者/網路/裝置等資訊。如果沒有這麼做，組織要整合成一組安全控制措施就變得很困難。而暫時替代方案也會很消耗組織的資源。例如，DevOps團隊會將 WAF/DDoS 保護視為事後的想法。更麻煩的是個別獨立的控制自己的安全態勢可能會導致災難。

SDP防範的威脅

SDP可以防範

Server被駭客攻擊後利用來製造DDoS/SQL injections
Server 有Misconfiguration或弱點產生
MITM(Man-in-the-middle)的劫持攻擊
憑證偽造的劫持攻擊
DNS Poisoning的劫持攻擊
釣魚
鍵盤側錄
暴力破解

SDP可以結合或取代業界常用的解決方案

NAC(Network Access Control):
這是一種運作在OSI L2的網路存取控制(802.1x)，它可以控制裝置要落在企業內網的哪一個VALN中，設備會被驗證，然後分配到預先應該要去的網段。這適合用在公司的內部網段數量沒有很多的組織。NAC需要特定的網路設備，並且是沒辦法用在雲端的環境與行動使用者。

SDP則可以取代NAC這一類的解決方案，因為SDP不需要特別的網路設備，就可以與一些終端裝置進行整合，並且也支援雲端與行動使用者的使用情境。不過有一好就沒有倆好，有一些硬體設備(如印表機、視訊設備)等只支援802.1x協定就不無法把SDP軟體安裝上去。比較可以實行的做法是採用Gateway-to-Gateway的方式來保護這些特殊的設備。

VPN(Virtual Private network):
這是通過Internet來建立加密的安全通道(TLS/SSL 或IPSec)來存取公司內的資源，可能是client-to-site或是site-tosite。雖然看起來很安全，但一般來說只要通過VPN的驗證並建立連線後就可以暢行無阻了。這跟SDP細部化的安全控制就不一樣了 — 只讓client去到應該去並且能執行的作業。另外有一些VPN的設定或問題讓使用者的體驗非常的差。而雲端遷移更加劇了VPN的複雜性，因為要控制client去道不同的地方就讓VPN的設定變得複雜。使用者在這些複雜的VPN設定中會搞得更亂，工作效率進而變差。對IT來說還要控制回程的網路流量。

VPN設備本身又是直接暴露在Internet上面，如果沒有做好資安強化就會變成是駭客的跳板。另外很多VPN的連線數又是算人頭的，這讓授權費用可能會增高。另外VPN設備通常也是Firewall設備，Firewall policy的設定配置都需要同步，有時VPN裝置可能會在不同的地點有不同的設備。

SDP可以獨立於VPN作業或是取代VPN這一類的解決方案。這是因為:

通常VPN client跟SDP一樣都需要裝軟體
SDP對所有的安全控制措施只要一個控制平台就可以
透過SPA與動態的防火牆能力，SDP的zero visibility可以讓組織有更多的資安韌性

NGFW(Next-generation Firewall):
次世代防火牆就是在傳統的防火牆增加其功能/能力。傳統的防火牆最多只能到OSI L4的檢查，而次世代的可以檢查到L7的內容。NGFW的功能依照各家品牌提供的功能可能不太一樣，但整個NGFW基本上能力有:

Application awareness
IPS/IDS
Identity awareness(user/group control)
VPN

NGFW有一些限制存在，如:

網路延遲性 — 特別是把IPS/IDS的功能打開然後也把其他封包深度檢查的功能也開啟
量能擴展 — 因為機器的規格是固定的，當超出機器的承載流量時就有效能問題
複雜的規則 — 在以上這麼多的功能如果都開啟，每一個功能都有著不一樣的規則。哪就會知道規則的複雜性有多高了

SDP則可以與NGFW進行整合:

SDP是可以專注在保護使用者的存取政策，而NGFW則專注於防火牆/IPS/封包檢查等功能
使用者存取政策可以透過與NGFW與 IAM/Windows AD進行整合

然而在整合之前我們還是要了解NGFW與SDP有著架構面上的不同:

NGGW是IP-based的，所以它沒法辦進行授權(Authorization)之類的功能。而SDP則是則是connection-based，所以可有授權的能力
NGFW的所有規則都需要事先設定好，就算修改也是人為去做，彈性較低。而SDP就可以包含類似NGFW之類的外部系統，並自動動態調整規則
NGFW還是傳統網路架構(護城河)，而SDP是採用動態的網路隔離能力
SDP的設計是基於”need to kmow”模型
最後NGFW還是需要先建立網路連線才可以繼續其他的安全控制，而不是先經過驗證與授權

IAM(Identity and Access Management):
SDP可以與IAM provider進行整合，不論是處於雲端/地端/混合的環境。IAM是一種用於驗證/認證/授權”使用者和裝置”的統一機制，它在一個中央系統中儲存受管理的identity attributes/group memberships。它可以與我們之前提到的傳統安全設備與解決方案進行整合，使用標準的協定: 如LDAP/Windows AD/ SAML/APIs。

SDP 通常根據基於 IAM 屬性/群組成員資格的業務規則以及進行連接的裝置和(或)網段本身的屬性來控制存取。SDP(使用其controller)依靠這些IAM的資料建立細部化的存取規則，並且只有在經過註冊裝置上請求特定存取權限的使用者才會獲得授權。

SDP與IAM的整合用在使用者與升級認證。例如IAM中啟用了MFA的功能，IAM可以使用API calls的方式與SDP溝通，進而完成整個身分驗證的生命週期，如—JML( Joiner, Mover, and Leaver)，暫停帳號或群組成員、基於地點來drop user/device connections。

IAM 資料還用於產出稽核日誌以及有關使用者/裝置存取的其他詳細信息。IAM telemetry將應用程式存取與使用者關聯起來 — 以更少的overhead提供有用的資料，這些歷史存取資料將有助於安全與稽核相關要求時能夠查證與佐證。

SDP與IAM的身分週期管理:

IAM專注於業務流程的身分驗證生命週期(如JML流程)
IAM的標準化如何使用身份資訊來控制對資源的存取(如使用RBAC/ABAC)
SDP高度依賴受IAM管理的身分屬性與群組成員
SDP 更改存取權限而不更改 IAM telemetry(因為SDP是IAM流程的下游系統)

另外SDP高度與SAML整合，SAML entity可能充當使用者屬性的身分提供者和(或) MFA 驗證提供者。SDP也可以使用其他協定: OAuth, OpenID connect, W3C Web Authentication, FIDO Alliance Client-to-Authenticator。

核心原則、底層技術與架構

本節中我們將說明SDP的作業如何提供組織的網路安全，還有和核心概念、底層技術、架構組件、保護工作流程等。

核心原則

SDP有三個核心原則來協助我們治理其SDP實行:

不假設任何事
不信任何人或事
驗證每件事

這些都是我們在實行SDP框架時的建構區塊。SDP是設計用來應對當今商業世界中動態的工作流程，絕大都是行動人員/裝置。所以SDP用軟體的方式實現以下目標:

Software defined Endpoint validation
Connect-based paradigm
與多種的控制措施整合(例如Firewall)

底層技術

SDP的底層技術分為以下四個組件:

組件一: Drop-all firewalls
其特徵如下:

禁止所有未明確允許的行為
能夠動態的將規則加入防火牆中
SDP 可以根據單一封包顯示缺少確定的 ID 來拒絕有風險的交易
SDP 透過在邊界丟棄所有未經授權的封包來拒絕惡意行為者的嘗試連接
聚焦於allow而不是block

組件二:分離的Control & Data planes
在SDP的架構中，除了 Control & Data Plane還有Management Plane。 Data plane就是裝載使用者的傳送資料，Control & Management Plane就是用來控制給不給Data Plane通行。

Control plane能建立connection與丟棄封包，並且確保在沒有完成使用者/裝置完成驗證前進行Data Plane的動作。因為傳統架構中，Control & Data Plane是同一個邏輯組件。將這兩個分開的好處在於，可以先驗證/授權後才建立連線。

組件三:Mutal TLS Authentication(mTLS)
SDP使用mTLS這種方式來確保溝通的雙方都是可信的。mTLS是一種相互驗證的方法，這種方式讓client端不需要去登入某個驗證系統就可以證明其身分。mTLS 透過驗證網路連線兩端的各方都擁有正確的私鑰來確保他們都是所聲稱的身分。他們各自的 TSL憑證中的資訊提供了額外的驗證。例如我們可以將這種方式用在IoT之類的驗證/加密。

這種方式是用於在IT環境中，限制連接到特定 Web 服務的programmatic/homogeneous client。另外營運的精力可以減少，安全要求更加嚴格。例如，可以用在B2B的系統中。

組件四: SPA
這是一種讓使用者發出連線請求的協定。SPA設計來彌補TCP/IP天生的缺乏安全性。因為在沒驗證之前，所有的TCP/IP連線到系統的要求通通都會被拒絕。流程圖如下:

一般SPA實行的概念如下:

SPA封包必須加密與驗證過
SPA封包需要獨立包含所有必需的資訊
封包的header必須是不被信任的
SPA封包的發/送都不是用管理者的權限等級進行的
沒有所謂raw packet的操作
伺服器必須盡可能從背景接收/處理 SPA 封包，而且不會回應發送端任何訊息

SPA的效益在於:

因為是drop-all firewall，所以攻擊者無法取類似poer scanning或其他偵查的方式來刺探訊息
SPA相關的組件對未授權的使用者是隱形的，這大大減少了攻擊面
Zero Day的保護 — 因為只有授權者能進入系統。非授權者無法利用zero day的攻擊
DDoS的防護 — 因為Drop-all，所有所有的DDoS HTTP(TCP)連線均無法建立
SDP的核心目標是客戶TCP/IP的開放與不安全的特性

SPA的限制:
SPA是SDP的一部分，所以它不是一個包山包海的安全範式。SPA有可能會是Main-in-the-middle攻擊的目標，因為SPA不是設計來抵抗這一類的Replay攻擊。駭客可能攔截SPA封包，而後建立 TCP 連線。

即使有Reply攻擊，駭客無法完成下一階段的mTLS連線。而controller/AH就會拒絕其連接嘗試。即使有這樣的小缺陷，但整體來說SPA仍比標準TCP安全。

SDP架構組件

這裡將介紹的組件有:

Initiating hosts
Accepting hosts
Gateways
SDP client
Controller

SDP整合式架構達成其他單一資安產品/解決方案無法達成的功能，SDP的整合功能有:

Identity-aware applications
Client-aware devices
Network-aware firewall/gateways

Initiating hosts:
這是某個裝置運行SDP client軟體對SDP進行初始化連線，此類裝置可以位於企業網路的內部或外部。

SDP client:
這個軟體可以讓Initiating hosts進行初始化連線，Client以加密方式登入 SDP。在完成對Controll的驗證與授權後，Client會產生SPA封包給SDP gateway。

Accepting Hosts:
接收來自Initiating hosts的連線並提供受SDP保護的服務。這一個組件通常位於組織控制的網路中。在沒有完成之前相關的認證/授權之前，Accepting Hosts不會有任何的回應。

SDP Controller:
這通常是一個設備或流程可以對服務存取進行隔離，它會對使用者/裝置進行授權與驗證，並建立安全的通訊。使用者與管理流量是分離的。這是受SPA保護的，所以它對未授權的使用者/裝置是隱形與無法存取的。Initiating hosts(IH)與Accepting Hosts(AH)都需要與它連線。

Gateway:
這通常是一個設備或流程可以針對已通過授權的使用者或裝置提供後端服務的存取。該組件會持續監控/紀錄/回報每個連線中的所有動作(基於在哪個位置)。

SDP的作業流程

下圖中Accepting host(AH)是隱藏在Gateway後面。

SDP Controller在 SDP 內新增/啟動並連接到身份驗證和授權的身分系統
透過檢查 SDP controller來新增/啟動 AH
IH被新增/啟動並連接到Controller
Controller驗證IH並決定AH的授權清單
始終發送 SPA 封包以建立通訊並隱藏應用層
IH與AH對control plane的資訊使用mTLS來交換mutual handshake
IH送出登入訊息要求
Controller會對IH送出目前可用的服務清單與驗證訊息
IH對AH送出SPA封包以建立data plane的通訊
針對資料傳送通訊會有另一個mTLS handshake來負責

SDP部署模型基礎

在我們佈署SDP之前，我們需要評估使用者環境、伺服器環境與控制環境（也就是SDP）。

架構性考量

我們需要考量實行ＳＤＰ對現有的網路拓樸與技術會有甚麼樣的影響，例如：

使用者衝擊
監控與日誌
應用程式更版與DevOps
裝置驗證

資安架構師必須決定使用哪種 SDP 部署，根據目的或使用場景決定哪種模式是適合的。但有一些是in-line的額外保護組件，例如Gateway。這可能會需要改變網路的拓樸（如firewall或routing）。

為了將SDP的功能發揮到最大，針對IP Infra我們應該實施是適合當下環境的Micro-segmentation。如此SDP才能確保安全連線，無論底層 IP 基礎設施為何。企業架構通常是很複雜的，實施SDP需要搞定一堆利害關係人，也要符合GRC的要求、日常的IT維運與管理要求。這些都在我們進行SDP規劃時都需要解決它的。

監控與日誌系統

佈署SDP同樣也會影響到監控與日誌系統，因為SDP會對監控與日誌系統隱藏要對系統監控的安全/效能/可靠度等流量。所以資安架構師也必須了解系統是如何運作的，而改變其網路會對其產生甚麼望樣的影響。

但是SDP卻可以豐富使用者的存取日誌，這可以強化監控與日誌系統的監控內容。所有SDP Gateway/controller的drop packet都可以被SIEM來分析，這是因為當佈署SDP時，連線中的who/what/when/why/how等資訊都可以很容易地收集。

應用程式更版與DevOps

SDP 透過成熟的整合支援 DevOps 並支援自動化。SDP會讓經過授權的使用者去連到他應該去的環境（test/stage/production）。SDP非常適合整合到Application stack(如K8S之類的虛擬環境)。

使用者衝擊

資安團隊應努力實現透明運作，盡量減少干擾使用者。而正確應用最小特權可以平衡使用者體驗和安全性。

裝置驗證

mTSL是基於有效私鑰授予存取權限，但這種方式也有被攻擊成功的可能。因為私鑰也有被偷的可能，這樣就無法區分到底誰才是合法使用者。裝置驗證進一步建立基於憑證金鑰的可信任連線。Controller充當可信任設備，因為它位於最嚴格控制的環境中。 IH 和 AH 必須透過Controller驗證自身，從而防止透過被盜金鑰進行未經授權的存取。

佈署模式

這一部分我們將討論幾種SDP佈署模式的相同與相異之處。SDP提供協定來保護在network stack中的所有layer。SDP是將controller/gateway擺在關鍵位置才能得以保護重要的網路連線。所有的SDP佈署模式都支援identity-driven的網路存取控制/授權。SDP 可與現有資安設備（IPS/IDS等）搭配使用，可分析丟棄的封包/不安全的連線。

Client-to-Gateway Model

這種模式適合有多個伺服器需要被Gateway所保護，尤其這些伺服器可能散落在不同的環境（雲端/地端）。Client使用mTLS tunnel 直接於gateway連結。Controller和Server可以使用相同的gateway。這個模式可以利用現有的資安設備，並將其部署於gateway與server之間。

Client-to-Server Model

這適用於Application在IaaS Provider平台上運作。這是將server與gateway放在同一個host中，這樣有很大彈性並且現有的資安設備可以繼續使用，也不需要有額外的網路設定。這個Host(Gateway/server)會強制SPA以防止未授權的使用者存取，而Gateway提供的安全伺服器連線可以完全由擁有者控制。Data Plane在這模式下也是絕對安全的，因為在這個mTLS tunnel中不會被break。

Server-to-Server Model

這適合用在IoT與VM環境，因為它提供在這些環境互相連線的完全控制。server之間的連線是被加密的，而server之間能不能通訊則需要依靠SDP內的白名單。Server可以同時扮演IH與AH，而Gateway也被直接安裝在Server內。也因為這些組件全部都在Server中，所以透過Gateway的伺服器連線也由應用程式/服務擁有者完全控制。

Client-to-Server-to-Client Model

這適合在雲端中運行的peer — to-peer的應用程式，像是聊天系統或視訊會議。Client對這一類的連線有完整的控制權。而SDP會將雙邊或多邊參與的client的IP影藏起來。

Client-to-gateway-to-Client

這是Client-to-Server-to-Client的變體，這個效益在於它可以讓client端直接相互連結，但是還是可以強制執行SDP的安全政策。應用程式會決定client之間如何連接，而Gateway則扮演firewall的角色。

Gateway-to-Gateway Model

這非常適用於IoT環境。這是因為相關的設備都無法安裝其SDP軟體，所以server與client都躲在Gateway後面。Server前端是一個AH(gateway)，client的前端是一個IH(gateway)。Gateway可能有firewlls或router或proxy的功能，端看實行的方式。