不買新產品，你要怎麼做到零信任架構？

駭客花生醬

2023/05/15閱讀時間約 14 分鐘

隨著「零信任架構」(Zero Trust Architecture) 一詞在臺灣風靡一時，各家資安廠商也搭上了這股風潮，什麼產品都要「零信任」一下。然而，有「零信任」的產品就是資安萬靈丹嗎？

零信任架構是什麼？

想像一下，如果你要存取資料，首先要驗證使用者身份（例如生物識別＋密碼），接著又要同時驗證使用的裝置是否安全，最後再經過系統判斷本次存取行為是否正常，才會被放行讓你存取資料。這樣的流程是不是聽起來很安全呢?

如果你覺得這樣很安全的話，那你可以了解一下零信任架構。上述流程只是零信任架構中的一種情境，順帶一提，現在政府在推動的零信任網路也都只是零信任架構中的一環。

總結來說，零信任架構 (Zero Trust Architecture, ZTA) 是一種資安策略和架構，其基本原則是不信任任何用戶、裝置或應用程式，直到其經過驗證和授權。

換言之，零信任架構的核心概念為「不要有任何隱式的信任。」

如下圖 NIST 的舉例：

以美國 NIST Zero Trust Policy 舉例

其中，有三個重要的名詞概念需要了解：

PIP (Policy Information Point)：用於收集與分析所有可用的安全策略和資訊，例如身份認證、裝置狀態等。
PEP (Policy Enforcement Point)：負責監視所有存取請求，並確保只有通過身份驗證和授權的請求才能存取資源。
PDP (Policy Decision Point)：用於實現安全策略的決策中心。基於所收集的安全資訊和策略，判斷是否應該允許或拒絕該存取請求。

如果所有的資源存取都要經過這些程序，理論上的確能實施零信任架構，但在現實世界中，要完全實施這些存取路徑基本上是任重而道遠，不太可能一次到位。

因此，接下來本篇文章會分享我對於零信任架構的一些觀察與實作建議。對零信任架構的基礎概念尚不清楚的讀者，可以閱讀 iThome 整理的〈ZTA 101〉，一般民眾也可以聽聽資安解壓縮的podcast〈EP51 - 別相信任何人｜零信任原則〉，以對零信任架構有一些基礎認識。

零信任 ≠ ＯＯＯ

首先要釐清一個重要前提：

零信任架構不只是單一種產品。

零信任架構開始流行之後，我們看到無數標榜零信任 OO 的各類產品在仿間大肆宣傳，但零信任不等於：

≠ 特權管理系統 (Privileged Access Management, PAM)
≠ 多重要素驗證 (Multi-factor authentication, MFA)
≠ 微切分架構 (Micro-Segmentation)
≠ 安全存取服務邊界 (Secure Access Service Edge, SASE)
≠ 虛擬私人網路 (Virtual Private Network, VPN)
等等等等……

如果有人跟你說，用了這套產品就可以「完全」實踐零信任，請多想想，我們要保護的資產千千萬萬種，不可能有一種解決方案可以一體適用所有資產、所有產業、所有情境。零信任只是一種概念，而不是一顆萬靈丹。

也因此，我會認定以上諸多產品分類，都只是零信任架構在實作時的「子集合」。在不考慮成本的情況下，這些產品還是能夠起到不錯的保護效果。舉例來說，Cloudflare 的 SASE 類型服務，每月 USD$ 7 元 / User，還不包含端點價格。若是地端的 VPN 與網路分隔，價格也許可以更低一些。

換言之，若要達成「零信任架構」，你也許可以導入上述產品分類。但就算不用——你也有機會做到。

不買新產品，你要怎麼做到零信任架構？

實施零信任架構需要進行裝置盤點、應用程式和服務的分類、控制更新管道、確認供應商對資安的掌控等。零信任不是不信任任何人，而是沒有隱式信任。在零信任架構下，環境中的所有東西，從裝置、應用，到網路都應該做到同樣的驗證，而不是預設相信他們都是安全的。

若是不看各種解決方案，針對零信任架構，我們如何將零信任的概念內化，實踐於企業的安全防護中？

以下將分為裝置、應用程式或服務、網路、身份進行說明。

裝置

進行裝置盤點是十分重要的。在零信任架構的概念中，我們不能先決地信任任何裝置，因此率先需要對手邊擁有的裝置做一次全面的盤點。

盤點過後，則根據裝置的敏感性和風險等級進行裝置分類。舉例來說，因為不能停擺所以一直無法更新的裝置、或是沒有續約的老舊裝置等等，企業中可能存在這些敏感性高且資安風險等級高的防護漏洞。進行裝置的分類有助於確保我們能夠更好地管理和保護這些資產。

此外，確保裝置都安裝了最新的安全更新和修補程序也是十分重要的。如果企業自身對於己身的資產毫無概念、無法掌握。我認為比起購買解決方案，企業更應該優先解決這些基本問題。

註：以上所述的資產盤點與分類並非只限於 OA 區或部分敏感範圍，而是包含整個企業場域，像是那些常常被忽略的舊伺服器區。

應用程式或服務

如果你的應用程式或服務全都是在雲端上，我相信你要實施一些零信任架構的措施是相較簡單的，但如果你的服務並不全都在雲上呢？

我將這些在地端的應用程式或服務分為兩種類型：第三方、自主開發。

以下說明這兩種類型的零信任架構實作差異。

第三方：泛指企業自身無法掌握其核心技術的應用程式或服務。例如：企業資源規劃系統 (Enterprise Resource Planning, ERP)、員工系統、文件儲存裝置……等等。對於這些第三方的應用程式或服務，實施零信任架構的關鍵要點在於：

更新管道：對於這類應用程式與服務，除了老生常談的保持更新，企業最好還要掌控更新管道。例如，Windows Update 獨立安裝程式 (Wusa.exe) 可以限制更新來源以及要更新的項目。此外，有些第三方的 IT 管理工具也可以管理端點軟體的更新。畢竟，來自第三方的應用程式與服務有可能因為其軟體供應商被攻擊，導致更新之中反而被塞入惡意程式，例如最新的 3cxDesktopApp 事件還有之前的 SolarWinds 事件，都是經典的供應鏈攻擊案例，因此，如果在第一時間就可以知道受害範圍或是控制更新範圍，便可以快速地進行資安事件處置。
確認供應商對於資安的掌控度：雖然不是每個企業都有足夠大的體量和能力強制要求供應商遵守一定的資安標準，但常見的做法是要求供應商出示安全合格認證（包含但不限於 ISO27001、Common Criteria…）。除此之外，稽核團隊應該注意的是安全合格認證的「範圍」。臺灣最常見的情況是通過 ISO27001 的範圍只有機房，但開發人員或是存取資料的人員並沒有納入管理範圍。
服務或應用程式的開發安全性：在採購時，供應商有責任提供安全評估報告（包含但不限於軟體弱點掃描報告、第三方測試報告…），並擁有安全的軟體開發流程（包含但不限於 SSDLC）。其中經常被忽略的是，供應商通常沒對軟體或服務使用的第三方函式庫進行盤點與版本控管。
限制服務的網路：這在後面的「網路」章節也會再次提到。實施零信任架構前，肯定會有許多未知的應用程式或服務。透過記錄 dns 資訊與網路流量，可以有效地後續控管其服務或是應用程式與網際網路連線範圍。

自主開發：泛指企業自行開發的應用程式或服務，對其具有完全的技術掌控度。除了常見的黑箱、白箱掃描，對於這些應用程式，實施零信任架構的關鍵要點在於：

安全的開發流程：確保開發人員遵循安全的開發流程，例如使用安全的編碼標準、進行定期的代碼審查和測試。此外，還要建立嚴格的變更管理流程，以確保對產品的修改和更新經過充分的審查和測試。
程式庫管理：對於開發中使用的第三方程式庫，追蹤版本和確保安全性。例如定期檢查相關的漏洞和安全風險，並在必要時進行更新或替換。許多現今企業的開發工具或是版本控制軟體都是使用第三方的系統，而許多駭客會偽造類似名稱的程式庫讓開發人員不小心引用。

註：除了上述做法，應用程式應確保更新管道與使用套件根據最小權限原則，永遠認定是可能被攻擊的。

網路

網路的防護和管理雖然是基本中的基本，但也是最難做好的。有些企業甚至連自己的網路拓墣圖都拿不出來。但無論如何，以下幾個面向都非常值得企業投資。

加密：加密所有的 DNS、HTTP、Email ，不要讓這些服務繼續裸奔了。DNS 應該是被很多企業遺忘的部分，但不管是保護 DNS 不被竄改，或是防止被駭客偷看上什麼網站，都是很基本的措施。

網路分隔：加強身份與網段的管理。無論是微分段，還是傳統的網路分段，不同做法其實都有同樣的目標，那就是建立有結構的、基於身份的隔離環境，防止攻擊者進入後能夠輕易地在網路中橫向移動，攻擊其他電腦。

但需要注意的是，零信任架構並不代表完全沒有內外網，隔離環境需要根據企業的需求和風險進行調整，並且需要與其他零信任的措施相互配合，才能真正實現網路的安全防護。而且一般來說，當企業有意識地去做網路分隔，同時已經往「消除」隱式信任更靠近一步了。

網路可視性：隨著我們加密各種流量，如何在監控網路封包與分析封包內容之間取得平衡就很重要了。檢查並分析記錄下來的網絡流量是零信任架構的一個重要原則，但許多深度封包檢測 (Deep Packet Inspection, DPI) 或是安全通訊端層 (Secure Sockets Layer, SSL) 分析的產品，並沒有好好實作，導致可能有被中間人攻擊的風險（可參考此篇文章〈HTTPS Interception Weakens TLS Security〉）。另一方面，對網路全面執行 DPI 也很貴啊！所以我建議，針對存放敏感數據並具有可預測性的來源和目的地的應用程式做封包深度檢測，其他的則是保留Ｍetadata 以進行異常分析。

身份

最後來到最多人討論的身份。這邊就不再說明 MFA 了，由於其十分重要，MFA 也是所有人在談零信任架構時最常說到的概念。那麼，除了 MFA 之外，還有哪些措施可以實踐身份上的零信任架構？

單一身份識別來源：盡可能地減少身份識別的來源並統一管道。想像一下，一個人要記 5~10 種帳號和密碼，哪天可能就忘記了。做好單一身份識別來源，能夠有效盤點使用者方面的風險。同時，當人員異動時也能快速進行反應，避免人員離職後卻因為過多身份沒有完整停用權限，使之還能違規存取。
權限盤點：還沒盤點好權限的企業都應該格外注意。很多人看到權限盤點，第一時間會想到 PAM 這種解決方案，但這種解決方案的使用前提是你要知道帳號或是服務的存在才能進行納管。所以，最重要也最基本的盤點權限，還是需整合文章前面提到的裝置、應用程式或服務進行全盤考量，甚至要包含身份識別系統。換言之，全面掌握既存的裝置、應用程式、服務，才能進行有效的權限盤點。

在臺灣，零信任「網路」 < 零信任「架構」

談了這麼多，我認為，臺灣目前推動的零信任「網路」指導原則與現今討論的零信任「架構」，還是有些落差的。

為什麼我會這樣認為呢？

零信任網路是一種保護網路安全的方法，它假設所有人都不可信，必須驗證身份和權限才能存取資源。然而，它只考慮了網路安全，沒有考慮到應用程式的安全性。

相對地，「零信任架構」是一種更完整的安全方法，考慮了網路和應用程式的安全性，以及人和電腦之間的信任關係，將各種角度的隱式信任盡可能地帶入架構中討論。

NCCST 政府零信任網路說明 - 截圖

CST 政府零信任網路說明 - 截圖

從 NCCST 的說明，不難看出有借鑑許多美國 NIST 的零信任架構部分內容。所謂的存取閘道相當於 PEP，讓存取資料的操作都必須通過它進行限制。而決策控制器相當於 PDP，作為決策的大腦根據各單位的政策去允許或拒絕存取，而各種身份與設備的代理程式相當於 PIP，用以輸入供決策的資訊。

然而，這樣的架構僅針對網路，無法等同於零信任架構。畢竟，被保護的資源或應用程式本身也可能存在問題，且資料的回傳也沒有必須經過決策系統。因此，僅透過零信任「網路」的保護方式，並不能完全保證資源或應用程式的安全性，必須透過零信任「架構」，綜合考量人、設備、應用程式之間的互動和信任關係，才能更全面地保障資訊安全。

總結來說，零信任架構並不僅僅是透過限制網路連線就可以解決的，它是整個資安策略的核心思想。因此，在制定資安策略時，必須將零信任的概念內化，從多個角度考量和防範潛在風險。

結語

零信任架構並非是一種產品或萬靈丹，而是一種理念和方法論。我希望透過這篇文章，讓大家對此有更深刻的認識，而不只是跟著潮流購買更多的解決方案，白白增加管理的負擔卻無法從根本實踐零信任架構。

無論是裝置的盤點與分類、應用程式或服務的管理、網路的防護、還是身份與權限的掌握，這些基礎功做好，不買新產品，也有機會做到零信任架構。

參考資料

〈封面圖片〉

〈ZTA 101〉

〈EP51 - 別相信任何人｜零信任原則〉

〈HTTPS Interception Weakens TLS Security〉

除此之外，撰寫本文時，我稍微收集並參考了一些有關零信任架構的資料，並附上了我自己的見解，歡迎大家參考：

NIST SP 800-207：最多人講到零信任架構時會提到它，我想應該也是最早出現在大眾眼前的白皮書。如果你想深入了解完整的零信任架構理論，這會是很好的參考，但這份文件並沒有提供明確的實踐指南。
NIST SP 1800-35 (Draft)：由於零信任架構被提出來後，許多美國聯邦單位也被要求實作，因此 NIST NCCoE 找了廠商來做示範組，詳盡解釋了零信任架構的執行概念、策略、評估、實作功能。最貼心的是，這份文件還針對不同層級的管理人員分成四份文件，讓每一個層級的管理者都能夠有所依據。這份文件目前還在草稿階段，並持續更新中。
美國聯邦政府 ZTA 指南：這份文件主要是讓聯邦政府人員有概念怎麼採購與實施零信任架構，非常簡短但有效，還很貼心地在結尾提供了 memo 資訊的整理，讓美國的聯邦政府人員能大概了解跟零信任架構有關的政府命令。
英國 NCSC ZTA 指南：與美國聯邦政府的 ZTA 指南類似，但英國的 ZTA 指南更加淺顯易懂，並涵蓋比較多的常見問題 Q&A。
CIS Controls v8 mapping ZTA：為了讓企業有明確的提升與改善目標，CIS 把自己列的安全控制項 (Controls) 對應到零信任架構的概念中，雖然無法全部涵蓋，但對企業而言總是個起頭。

即將進入廣告，捲動後可繼續閱讀

為什麼會看到廣告

22會員

9內容數

分享對於資訊安全的分析和評（吐）論（嘈），趨勢觀察、技術分析、觀點評論、科普教育，除了特別專業的網路安全分享，也會穿插一些科普文章與實體安全討論，歡迎分享給你的親朋好友，畢竟多了解一些安全也就多一份保障。