資安架構師決策錄 (02)：權限模型的取捨

當身份本身不再可靠 When Identity Itself Is No Longer Reliable

如果你同意我們在前一章的結論 If you agreed with the conclusion from the previous chapter:

當我們開始接受這件事之後，下一個問題其實不言而喻 Once we accept that, the next question is obvious:

如果身份本身並不穩定 If identities aren’t stable

那麼所有建立在身份之上的授權決策，真的還能被視為可靠嗎？ authorization decisions derived from it are not guarantees — they are assumptions.

在我們開始討論之前，無可避免地需要回顧一下授權模型的演進。 Before diving in, it’s inevitable to revisit the evolution of access control models.

包含了 Including:

• 自主型存取控制（DAC）(Discretionary Access Control)
• 強制型存取控制（MAC）(Mandatory Access Control)
• 角色型存取控制RBAC (Role-Based Access Control)
• 屬性型存取控制ABAC (Attribute-Based Access Control)
• 基於風險的存取控制Risk-Based Access Control
• 規則存取控制 Rule-Based Access Control
• 基於歷史的存取控制 History-Based Access Control

每一代模型，都在試圖修補前一代無法處理的問題。 Access control models do not replace one another — they compensate for failure modes their predecessors were never meant to detect.

而在多數現代企業環境中，我想我們可以先大膽假設 "RBAC" 幾乎已經成為預設的控管方式： RBAC has quietly become the default trust distribution mechanism in modern enterprise environments.

我們分配群組、定義角色，再透過角色對應權限來限制存取範圍。 We assign groups, define roles, and map permissions through these roles to restrict access.

這套模型的邏輯非常簡單，只要你屬於這個角色，你就被允許執行這個行為。 Its logic is simple: belong to the role, and you’re allowed to perform the action.

如同你所知道的，RBAC 並不會驗證 As you know, RBAC doesn’t check:

• 這個請求來自哪一台設備 Which device the request comes from
• 是否為受管控裝置 Whether the device is managed
• 是否來自預期的網路環境 Whether it comes from an expected network
• 是否在合理的任務執行時間內 Whether it happens within expected operational hours

它只回答一個問題： 你是誰？ 而不會去問： 你現在的狀態是什麼？ It confirms the persona, but ignores the context.

就像我們當兵時在喊的站住口令誰，只要答的出來，你就是友軍，就算你的衣服穿的跟我不太一樣也沒關係。 It’s like the classic WWII D-Day challenge: whisper "Thunder" to my "Flash", and you're an ally—even if your uniform screams otherwise.

在網路邊界仍然清晰的年代，這其實沒有太大的問題。 Back when network perimeters were intact, this worked well enough.

但如今：身份可以被複製、Access Token 可能被竊取、設備可能被接管、BYOD 與遠端辦公成為常態，RBAC 仍然會選擇信任這個身份。 Today, identities can be cloned, access tokens stolen, devices hijacked. BYOD and remote work are standard. RBAC still chooses to trust the identity.

因為那正是它被設計出來要做的事情。 Because that’s exactly what it was designed to do.

Project A：當 RBAC 開始信錯人 When RBAC Trusted the Wrong Entity

如同我們序章談到的，我們有著一個虛擬專案Project A As mentioned in the prologue, we are grounding our discussion in a hypothetical scenario: Project A.

Project A 的開始，其實只是一次很普通的權限盤點。 Project A started as an ordinary permission audit.

在例行性稽核中，內部偶然發現某個用於資料同步的服務帳號（Service Account），同時被指派了兩個角色： During a routine audit, we found that a service account for data sync had been assigned two roles:

• Data Processing
• Backup Operator

在 RBAC 的邏輯下，這其實非常合理。 From an RBAC perspective, this made perfect sense.

這個帳號確實需要： This account indeed needed to:

• 讀取特定資料庫 Read specific databases
• 存取部分備份資源 Access some backup resources
• 定期執行同步任務 Perform scheduled sync tasks

因此在既有設計中，我們讓這個帳號同時擁有這兩個角色，而這個設計，多年來從未出過問題。 So in the original design, it had both roles—and for years, there was no issue.

直到某一天，這個服務帳號的 Access Token 被用在一台未受管控的設備上。 Until one day, its access token was used on an unmanaged device.

RBAC 看不見這件事。 RBAC didn’t see it.

它只知道：這個身份，屬於這個角色，而這個角色，被允許存取這個資源。 It only knew: this identity belongs to the role, and the role is allowed to access the resource.

於是：同步任務成功執行、備份資源成功讀取、橫向移動也成功發生。 So: the sync ran, backups were accessed, lateral movement succeeded.

從 RBAC 的角度來看，這一切都符合既有授權邏輯。 From RBAC’s perspective, everything was normal.

沒有任何違規。 No policy violation occurred.

因為 RBAC 從來沒有被設計來回答：這個「身份」，現在是從哪裡來的？ Because RBAC was never meant to answer:Where is this “identity” coming from right now?

已知與未知 The Known and The Unknown

在事件檢討中，除了首當其衝的憑證洩漏問題 我們開始重新思考一個問題： During the post-incident review, beyond the obvious credential compromise, we began questioning something more fundamental:

我們是否應該讓授權決策，考慮「身份以外」的訊號？ Should we base authorization decisions on signals beyond just identity?

於是，在 Project A 裡，導入 ABAC 的想法被提出。 And that’s when ABAC entered the conversation in Project A.

資安團隊希望在每一次存取發生時，系統都能重新判斷： The security team wanted the system to re-evaluate every single access attempt:

• 是否為受管設備？ Is this a managed device?
• 是否通過裝置健康度檢查？ Does it pass the device health check?
• 是否來自預期網段？ Is it coming from an expected network segment?
• 是否符合任務執行時間？ Is it within the expected operational hours?

換句話說，授權決策不再只依賴身份，而是依賴「Identity + Context」。 Authorization no longer derives solely from identity — but from its surrounding context.

ABAC 的設計，是透過多種屬性（attributes） 來描述存取主體、資源與當下環境狀態，並由政策規則（policy）在執行時進行評估。 ABAC models access through attributes — of the subject, the resource, and the environment — evaluated against policy at runtime.

這使得授權行為，從單純的身份對應關係，轉變為一種基於語意描述的條件判斷過程。 This shifts authorization from simple identity mapping to a semantic, condition-based evaluation process.

系統不再只是在確認：你是誰？ The system stops just confirming: Who are you?

而是在嘗試理解，你現在處於什麼樣的狀態 Instead, it evaluates the state you operate in.

IT團隊也考量到維運上的問題 Operations had their own concerns.

在 RBAC 的世界裡，授權錯誤通常發生在事件之後。 In RBAC, authorization failures tend to surface after an incident.

但 ABAC 導入之後，錯誤可能會提前發生。 ABAC shifts failure into the authorization path itself.

當設備健康度判斷異常、Context 尚未同步、風險評分出現誤差 A failed posture check, stale context, or a miscalculated risk score —

系統有可能在正常營運流程中，拒絕一個原本合法的請求。 may cause the system to reject a legitimate request during normal operations.

這意味著，授權錯誤不再只是在「給太多」時發生， Authorization errors are no longer limited to excessive privilege.

而可能變成，在關鍵時刻，拒絕了正確的人。 they can mean denying the right person at a critical moment.

你要承擔什麼代價? What Are You Willing to Pay?

若我們都同意上面的討論 If we all agree on the discussion above

那此時應該意識到一件事 RBAC 與 ABAC 的差異，也許並不只是「授權方式」的不同。 then the difference between RBAC and ABAC may not lie in authorization method alone.

而是我們選擇讓錯誤發生在什麼時候。 It lies in when we allow failure to occur.

在大多數 RBAC 的實作中，信任的建立流程，其實可以被視為一條 一次性完成的 Trust Evaluation Flow。 In most RBAC implementations, trust is evaluated once — and reused thereafter.

（Adapted from NIST SP 800-162 Figure 7: ACL Trust Chain）

在此流程中，Access Control Decision發生於 Authentication 之後，並僅依賴於： Identity Credential Owner-defined Policy（ACL / Role Assignment） Access decisions occur post-authentication, based solely on identity credentials and owner-defined policy.

授權結果一旦產生，便可持續套用於後續的資源存取請求，而無須重新向其他信任來源查證。 Once granted, authorization is applied to subsequent requests without re-validation from other trust sources.

即使Access Token 已經外洩、設備遭到接管、使用者行為異常 Even if a token is leaked, a device is compromised, or behavior becomes anomalous

只要主體(Subject)仍然成立，授權就會被允許。 Authorization persists as long as the Subject remains valid.

錯誤通常發生在事件之後。 Failures emerge post-incident.

當攻擊已經開始橫向移動，甚至完成權限提升時，系統才意識到信任被濫用。 Often after lateral movement or privilege escalation has already begun.

但 ABAC 的世界恰好相反。 ABAC inverts this model entirely.

這條信任鏈會被拆解為一個，持續評估的 Policy Decision Process Trust becomes a continuously evaluated Policy Decision Process.

（Adapted from NIST SP 800-162 Figure 8: ABAC Trust Chain）

Access Control Decision 不再僅依賴於單一身份憑證，而是同時依賴於多個屬性來源（Attribute Authorities），例如： Access Control Decisions no longer hinge on a single credential — but on multiple Attribute Authorities, such as:

• HR 系統（Subject Attributes）
• 資料分類系統（Object Attributes）
• 裝置管理平台或威脅感測器（Environment Conditions）

換句話說，授權決策的信任根源，已從單一管理者轉變 變成分散於多個外部資訊來源。 In other words, the root of trust shifts from a single administrator to a distributed set of external information sources.

系統必須在每一次請求發生時，重新匯入並評估這些屬性資訊。 Attributes must now be re-ingested and evaluated at every request.

這代表授權決策的可信度，將不再只取決於身份是否正確指派， 而是極度依賴用於計算該決策之資訊的品質。 Authorization becomes constrained by the fidelity of the data used to evaluate it — not merely by correct identity assignment.

就正如 NIST SP 800-162（p.30）所提到的： As NIST SP 800-162 states:

談到「品質」，你可能會覺得有些抽象 一個屬性，究竟該怎麼判斷品質？ 在 NIST 的框架裡，是透過 「元屬性 (Metaattributes)」 的概念來解釋這個問題。 But what does "quality" actually mean for an attribute? NIST approaches this through the concept of Metaattributes.

對於這個名詞，我自己喜歡用資料的資料來解釋他 Simply put: data about the data.

而在 ABAC 的世界裡，系統不只要驗證「屬性」本身（例如：這個帳號是不是經理？），更要評估這項屬性的「信心水準 (Assurance Level)」。 包含它的權威性 (Authority)、新鮮度 (Freshness) 與準確度 (Accuracy)。 ABAC does not merely verify the claim — it evaluates the assurance behind it: Authority. Freshness. Accuracy.

既然談到數據品質，在資料探勘的領域裡，有一句名言 「GIGO (Garbage In, Garbage Out)。」 And in data science, there is an old truth: "Garbage In, Garbage Out".

在 ABAC 的世界裡，所有屬性與情境訊號，本質上都是決策輸入資料。 In ABAC, every attribute and contextual signal directly shapes the outcome of authorization.

當這些外部來源，無法提供即時、一致且正確的資訊時，基於這些輸入所做出的每一次即時授權推斷，都可能因資訊品質不足而產生誤判。 And when these inputs are stale, inconsistent, or inaccurate — every real-time authorization inference inherits that uncertainty.

在 RBAC 模型中，信任是一種在執行前被建立的靜態假設。 RBAC treats trust as something resolved before execution begins.

而在 ABAC 的決策流程裡，信任則變成一種需要在執行時，持續推斷的運算結果。 In ABAC, trust becomes a runtime inference.

這使得系統設計的邏輯，不再只是 誰被允許存取什麼資源？ System design shifts from asking:Who can access what?

Trust，應該在 Authentication Time (驗證)被一次性建立， 還是應該在 Authorization Time (授權)被持續推斷？ Should trust be established once at Authentication Time — or continuously inferred at Authorization Time?

那麼，當所有授權模型，甚至信任推斷，都有可能需要承擔出錯的代價時。 When every authorization model — and even trust inference itself — comes with a cost of failure...

我們是否真的應該——永遠不要信任任何一次存取請求？ Should we, then, simply never trust any access request?