資安架構師決策錄 (03)：從零開始建信任

Trust Starts From Zero

你必須面對的信任問題 The Trust Problem

如果所有 authorization input 都可能錯，那我們為什麼還相信「上一次的決策」？ If every authorization input can be wrong,why do we still trust the previous decision?

從第一篇開始，我們從 Identity 談到 Authorization Model。 Since the first article, we moved from Identity to Authorization models.

我想我們目前有一個小小的共識 By now, we probably agree on a few things.

Identity 也許不可靠 Identity is not always reliable. Permission 也許不可靠 Permissions can be misconfigured. Context 也有可能不可靠 Context signals can also lie.

如果什麼都不可靠 那我們到底怎麼做? If none of these are reliable, what do we rely on?

如果我們細細推敲，可以得到一個簡單卻真實的結論 If we reduce the problem to its core, only one thing remains.

安全其實只是信任的問題，僅此而已 Security is ultimately a question of trust. Nothing more.

於是到這裡，我們可以推斷出 Which leads to a simple observation.

所有安全架構，本質上只是在回答兩個問題 Every security architecture answers two questions.

誰值得被信任，以及信任可以維持多久 Who should be trusted? And how long should that trust last?

信任其實是所有系統的核心。 Trust sits at the center(Core) of every system.

我相信你是誰，所以我讓你使用服務。 If I trust your identity, I allow you to use a service.

我相信你的權限是真的，所以我允許這個操作。 If I trust your permissions, then action is allowed.

在人與人之間，我相信信任也是一個重要的價值 The same rule applies between people.

我越相信你，我才越可能給你更多。 More trust leads to more access.

比如借錢給你，或者讓你進我家。 Lending you money. Or letting you into my house.

上一篇裡 我們也花了不少時間來討論ABAC In the previous article, we spent time discussing ABAC.

甚至很多人直接說，ABAC 就是零信任的核心。 Some people simplify it like - ABAC is the core of Zero Trust.

但在零信任的世界裡，資安的本質變成一件事 In a Zero Trust world, security does one thing.

不斷重新評估信任。 It continuously re-evaluates trust.

於是在這裡我們要先問自己一個問題 Which brings us to the real question.

什麼是零信任? What is Zero Trust?

信任歸零 Resetting Trust

當我們想到零信任 When people talk about Zero Trust,

我相信大家腦海裡第一個出現的就是零信任之父John Kindervag說過的 we usually quote John Kindervag：

"Never Trust, Always Verify."

這是一個好標語，簡潔有力，也是很多人的聖經 It’s a powerful slogan—simple and memorable.

於是很多人會理解為 永不信任 But many people interpret it as: Never trust anything.

不過，我們靜下來好好想一下 Let’s hit the pause button.

Zero Trust，真的等於「永不信任」嗎？ Does Zero Trust really mean never trust?

我們先定義一下什麼叫永不 Let’s first clarify what never actually means.

永遠不會?永遠不能?永遠不可以? Does it mean something that will never happen? Something that is mission impossible?

像是以前人認為永遠不可能到月球，地球永遠不可能是圓的 Historically, people once believed that humans would never reach the moon, or that the Earth could never be round.

這個定義應該是永遠不會發生 In that sense, “never” means something that simply cannot happen.

所以如果真的「永不信任」： So if we literally never trust,

Server 永遠不該開放存取 Servers should never allow access.

Session 永遠不該成立 Sessions should never be established.

Authorization 永遠不該成功 Authorization should never succeed.

服務不給用，連線不成立，系統無法運作。 No services, no connections, no system operations.

這才算是真的永不信任。 That would be true “never trust”.

就像把資料放在堅不可摧的保險箱，但沒有任何人有鑰匙或密碼 Imagine putting data inside an unbreakable vault, But nobody has the key.

他確實不可用，但也永遠不可用 It is perfectly secure, And completely useless.

所以下一個問題馬上就來了 So the next question naturally arises

Zero Trust，到底是「不信任任何人」，還是「不信任任何過去的決策」 *Does Zero Trust mean: trusting no one at all,or trust no past decisions?*

關於這個問題，我有一個答案：信任從零開始。 My answer is simple "Trust starts from zero."

這個觀點其實也是我從 WUSON 老師那裡學到的。 This idea was something I first learned from my mentor, WUSON.

但老師說的不代表就一定對， But even a master’s words shouldn’t be accepted blindly.

我們還是需要找到能說服自己的理由。 We still need our own reasoning.

於是我也翻了不少文件， So I started reading some documents.

有趣的是，文件裡有Never 有Trust，但並沒有任何Never Trust連在一起的用詞 Interestingly, the words never and trust both appear frequently— but the phrase “never trust” rarely appears as a formal definition.

另外一個很有趣的是，John Kindervag也提過 Another interesting observation comes from John Kindervag.

No More Chewy Centers: Introducing The Zero Trust Model Of Information Security P.5*

Trust but Verify is a Joke

因為驗證這件事本身非常困難，所以更多時候是信任，但不驗證 Because verification itself is extremely difficult, what often happens in reality is simple: we trust, but we do not actually verify.

在這裡我們又要引用一下NIST的定義 This is where the definition from NIST becomes useful.

在 NIST SP 800-207 裡其實講得很清楚： In NIST SP 800-207, Zero Trust is defined as:

Refer form Page.4

Zero trust is a cybersecurity paradigm focused on resource protection and the premise that trust is never granted implicitly but must be continually evaluated.

Zero Trust 要消除的，不是 Trust， What Zero Trust tries to eliminate is not trust itself.

而是：Implicit Trust（隱含信任） It eliminates implicit trust.

什麼是隱含信任？ So what exactly is implicit trust?

在Ep01時其實我們一直在討論這件事 We were already talking about this back in Ep01.

因為你在內網、因為你有 VPN IP、因為你有靜態密碼、因為你之前登入過 Because you are on the internal network, you have a VPN IP, and you've logged in before.

所以系統「預設」你仍然安全。 So the system assumes you are still safe.

但你真的是嗎？ But are you?

答案我們都知道了 We know the answer.

我們不是不信任”人”,我們是不信任「過去的狀態」

在 Zero Trust 裡，信任是短暫的（Ephemeral）。 In a Zero Trust model, trust is ephemeral.

上一秒你是安全的，不代表下一秒你的 Session Token 沒被劫持。 Being secure one second, does not mean your session token cannot be compromised the next.

所以，每一次 Request，我們都把信任歸零 Every request, trust is reset.

重新根據當下的 We recalculate the authorization decision based on the current:

Identity Context

來計算 Authorization Decision。 to produce a new authorization decision.

Zero Trust 不是信任的消失，而是信任的過期。 Zero Trust does not eliminate trust, it expires it.

也在上一篇提到，ABAC 持續觀察各種狀態 This is also why ABAC fits naturally into Zero Trust.

這也是ABAC會成為零信任的開關的理由 It continuously evaluates attributes and system state.

Project A 的困境 The Dilemma in Project A

在Project A裡 因為盤點出來的一個身份問題 In Project A, the trigger was an identity issue discovered during an audit.

我們討論到是不是要將身份驗證進階到ABAC The discussion quickly turned to whether RBAC should evolve into ABAC.

那麼下一個想法被提出，我們是不是 Then a natural question followed.

藉著導入ABAC 開始將內部環境走向零信任 If we are introducing ABAC anyway, should we move the internal environment toward Zero Trust as well?

於是討論很快就走到三個關鍵字 The conversation quickly converged on three ideas.

身份驗證，設備驗證，信任推斷 Identity verification, device verification, and trust inference.

但內部的身份如此雜亂，本來就難以統一控管， But reality hit quickly: internal identities were a complete mess.

要處理身份，要做好設備，又要能夠判斷當前狀態 managing identity, device posture, and runtime context together at once

在這樣的現況下，全面導入ABAC簡直天方夜譚 made a full ABAC rollout feel unrealistic.

我們怕的不是架構複雜，但怕的是在不明確的狀況下重構我們的世界 It wasn’t architectural complexity that worried us — it was rebuilding everything without clear boundaries.

在連續幾場會議，討論，或者我們可以說理性溝通(ㄔㄠˇㄐㄧㄚˋ) After several meetings — or what we politely called “rational discussions” (arguments).

畢竟，內部會議上更多的是互推皮球的戲碼 In enterprise meetings, responsibility often moves faster than decisions anyway.

「有些業務總說買他們的 Agent 就能零信任。 Some sales reps keeps telling us their agent delivers Zero Trust.

聽起來就像是完美的一鍵安裝，簡直讓人心動不已。 It sounds like a perfect one-click solution.

但現實是，主體、客體、Security Clearance、HR大家的角度定位都模糊不清，你要怎麼對它做 ABAC？」 “But when subjects, objects, and clearance levels are not even defined, how exactly do you implement ABAC?”

最後我們達成了一個比較務實的共識 Eventually, we reached a more pragmatic conclusion.

混用 + 逐步導入。 A hybrid model, introduced gradually.

什麼意思? What does that mean in practice?

上一章我們提到了，權限模型必須取捨。 In the previous chapter we mentioned that access models require trade-offs.

但在 Zero Trust 的世界觀下，這個前提本身就有問題。 But in a Zero Trust mindset, that assumption itself becomes questionable.

誰說一定要二選一？ Who said we must choose only one?

內部的環境本來就有一些RBAC，加上local account The internal environment already had RBAC systems and local accounts.

先在幾個相對可控的環境導入 ABAC。 So we introduce ABAC only in controlled environments first.

而其他本來就在使用RBAC系統則先維持， Existing RBAC systems remain in place.

但加入一些 Context 條件，例如：時間、來源位置 But we begin adding contextual conditions such as: time restrictions and source location.

同時，逐步把部分身份整合到 IdP，這會是Project A裡面比較可實踐的做法。 At the same time, gradually integrating some identities into the IdP will be a more feasible approach within Project A.

企業環境本來就是疊床架屋的產物,很難一次性建構出完美的世界。 Enterprise environments are layered over time; rebuilding them perfectly in one step is unrealistic.

RBAC 作為 baseline containment RBAC provides the baseline containment.

Conditional RBAC（例如時間條件）作為過渡 Conditional RBAC — such as time-based restrictions — serves as a transitional step.

ABAC 用於高敏感資產 ABAC can then be applied to high-sensitivity resources.

Step-up Auth 用於高風險行為 Step-up authentication protects high-risk operations.

例如，在雲端 IAM 裡，我們其實可以很容易地在 RBAC 上加入條件限制,例如時間或星期條件，形成 Conditional RBAC。 For example, in cloud IAM systems, RBAC can easily be extended with conditions such as time or day-of-week.

GCP IAM 中的 Conditional RBAC（加入時間條件） For instance, Conditional RBAC in Google Cloud IAM.

他從來不是一次性導入 This transformation never happens all at once.

而是分區、分資產、分風險等級 逐步 Rollout It is rolled out gradually — by environment, asset type, and risk level.

守門員在哪裡? Where Enforcement Happens

到了這裏還有一個更關鍵的問題 At this point, another critical question appears.

這些 Policy 要在哪裡執行？ Where should these policies actually be enforced?

如果 Trust 必須在每一次 Request 被重新計算,那Enforcement，就不能像過去一樣只存在於「登入那一刻」。 If trust must be recalculated on every request, enforcement can no longer happen only at login.

它必須存在於，流量發生的路徑上 It must exist along the path where traffic actually flows.

前面提過 ABAC就是零信任的核心要素之一 Earlier we mentioned that ABAC sits at the core of Zero Trust.

而 ABAC 再往下拆， If we break ABAC down further,

就會走到 XACML we eventually arrive at XACML.

再帶出 PDP、PEP、PIP、PAP 這些是 XACML 定義的授權架構元件。 This model introduces several core components: PDP, PEP, PIP, and PAP.

在這裡，我們先不談技術細節或原理 For now, we will not dive into the implementation details.

我們可以參考下圖關於XACML的細部元件說明 But the architecture diagram illustrates the idea clearly.

例如 下圖所示

也就是在這時候，流量路徑執行的這個目標下，SASE 才開始變得合理。 Once enforcement moves onto the traffic path, SASE starts to make sense.

談到SASE 也許對很多經營者而言是一種問號 For many decision makers, however, SASE often raises a simple question.

到底為什麼要花大錢，去取代一個本來接近免費的VPN服務? Why spend a large budget replacing something that was almost free — a VPN?

很多人會認為，SASE 是 VPN 的升級版。 Many people assume SASE is simply a "Pro Max plus" version of VPN.

對，也不對。 That is both correct and misleading.

VPN 建立的是一次性信任（One-time Trust） VPN establishes one-time trust.

而 Zero Trust 要求的是持續性驗證（Continuous Evaluation） Zero Trust requires continuous evaluation.

SASE 追求的目標，不是讓你「連進來」而已。 The goal of SASE is not merely to allow connections.

而是把 PEP（Policy Enforcement Point），從內網邊界，移動到： 每一次存取請求的 runtime decision layer。 Instead, it moves the Policy Enforcement Point from the network perimeter to the runtime decision layer of every request.

「VPN 給的是一張門票，一張進入內部網段的門票，一旦進門，隱含信任就產生了，勒索軟體就有機會在裡面橫向移動。 VPN gives you a ticket into the internal network. Once inside, implicit trust begins — and lateral movement becomes possible.

而 SASE 給的是一條只通往『單一應用程式（Specific Application）』的限時專屬隧道，而且這條隧道還有可能會根據你當下的設備分數隨時關掉。」 SASE instead builds a short-lived tunnel to a specific application — and that tunnel can disappear the moment your device posture changes.

如果你同意我們前面說的 If you agree with the earlier argument,

安全的本質是信任 that security is fundamentally about trust,

在 Project A 裡 Back in Project A

當我們終於對內部信任模型達成共識之後。 after we finally reached agreement on the internal trust model.

負責Data的Engineer這時候抬起頭，緩緩的問了一句。 the data engineer looked up and asked a simple question.

SaaS上面的資料呢? “What about the data stored in SaaS?”