 Java 權限體系 第一篇：從 ACL 到 RBAC、ABAC、ReBAC——權限模型到底在解決什么問題)
玩轉(zhuǎn) Java 權限體系 第一篇從 ACL 到 RBAC、ABAC、ReBAC——權限模型到底在解決什么問題Java 圈里聊權限開口基本都是 Spring Security、Shiro、Sa-Token。但這三個東西解決的是同一層問題嗎其實不是。它們更像執(zhí)行器而真正決定你系統(tǒng)會不會越權、能不能審計、要不要重寫一遍的是它們背后那套訪問控制模型。筆者的第一個真實教訓來得很早某天產(chǎn)品加了一句部門經(jīng)理也能看本部門的數(shù)據(jù)于是PreAuthorize(hasRole(MANAGER))后面開始長出一堆if (deptId user.deptId)半年后沒人說得清哪個接口是完整的權限判斷。這就是典型的模型沒選對框架只能拿來打補丁。這一篇不談代碼怎么寫只把 ACL / DAC / MAC / RBAC / ABAC / ReBAC 這條演進線講清楚每個模型的判定式是什么、它在什么場景會撐不住、以及這些模型在 Java 生態(tài)里分別落在哪一層。文末會給出筆者自己的選型判斷。1. 先把三個詞分開認證、授權、訪問控制模型混用這三個詞是絕大多數(shù)權限討論吵不起來的原因。NIST 在 SP 800-162 里劃得很干凈認證是驗證主體確實被授權使用它拿出來的那個標識而授權是對一次具體請求作出允許或拒絕的決定兩者不是一回事。原文說得很直白——認證不等于訪問控制或授權。來源認證 Authentication → 你是誰登錄、token、Passkey、mTLS 授權 Authorization → 這一次請求能不能放行permit / deny 訪問控制模型 AC Model → 能不能這件事用什么數(shù)據(jù)結(jié)構(gòu)去表達和推理簡單理解模型是數(shù)據(jù)模型的選型框架是這套判定式的執(zhí)行位置。Spring Security 的過濾器鏈、Shiro 的Subject、Sa-Token 的StpUtil都是執(zhí)行位置它們并不強制你用哪種模型。順著這個劃分SP 800-162 還給出了一組后來被整個行業(yè)包括零信任標準沿用的角色詞組件全稱干什么PEPPolicy Enforcement Point攔截請求、執(zhí)行 PDP 的結(jié)論PDPPolicy Decision Point計算決策“評估適用的策略并給出結(jié)論”PIPPolicy Information Point提供決策所需的屬性數(shù)據(jù)PAPPolicy Administration Point寫策略、測策略、調(diào)策略的后臺Context Handler—把上面幾方的調(diào)用順序編排起來來源這套詞很重要因為第四、第五篇里所有網(wǎng)關鑒權“授權中臺”把策略搬出應用的討論本質(zhì)都是在問同一件事你的 PEP 和 PDP 分別坐在哪里。2. 演進線從文件誰能讀寫到每次請求重新判斷這條線不是編年史堆料每一步都在補上一步的表達能力缺口。1960s–70s 1992 / 1996 2004 / 2013 2013 / 2014 2019 2020 DAC · MAC → RBAC 模型 → ANSI INCITS 359 → XACML 3.0 → Zanzibar → 零信任 NIST DoD 場景 角色做中間層 2004 批準 屬性四分類 關系元組 SP 800-207 術語出自 權限掛角色 2012 修訂 userset 規(guī)則 2020-08 TCSEC SP 800-162 ABAC2014-01幾個關鍵錨點都能核對時間事件出處1960s–1970sDAC / MAC 概念出現(xiàn)在美國國防部應用術語在 TCSEC“Orange Book”中被定義NIST SP 800-1621973機密性模型 Bell-LaPadula 的原始載體是 MITRE 技術報告 MTR-2547其 Volume II 于 1996 年被期刊重刊DOI1975 / 1977Biba 完整性模型年份存在分歧工程文檔常寫 1975學術引用多為 1977 的 MITRE 報告原始報告本次未取到Casbin 文檔1992NIST 提出通用 RBAC 模型三條規(guī)則角色指派、角色授權、事務授權核心特征是所有訪問都經(jīng)由角色NIST RBAC FAQ1996RBAC 四層級模型RBAC0–RBAC3經(jīng)典論文IEEE Computer29(2): 38-47DOI2004-02-11NIST RBAC 模型成為美國國家標準ANSI/INCITS 359-2004NIST 項目頁2012-05-29該標準修訂為INCITS 359-2012同上2013-01-22XACML 3.0成為 OASIS Standard2.0 是 2005-02-011.0 是 2003-02-18OASIS2014-01NIST SP 800-162《ABAC 定義與考量》發(fā)布Final——注意中文資料里的2018 年多為轉(zhuǎn)載時間NIST2019GoogleZanzibar論文USENIX ATC 19標題為Google’s Consistent, Global Authorization SystemUSENIX PDF2020-08NIST SP 800-207《Zero Trust Architecture》發(fā)布NIST這里有個容易被忽略但很有說服力的Java 本地注腳JVM 自己就有一套代碼級授權java.security.Policy/ Security Manager從 Java 1.0 就在而它正在被官方拆除——JEP 411Status: Closed/DeliveredRelease 17把它標記為待移除JEP 486Release 24永久禁用它。JEP 411 的原話相當直白它多年來不是保護客戶端 Java 代碼的主要手段也很少被用于服務端維護成本卻很高并且官方明確不提供替代品。JVM 內(nèi)置授權Policy / Security Manager → 退場Java 17 棄用Java 24 永久禁用 Java 側(cè)權限模型剩下的三條落點應用框架Spring Security / Shiro / Sa-Token 容器規(guī)范Jakarta Authorization即 JACC 外置授權服務Casbin / OpenFGA / Cerbos / Keycloak注JEP 編號、日期與狀態(tài)均為 OpenJDK 官方頁面可核對的事實“最終收斂到三條路是筆者歸納不是官方表述。JACC 的定位是為授權模塊定義一個低層 SPI讓容器把授權決策外包給策略模塊”這一點與 PEP/PDP 分離是同一個思想。來源3. 五個模型的判定式一張表看懂差異把每個模型壓縮成一行判定式差異立刻就出來了。模型判定式本文歸納非原文公式權限存在哪撐不住的場景DACdecide(subject, object, ACL[object] ∪ 屬主自由裁量)對象上屬主可改對象海量時無法治理誰能改 ACL本身沒人管MACpermit ? 對象密級標簽被主體許可級別覆蓋用戶不能改標簽label業(yè)務系統(tǒng)沒有密級這種東西變更要走中央授權RBACpermit ? ?r ∈ 會話中激活的角色 : (r, op, obj) ∈ PAuser→role→permission 三張關系表約束涉及對象屬性/時間/位置時只能把約束編進角色 → 角色爆炸ABACpermit/deny ? policy(attrs(subject), attrs(object), attrs(action), attrs(environment))策略布爾規(guī)則集決策前無法回答誰能看這條數(shù)據(jù)審計昂貴ReBACCheck(user#relationobject)由關系元組 userset 重寫規(guī)則展開關系元組圖屬性類條件需額外機制可讀性依賴圖遍歷與緩存Q1ACL 和 RBAC 到底差在哪一步差在中間層。ACL 把誰能對這個對象干什么直接寫在對象上Windows 文件權限、Linux 的 owner/group/other、PostgreSQL 的GRANT、K8s 的 RoleBinding 都是這一族。它的致命問題不是不安全而是沒法批量管理一百萬條文檔各自帶一張 ACL你無法回答這個新員工多了哪些權限。RBAC 的關鍵設計是引入角色作為唯一的授權通道。NIST FAQ 里那句a key feature of this model is that all access is through roles就是這個意思——權限不許直接掛到用戶身上。來源順帶把常被混用的兩個詞分清用戶組是用戶的集合角色是權限的集合組不攜帶權限角色攜帶。RBAC 的標準結(jié)構(gòu)里還有會話中激活角色的子集這一層Core RBAC 明確包含 role activation這也是 RBAC 比權限集合打平多出來的能力。NIST RBAC 參考模型由四個組件構(gòu)成前兩個是主體后兩個才是約束組件管什么Core RBAC最小元素集與關系用戶-角色指派、權限-角色指派、會話內(nèi)角色激活。標準明確Core 在任何 RBAC 系統(tǒng)里都是必需的其余組件互相獨立Hierarchical RBAC角色繼承引入角色的授權用戶集 / 授權權限集Static SoD靜態(tài)職責分離約束用戶到角色的指派比如同一人不能同時擁有出納和會計Dynamic SoD動態(tài)職責分離約束同一次會話里被激活的角色可以同時擁有但不能同時啟用來源這張表后面會用到標準里的約束只有 SoD 這兩種它們只管角色完全不涉及對象屬性、行范圍、時間窗、審批關系。Q2ABAC 的四類屬性是哪四類先給一句最省事的對照RBAC 判定用 1 個屬性角色 → 有 NIST 標準INCITS 359 ABAC 判定用 4 類屬性主體/對象/操作/環(huán)境 → 標準載體是 SP 800-162 XACML這里必須說清一個措辭分歧否則容易被同行挑刺四類屬性的分類法其實來自 XACMLsubject / (resource) object / action / environment conditionsOASIS 規(guī)范里對應四個屬性類別 URI而 SP 800-162 正文用的是subject / object / environment / operations(activities)。兩邊語義一致命名不同。來源1 來源2ABAC 的定義原文值得抄進設計文檔主體對對象執(zhí)行操作的請求是否被批準取決于主體被賦予的屬性、對象被賦予的屬性、環(huán)境條件以及一組以這些屬性和條件表達的策略。SP 800-162 里最有價值的一句話是它沒有把 ABAC 說成 RBAC 的替代品而是反過來定位ACL 和 RBAC 在某種意義上是 ABAC 的特例ACL 工作在身份這個屬性上RBAC 工作在角色這個屬性上。與 ABAC 的關鍵差異在于用復雜布爾規(guī)則集表達策略這個概念。來源同一節(jié)還點了另一處要害ACL/RBAC 也能達成 ABAC 的目標但要證明訪問控制需求被滿足會變得困難而昂貴而且一旦需求變化很難找出所有需要跟著改的實現(xiàn)位置。這句話就是權限系統(tǒng)重構(gòu)的立項理由。Q3ReBAC 是不是新東西思想不新工程化是新的。ReBAC這個縮寫不是 Zanzibar 論文的用詞——論文自稱是一個存儲與評估訪問控制列表ACL的全球系統(tǒng)把 Zanzibar 歸納為 ReBAC 是后續(xù)開源實現(xiàn)OpenFGA、SpiceDB做的事。來源它的數(shù)據(jù)模型只有兩樣東西一張元組和一組展開規(guī)則元組?object?#relation?user? object namespace:object-id user user-id | ?object?#relationuserset 展開this直接| computed userset同對象內(nèi)其他關系| tuple to userset沿父對象繼承 算子union / intersection / exclusion論文給的兩個數(shù)字解釋了為什么值得學擴展到數(shù)萬億張 ACL、每秒數(shù)百萬次授權請求三年生產(chǎn)運行中維持95 分位延遲低于 10 毫秒、可用性高于 99.999%服務對象包括 Calendar、Drive、Photos、YouTube。一致性靠zookie協(xié)議保證 ACL 更新與內(nèi)容更新之間的因果順序。來源用 DSL 寫出來是這樣OpenFGA 的語法viewer from parent_folder就是 tuple-to-usersetdefine viewer: [user, domain#member] or writer or viewer from parent_folder來源ReBAC 真正的獨特點是對象與對象之間的關系文件夾→文檔是一等公民。RBAC 的對象只是被 permission 命中繼承要靠建模ReBAC 里繼承是一次查詢。至于部門即父對象這類組織關系天然就該存成元組而不是存成角色。工業(yè)實現(xiàn)的取舍也可以核對OpenFGA 明確其 JSON 語法closely tracks the original Zanzibar paper 的語法DSL 只是編譯到 JSON 的語法糖CNCF 項目2022-09-14 入選2025-10-28 升為 Incubating來源SpiceDB 則在與 Zanzibar 的官方對照頁里承認簡化了存儲與一致性Zanzibar 只支持 SpannerSpiceDB 支持多種 datastorezookie 換成了更簡單的讀寫一致性選項來源。純關系模型表達不了工作時間以外不許導出這類屬性條件所以兩家各補了一個口子SpiceDB 叫Caveats可命名、附著到關系上的布爾表達式官方稱用于建模ABAC 風格的決策OpenFGA 叫Conditions用 Google CEL 寫表達式。來源1 來源24. 三個說法很流行但其實不準確的問題這一節(jié)是筆者覺得最值得單獨拎出來的部分——它們直接決定選型討論會不會跑偏。Q1角色爆炸role explosion為什么會發(fā)生這不是坊間吐槽SP 800-162 有原話RBAC 不容易支持多因子決策例如依賴物理位置、依賴專項培訓的場景RBAC 的角色指派往往基于較靜態(tài)的組織位置而要在這類場景里實現(xiàn)訪問控制決策就需要創(chuàng)建大量臨時性、成員極少的角色——這正是通常所說的角色爆炸。來源因果鏈是這樣的角色只能掛在用戶的靜態(tài)組織位置上 ↓ 約束一旦涉及 對象屬性 / 部門 / 時段 / 審批關系 只能把約束編碼進角色本身 ↓ 角色數(shù)量 ≈ 角色 × 部門 × 數(shù)據(jù)范圍 × 時段 ↓ 這些 ad hoc 角色成員極少、語義重復、無法向?qū)徲嫿忉尀槭裁从羞@個角色工業(yè)界兩個低成本補丁都在這條鏈上打洞Casbin 的RBAC with Domains給角色加一個域/租戶維度和RBAC with Conditions在規(guī)則上直接掛條件參數(shù)。來源1 來源2Q2RBAC 表達不了只看本部門數(shù)據(jù)這句話對不對過于絕對但工程語義上算半對。NIST FAQ 里專門有一節(jié)回應這類批評對方舉的例子是病歷權限建立在醫(yī)生與病人的具體關系上官方回答有兩個重點1992 年模型本身就是only if而非if的授權語義——訪問只有在滿足角色要求時才授予正是這樣才允許在訪問時追加額外約束但標準沒有規(guī)定這些額外約束該怎么實現(xiàn)它的設計是讓設計者自行添加約束來處理這些關系模型本身不會妨礙你加。來源再把第 3 節(jié)那張四組件表拿出來標準層面的約束組件只有 Static SoD 和 Dynamic SoD管的全是誰能同時/同時激活哪些角色。所以準確的表述是純 RBACCore Hierarchical SoD無法簡潔地表達行級/對象級約束硬要表達就要付出角色數(shù)量和維護成本的代價。中文社區(qū)那句RBAC 只能到菜單按鈕級數(shù)據(jù)權限必須靠 ABAC/ReBAC——這是工程經(jīng)驗的概括不是任何標準的表述寫方案時可以引但不要掛 NIST 的名義。Q3ABAC 是不是就更可控了ABAC 的代價在另一個維度決策前審計。SP 800-162 §3.1.2.3 明確要求企業(yè)需要事前審計before the fact audit能力——在請求發(fā)生之前就知道某人對哪些對象有權限、某對象被哪些人訪問。原文緊接著寫ABAC 系統(tǒng)可能不太適合高效地進行這類審計因為要算出誰能訪問這條數(shù)據(jù)需要巨大的數(shù)據(jù)檢索與計算量甚至可能要拿企業(yè)里每一個已知主體去模擬一次訪問請求。來源同文檔另一處還提醒采用分布式訪問控制架構(gòu)時審計訪問決策與事件的能力會受到影響。結(jié)論句原文這句很適合放進立項郵件ABAC 系統(tǒng)更復雜因此比更簡單的訪問控制系統(tǒng)實現(xiàn)和維護成本更高。但同一份文檔也承認ABAC 能實現(xiàn)既有的基于角色的策略并支持從角色化策略向更細粒度策略的遷移。NIST 自己在 RBAC 項目頁上對 ABAC 的概括更口語“ABAC 是一種基于規(guī)則的訪問控制方法容易搭起來但難以管理?！?. 零信任到底改變了什么、沒改變什么很多方案書把零信任當成權限模型的新一代其實不是。NIST SP 800-2072020-08Final的定義是一套不斷演進的網(wǎng)絡安全范式把防御從靜態(tài)的、基于網(wǎng)絡邊界的位置轉(zhuǎn)向聚焦用戶、資產(chǎn)和資源其規(guī)范性定義是在把網(wǎng)絡視為已被攻破的前提下最小化每次請求執(zhí)行精確、最小權限訪問決策時的不確定性。來源七條原則里與權限框架直接相關的三條② 所有通信一律受保護與網(wǎng)絡位置無關 ③ 對單個資源的訪問按每次會話授予 —— 進了 A 資源不等于能進 B 資源 ⑥ 所有認證與授權都是動態(tài)的、訪問前嚴格執(zhí)行交易過程中持續(xù)監(jiān)控可能重新認證與重新授權而且它把 PDP 又拆了一層Policy EnginePE做最終裁決“授予、拒絕或撤銷”Policy AdministratorPA執(zhí)行決策控制面與數(shù)據(jù)面分離。改變了什么維度傳統(tǒng)權限框架零信任之后信任來源網(wǎng)絡位置 / 內(nèi)網(wǎng)身份明確不因物理或網(wǎng)絡位置、不因資產(chǎn)歸屬而給隱含信任判定粒度一次登錄長期可信per-session、per-request持續(xù)重評估PEP/PDP 位置應用外圍一層攔截器往資源側(cè)搬成為獨立的、要有實時上下文和可撤銷能力的決策服務決策輸入角色角色 設備態(tài)勢 行為 環(huán)境屬性結(jié)論種類allow / denyallow / deny /revoke沒改變什么判定式本身仍是policy(attributes) → permit/deny也就是 ABAC 的語義PEP/PDP 這套詞匯也不是它發(fā)明的——SP 800-207 在給出 PDP/PEP 模型的段落有腳注 3明確寫著概念部分定義于 OASIS XACML 2.0。微分段也不等于零信任NIST 有意把它描述成 ZTA 的一種功能能力“這些定義仍在以某種方式相對邊界來定義自己比如微分段或微邊界”。還有一條常被忽略的適用邊界七條原則針對組織內(nèi)部或與伙伴組織協(xié)作完成的工作不適用于匿名公開或面向消費者的業(yè)務流程。做 C 端產(chǎn)品時把 ZT 原則原樣搬過來會寫出很重的方案。一句話總結(jié)筆者觀點零信任是部署與信任模型不是新的訪問控制模型。它給權限框架出的真正考題是——你的授權決策必須能實時拿到上下文并且能被撤銷。6. 這些模型在 Java 生態(tài)里分別落在哪一層把前面的譜系映射到實際選型上一張表基本夠用模型Java 側(cè)的典型落點客觀狀態(tài)ACL / DAC文件與數(shù)據(jù)庫對象權限、Spring Security ACL 模塊對象級 ACE 存 DB、Shiro 的 Wildcard Permissionsprinter:delete式通配串小眾但沒死ACL 模塊仍是官方文檔里的一章RBAC幾乎所有后臺的角色-菜單-按鈕三件套、Keycloak 的 Role/Group Policy、Casbin 的p, sub, obj, act RBAC matcher事實上的默認起點ABACKeycloak Authorization ServicesRole/Group/User/Client/Time/Regex/JS 策略并對接 UMA、CerbosResource/Principal/Role/Scoped Policy Conditions Derived Roles、OPA/RegoCNCFGraduated2021-01-29、AWS Cedar策略語言化、可測試化ReBACOpenFGACNCF Incubating、SpiceDBZanzibar 血統(tǒng)元組存儲數(shù)據(jù)權限行級PostgreSQL RLS9.5 引入、Oracle VPD、SQL Server RLS2016 引入應用層 MyBatis/JPA 攔截器DB 層兜底 應用層拼接并存數(shù)據(jù)權限列級PostgreSQL 列級GRANT、Oracle “Grants of Privileges on Columns”原生支持但很少被應用用上混合Casbinacl/rbac/abac/orbac/blp/biba 等一整套可運行配置Java 是官方支持語言。注2026-02 已進入 Apache 孵化器官網(wǎng) casbin.org 現(xiàn) 301 至 casbin.apache.org單庫覆蓋多模型代價是模型語法要自己維護兩個技術細節(jié)值得現(xiàn)在就記住第四篇會正面用到RLS 是會被繞過的。PostgreSQL 官方文檔寫明superuser 與帶BYPASSRLS屬性的角色總是繞過行級安全表 owner 默認也繞過可用ALTER TABLE ... FORCE ROW LEVEL SECURITY讓它受約束唯一鍵/主鍵/外鍵這類引用完整性檢查總是繞過行安全。這意味著用了 RLS 就安全是錯的——應用賬號一旦是表 owner策略形同虛設。來源Oracle VPD 的機制是改 SQL而不是過濾結(jié)果。官方定義是創(chuàng)建控制數(shù)據(jù)庫行級與列級訪問的安全策略做法是給命中的表/視圖/同義詞上的 SQL動態(tài)追加一個 WHERE 子句實現(xiàn)入口是DBMS_RLS包配合 application contexts。來源至于策略語言本身的語義有一個容易記錯但很關鍵的點Cedar 是默認拒絕且顯式 forbid 優(yōu)先。官方規(guī)則原文是至少一條匹配策略為 Allow 且恰好零條為 Deny 時整體才是 Allow并明確兩條原則——空策略集的默認結(jié)果是implicit deny任一策略給出 Deny顯式 Deny 總是覆蓋其它策略的 Allow。來源 同一頁還順手回答了這算 RBAC 還是 ABAC只有 scope 沒有附加條件的策略可以作為 RBAC 方案的一部分帶條件的策略可以作為 ABAC 方案的一部分。注Cerbos不在 CNCF 項目列表內(nèi)官方項目頁 404把它寫成CNCF 項目是常見錯誤。7. 標準之外token 這一層現(xiàn)在走到哪了第一篇不該以代碼結(jié)尾但應該給一條時間是否可信的核對結(jié)論。截至 2026-09-29事項狀態(tài)出處OAuth 2.1仍不是 RFC。當前修訂draft-ietf-oauth-v2-1-16Last updated2026-09-02IESG 狀態(tài)僅 “I-D Exists”未進入 Last Calldatatracker草案里已經(jīng)確定的口徑PKCE變?yōu)楸匦鐸mplicit、資源所有者密碼憑證等不再被規(guī)定redirect URI嚴格字符串匹配目標是合并 RFC 8252 / 9700 / 瀏覽器應用草案并移除 RFC 9700 中被認定不安全的特性草案正文OAuth 安全 BCPRFC 9700BCP 2402025-01Updates 6749/6750/6819RFC EditorDPoPsender-constrained token 主路RFC 94492023-09。?? 不是 9440——RFC 9440 是Client-Cert HTTP Header FieldInformational解決TLS 在反向代理終結(jié)、Java 應用拿不到客戶端證書RFC EditormTLS 綁定 access tokenRFC 87052020-02比 OAuth 2.1 時代早得多不是新事物RFC EditorJWT 形態(tài)的 access tokenRFC 90682021-10RFC EditorOIDC Core 1.0OpenID Foundation 側(cè)為Final含 errata set 2。?? OIDC 已是 ISO/IEC 標準一說本次未核實規(guī)范正文只引用 ISO/IEC 29115別在方案里寫規(guī)范這里存在一個對權限框架很鋒利的張力筆者分析非標準表述OAuth 2.1 把 sender-constrained token 留在了擴展DPoP / mTLS而不是核心規(guī)范里因此 Java 框架默認發(fā)出的是不綁定的 bearer token而零信任要求可撤銷、持續(xù)重評估。這兩件事不靠給框架加攔截器解決只能靠短 TTL 撤銷通道或把決策外置到 PDP。第三、第五篇會分別處理這兩條路。最后總結(jié)先選模型再選框架。Spring Security / Shiro / Sa-Token 都是執(zhí)行器它們不阻止你寫出一個 ACL 系統(tǒng)也不保證你能寫出可審計的 ABAC 系統(tǒng)。RBAC 是默認起點而不是終點。它帶來的確定性權限只經(jīng)由角色、角色只經(jīng)由指派非常有價值一旦約束涉及對象屬性和環(huán)境你要么走域/條件補丁要么接受角色爆炸。RBAC 表達不了數(shù)據(jù)權限這句話別原樣引用。標準的態(tài)度是允許你加約束但不告訴你怎么加——真正的問題不是不能表達是表達得不可審計。ABAC 換來的細粒度要用審計成本付。上線前先確認你能回答誰能看這條數(shù)據(jù)而不是只確認這次請求被拒了。ReBAC 值得學的不是名字是關系是一等公民。組織樹、文件夾、共享鏈、租戶層級本來就該是數(shù)據(jù)而不是角色。零信任沒有替代任何模型。它替代的是一次登錄長期可信并把問題從權限判斷放在哪變成決策能不能實時、能不能撤銷。對后端/架構(gòu)崗筆者個人更關注三件事權限點的唯一權威存儲在哪里、需求變更時改動面能不能被枚舉、以及審計能不能在事故前而不是事故后回答誰有權。下一篇測評篇會把鏡頭拉回到三個 Java 框架本身過濾器鏈、Subject、StpUtil三種架構(gòu)到底在哪些地方不可互換。事實說明文中所有標準編號、發(fā)布日期、版本狀態(tài)與引文均在 2026-09-29 逐條核對一手來源Biba 年份1975/1977與 ABAC四類屬性措辭存在來源分歧已在正文標注DAC 的提出年份、TCSEC 確切編號、OIDC 的 ISO/IEC 狀態(tài)未取到一手依據(jù)故正文未作斷言。帶筆者歸納/筆者觀點標記的段落為分析而非標準表述。參考資料 致謝[1] NIST SP 800-162《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》[2] NIST SP 800-162 發(fā)布頁2014-01, Final[3] NIST RBAC 項目頁標準沿革與文獻清單[4] NIST RBAC FAQ四組件、RBAC0-3、約束與批評回應[5] NIST CSRC 術語表DAC MAC[6] NIST SP 800-207《Zero Trust Architecture》PDF2020-08[7] USENIX ATC 19Zanzibar — Google’s Consistent, Global Authorization System[8] OASIS XACML 3.0 Core Specification2013-01-22[9] Bell-LaPadula 原始報告重刊Journal of Computer Security, DOI 10.3233/JCS-1996-42-308 IEEE Computer 29(2):38-47 RBAC ModelsDOI 10.1109/2.485845[10] OpenJDK JEP 411棄用 Security Manager JEP 486永久禁用 Security Manager[11] Jakarta AuthorizationJACC規(guī)范頁[12] Spring Security 參考文檔ACL 模塊 過濾器架構(gòu)[13] Apache ShiroPermissions 與 News3.0.x 發(fā)版動態(tài)[14] Casbin 支持模型清單 RBAC with Domains RBAC with Conditions BLP Biba PBAC OrBAC[15] OpenFGAAuthorization Concepts Configuration Language Conceptsstore/tuple/model/Condition[16] CNCF 項目頁OpenFGAIncubating, 2025-10-28 OPAGraduated, 2021-01-29[17] Authzed SpiceDB與 Zanzibar 的對照 Caveats[18] AWS Cedar 策略語言文檔 Cedar Policy Syntaximplicit deny 與 forbid 優(yōu)先[19] Cerbos 文檔首頁[20] OPA 文檔首頁 Data Filtering with OPA[21] PostgreSQL 文檔Row Security Policies CREATE POLICY GRANT列級權限[22] Oracle Database 19c 安全指南Virtual Private Database[23] Microsoft SQL ServerRow-Level Security[24] IETF datatrackerOAuth 2.1 草案狀態(tài) draft-ietf-oauth-v2-1-16 正文[25] RFC 9700OAuth 安全 BCP RFC 9449DPoP RFC 9440Client-Cert 頭 RFC 8705mTLS 與證書綁定 token RFC 9068JWT 形態(tài) access token[26] OpenID Connect Core 1.0Final, errata set 2 玩轉(zhuǎn) Java 權限體系 第一篇：從 ACL 到 RBAC、ABAC、ReBAC——權限模型到底在解決什么問題
玩轉(zhuǎn) Java 權限體系 第一篇從 ACL 到 RBAC、ABAC、ReBAC——權限模型到底在解決什么問題Java 圈里聊權限開口基本都是 Spring Security、Shiro、Sa-Token。但這三個東西解決的是同一層問題嗎其實不是。它們更像執(zhí)行器而真正決定你系統(tǒng)會不會越權、能不能審計、要不要重寫一遍的是它們背后那套訪問控制模型。筆者的第一個真實教訓來得很早某天產(chǎn)品加了一句部門經(jīng)理也能看本部門的數(shù)據(jù)于是PreAuthorize(hasRole(MANAGER))后面開始長出一堆if (deptId user.deptId)半年后沒人說得清哪個接口是完整的權限判斷。這就是典型的模型沒選對框架只能拿來打補丁。這一篇不談代碼怎么寫只把 ACL / DAC / MAC / RBAC / ABAC / ReBAC 這條演進線講清楚每個模型的判定式是什么、它在什么場景會撐不住、以及這些模型在 Java 生態(tài)里分別落在哪一層。文末會給出筆者自己的選型判斷。1. 先把三個詞分開認證、授權、訪問控制模型混用這三個詞是絕大多數(shù)權限討論吵不起來的原因。NIST 在 SP 800-162 里劃得很干凈認證是驗證主體確實被授權使用它拿出來的那個標識而授權是對一次具體請求作出允許或拒絕的決定兩者不是一回事。原文說得很直白——認證不等于訪問控制或授權。來源認證 Authentication → 你是誰登錄、token、Passkey、mTLS 授權 Authorization → 這一次請求能不能放行permit / deny 訪問控制模型 AC Model → 能不能這件事用什么數(shù)據(jù)結(jié)構(gòu)去表達和推理簡單理解模型是數(shù)據(jù)模型的選型框架是這套判定式的執(zhí)行位置。Spring Security 的過濾器鏈、Shiro 的Subject、Sa-Token 的StpUtil都是執(zhí)行位置它們并不強制你用哪種模型。順著這個劃分SP 800-162 還給出了一組后來被整個行業(yè)包括零信任標準沿用的角色詞組件全稱干什么PEPPolicy Enforcement Point攔截請求、執(zhí)行 PDP 的結(jié)論PDPPolicy Decision Point計算決策“評估適用的策略并給出結(jié)論”PIPPolicy Information Point提供決策所需的屬性數(shù)據(jù)PAPPolicy Administration Point寫策略、測策略、調(diào)策略的后臺Context Handler—把上面幾方的調(diào)用順序編排起來來源這套詞很重要因為第四、第五篇里所有網(wǎng)關鑒權“授權中臺”把策略搬出應用的討論本質(zhì)都是在問同一件事你的 PEP 和 PDP 分別坐在哪里。2. 演進線從文件誰能讀寫到每次請求重新判斷這條線不是編年史堆料每一步都在補上一步的表達能力缺口。1960s–70s 1992 / 1996 2004 / 2013 2013 / 2014 2019 2020 DAC · MAC → RBAC 模型 → ANSI INCITS 359 → XACML 3.0 → Zanzibar → 零信任 NIST DoD 場景 角色做中間層 2004 批準 屬性四分類 關系元組 SP 800-207 術語出自 權限掛角色 2012 修訂 userset 規(guī)則 2020-08 TCSEC SP 800-162 ABAC2014-01幾個關鍵錨點都能核對時間事件出處1960s–1970sDAC / MAC 概念出現(xiàn)在美國國防部應用術語在 TCSEC“Orange Book”中被定義NIST SP 800-1621973機密性模型 Bell-LaPadula 的原始載體是 MITRE 技術報告 MTR-2547其 Volume II 于 1996 年被期刊重刊DOI1975 / 1977Biba 完整性模型年份存在分歧工程文檔常寫 1975學術引用多為 1977 的 MITRE 報告原始報告本次未取到Casbin 文檔1992NIST 提出通用 RBAC 模型三條規(guī)則角色指派、角色授權、事務授權核心特征是所有訪問都經(jīng)由角色NIST RBAC FAQ1996RBAC 四層級模型RBAC0–RBAC3經(jīng)典論文IEEE Computer29(2): 38-47DOI2004-02-11NIST RBAC 模型成為美國國家標準ANSI/INCITS 359-2004NIST 項目頁2012-05-29該標準修訂為INCITS 359-2012同上2013-01-22XACML 3.0成為 OASIS Standard2.0 是 2005-02-011.0 是 2003-02-18OASIS2014-01NIST SP 800-162《ABAC 定義與考量》發(fā)布Final——注意中文資料里的2018 年多為轉(zhuǎn)載時間NIST2019GoogleZanzibar論文USENIX ATC 19標題為Google’s Consistent, Global Authorization SystemUSENIX PDF2020-08NIST SP 800-207《Zero Trust Architecture》發(fā)布NIST這里有個容易被忽略但很有說服力的Java 本地注腳JVM 自己就有一套代碼級授權java.security.Policy/ Security Manager從 Java 1.0 就在而它正在被官方拆除——JEP 411Status: Closed/DeliveredRelease 17把它標記為待移除JEP 486Release 24永久禁用它。JEP 411 的原話相當直白它多年來不是保護客戶端 Java 代碼的主要手段也很少被用于服務端維護成本卻很高并且官方明確不提供替代品。JVM 內(nèi)置授權Policy / Security Manager → 退場Java 17 棄用Java 24 永久禁用 Java 側(cè)權限模型剩下的三條落點應用框架Spring Security / Shiro / Sa-Token 容器規(guī)范Jakarta Authorization即 JACC 外置授權服務Casbin / OpenFGA / Cerbos / Keycloak注JEP 編號、日期與狀態(tài)均為 OpenJDK 官方頁面可核對的事實“最終收斂到三條路是筆者歸納不是官方表述。JACC 的定位是為授權模塊定義一個低層 SPI讓容器把授權決策外包給策略模塊”這一點與 PEP/PDP 分離是同一個思想。來源3. 五個模型的判定式一張表看懂差異把每個模型壓縮成一行判定式差異立刻就出來了。模型判定式本文歸納非原文公式權限存在哪撐不住的場景DACdecide(subject, object, ACL[object] ∪ 屬主自由裁量)對象上屬主可改對象海量時無法治理誰能改 ACL本身沒人管MACpermit ? 對象密級標簽被主體許可級別覆蓋用戶不能改標簽label業(yè)務系統(tǒng)沒有密級這種東西變更要走中央授權RBACpermit ? ?r ∈ 會話中激活的角色 : (r, op, obj) ∈ PAuser→role→permission 三張關系表約束涉及對象屬性/時間/位置時只能把約束編進角色 → 角色爆炸ABACpermit/deny ? policy(attrs(subject), attrs(object), attrs(action), attrs(environment))策略布爾規(guī)則集決策前無法回答誰能看這條數(shù)據(jù)審計昂貴ReBACCheck(user#relationobject)由關系元組 userset 重寫規(guī)則展開關系元組圖屬性類條件需額外機制可讀性依賴圖遍歷與緩存Q1ACL 和 RBAC 到底差在哪一步差在中間層。ACL 把誰能對這個對象干什么直接寫在對象上Windows 文件權限、Linux 的 owner/group/other、PostgreSQL 的GRANT、K8s 的 RoleBinding 都是這一族。它的致命問題不是不安全而是沒法批量管理一百萬條文檔各自帶一張 ACL你無法回答這個新員工多了哪些權限。RBAC 的關鍵設計是引入角色作為唯一的授權通道。NIST FAQ 里那句a key feature of this model is that all access is through roles就是這個意思——權限不許直接掛到用戶身上。來源順帶把常被混用的兩個詞分清用戶組是用戶的集合角色是權限的集合組不攜帶權限角色攜帶。RBAC 的標準結(jié)構(gòu)里還有會話中激活角色的子集這一層Core RBAC 明確包含 role activation這也是 RBAC 比權限集合打平多出來的能力。NIST RBAC 參考模型由四個組件構(gòu)成前兩個是主體后兩個才是約束組件管什么Core RBAC最小元素集與關系用戶-角色指派、權限-角色指派、會話內(nèi)角色激活。標準明確Core 在任何 RBAC 系統(tǒng)里都是必需的其余組件互相獨立Hierarchical RBAC角色繼承引入角色的授權用戶集 / 授權權限集Static SoD靜態(tài)職責分離約束用戶到角色的指派比如同一人不能同時擁有出納和會計Dynamic SoD動態(tài)職責分離約束同一次會話里被激活的角色可以同時擁有但不能同時啟用來源這張表后面會用到標準里的約束只有 SoD 這兩種它們只管角色完全不涉及對象屬性、行范圍、時間窗、審批關系。Q2ABAC 的四類屬性是哪四類先給一句最省事的對照RBAC 判定用 1 個屬性角色 → 有 NIST 標準INCITS 359 ABAC 判定用 4 類屬性主體/對象/操作/環(huán)境 → 標準載體是 SP 800-162 XACML這里必須說清一個措辭分歧否則容易被同行挑刺四類屬性的分類法其實來自 XACMLsubject / (resource) object / action / environment conditionsOASIS 規(guī)范里對應四個屬性類別 URI而 SP 800-162 正文用的是subject / object / environment / operations(activities)。兩邊語義一致命名不同。來源1 來源2ABAC 的定義原文值得抄進設計文檔主體對對象執(zhí)行操作的請求是否被批準取決于主體被賦予的屬性、對象被賦予的屬性、環(huán)境條件以及一組以這些屬性和條件表達的策略。SP 800-162 里最有價值的一句話是它沒有把 ABAC 說成 RBAC 的替代品而是反過來定位ACL 和 RBAC 在某種意義上是 ABAC 的特例ACL 工作在身份這個屬性上RBAC 工作在角色這個屬性上。與 ABAC 的關鍵差異在于用復雜布爾規(guī)則集表達策略這個概念。來源同一節(jié)還點了另一處要害ACL/RBAC 也能達成 ABAC 的目標但要證明訪問控制需求被滿足會變得困難而昂貴而且一旦需求變化很難找出所有需要跟著改的實現(xiàn)位置。這句話就是權限系統(tǒng)重構(gòu)的立項理由。Q3ReBAC 是不是新東西思想不新工程化是新的。ReBAC這個縮寫不是 Zanzibar 論文的用詞——論文自稱是一個存儲與評估訪問控制列表ACL的全球系統(tǒng)把 Zanzibar 歸納為 ReBAC 是后續(xù)開源實現(xiàn)OpenFGA、SpiceDB做的事。來源它的數(shù)據(jù)模型只有兩樣東西一張元組和一組展開規(guī)則元組?object?#relation?user? object namespace:object-id user user-id | ?object?#relationuserset 展開this直接| computed userset同對象內(nèi)其他關系| tuple to userset沿父對象繼承 算子union / intersection / exclusion論文給的兩個數(shù)字解釋了為什么值得學擴展到數(shù)萬億張 ACL、每秒數(shù)百萬次授權請求三年生產(chǎn)運行中維持95 分位延遲低于 10 毫秒、可用性高于 99.999%服務對象包括 Calendar、Drive、Photos、YouTube。一致性靠zookie協(xié)議保證 ACL 更新與內(nèi)容更新之間的因果順序。來源用 DSL 寫出來是這樣OpenFGA 的語法viewer from parent_folder就是 tuple-to-usersetdefine viewer: [user, domain#member] or writer or viewer from parent_folder來源ReBAC 真正的獨特點是對象與對象之間的關系文件夾→文檔是一等公民。RBAC 的對象只是被 permission 命中繼承要靠建模ReBAC 里繼承是一次查詢。至于部門即父對象這類組織關系天然就該存成元組而不是存成角色。工業(yè)實現(xiàn)的取舍也可以核對OpenFGA 明確其 JSON 語法closely tracks the original Zanzibar paper 的語法DSL 只是編譯到 JSON 的語法糖CNCF 項目2022-09-14 入選2025-10-28 升為 Incubating來源SpiceDB 則在與 Zanzibar 的官方對照頁里承認簡化了存儲與一致性Zanzibar 只支持 SpannerSpiceDB 支持多種 datastorezookie 換成了更簡單的讀寫一致性選項來源。純關系模型表達不了工作時間以外不許導出這類屬性條件所以兩家各補了一個口子SpiceDB 叫Caveats可命名、附著到關系上的布爾表達式官方稱用于建模ABAC 風格的決策OpenFGA 叫Conditions用 Google CEL 寫表達式。來源1 來源24. 三個說法很流行但其實不準確的問題這一節(jié)是筆者覺得最值得單獨拎出來的部分——它們直接決定選型討論會不會跑偏。Q1角色爆炸role explosion為什么會發(fā)生這不是坊間吐槽SP 800-162 有原話RBAC 不容易支持多因子決策例如依賴物理位置、依賴專項培訓的場景RBAC 的角色指派往往基于較靜態(tài)的組織位置而要在這類場景里實現(xiàn)訪問控制決策就需要創(chuàng)建大量臨時性、成員極少的角色——這正是通常所說的角色爆炸。來源因果鏈是這樣的角色只能掛在用戶的靜態(tài)組織位置上 ↓ 約束一旦涉及 對象屬性 / 部門 / 時段 / 審批關系 只能把約束編碼進角色本身 ↓ 角色數(shù)量 ≈ 角色 × 部門 × 數(shù)據(jù)范圍 × 時段 ↓ 這些 ad hoc 角色成員極少、語義重復、無法向?qū)徲嫿忉尀槭裁从羞@個角色工業(yè)界兩個低成本補丁都在這條鏈上打洞Casbin 的RBAC with Domains給角色加一個域/租戶維度和RBAC with Conditions在規(guī)則上直接掛條件參數(shù)。來源1 來源2Q2RBAC 表達不了只看本部門數(shù)據(jù)這句話對不對過于絕對但工程語義上算半對。NIST FAQ 里專門有一節(jié)回應這類批評對方舉的例子是病歷權限建立在醫(yī)生與病人的具體關系上官方回答有兩個重點1992 年模型本身就是only if而非if的授權語義——訪問只有在滿足角色要求時才授予正是這樣才允許在訪問時追加額外約束但標準沒有規(guī)定這些額外約束該怎么實現(xiàn)它的設計是讓設計者自行添加約束來處理這些關系模型本身不會妨礙你加。來源再把第 3 節(jié)那張四組件表拿出來標準層面的約束組件只有 Static SoD 和 Dynamic SoD管的全是誰能同時/同時激活哪些角色。所以準確的表述是純 RBACCore Hierarchical SoD無法簡潔地表達行級/對象級約束硬要表達就要付出角色數(shù)量和維護成本的代價。中文社區(qū)那句RBAC 只能到菜單按鈕級數(shù)據(jù)權限必須靠 ABAC/ReBAC——這是工程經(jīng)驗的概括不是任何標準的表述寫方案時可以引但不要掛 NIST 的名義。Q3ABAC 是不是就更可控了ABAC 的代價在另一個維度決策前審計。SP 800-162 §3.1.2.3 明確要求企業(yè)需要事前審計before the fact audit能力——在請求發(fā)生之前就知道某人對哪些對象有權限、某對象被哪些人訪問。原文緊接著寫ABAC 系統(tǒng)可能不太適合高效地進行這類審計因為要算出誰能訪問這條數(shù)據(jù)需要巨大的數(shù)據(jù)檢索與計算量甚至可能要拿企業(yè)里每一個已知主體去模擬一次訪問請求。來源同文檔另一處還提醒采用分布式訪問控制架構(gòu)時審計訪問決策與事件的能力會受到影響。結(jié)論句原文這句很適合放進立項郵件ABAC 系統(tǒng)更復雜因此比更簡單的訪問控制系統(tǒng)實現(xiàn)和維護成本更高。但同一份文檔也承認ABAC 能實現(xiàn)既有的基于角色的策略并支持從角色化策略向更細粒度策略的遷移。NIST 自己在 RBAC 項目頁上對 ABAC 的概括更口語“ABAC 是一種基于規(guī)則的訪問控制方法容易搭起來但難以管理?！?. 零信任到底改變了什么、沒改變什么很多方案書把零信任當成權限模型的新一代其實不是。NIST SP 800-2072020-08Final的定義是一套不斷演進的網(wǎng)絡安全范式把防御從靜態(tài)的、基于網(wǎng)絡邊界的位置轉(zhuǎn)向聚焦用戶、資產(chǎn)和資源其規(guī)范性定義是在把網(wǎng)絡視為已被攻破的前提下最小化每次請求執(zhí)行精確、最小權限訪問決策時的不確定性。來源七條原則里與權限框架直接相關的三條② 所有通信一律受保護與網(wǎng)絡位置無關 ③ 對單個資源的訪問按每次會話授予 —— 進了 A 資源不等于能進 B 資源 ⑥ 所有認證與授權都是動態(tài)的、訪問前嚴格執(zhí)行交易過程中持續(xù)監(jiān)控可能重新認證與重新授權而且它把 PDP 又拆了一層Policy EnginePE做最終裁決“授予、拒絕或撤銷”Policy AdministratorPA執(zhí)行決策控制面與數(shù)據(jù)面分離。改變了什么維度傳統(tǒng)權限框架零信任之后信任來源網(wǎng)絡位置 / 內(nèi)網(wǎng)身份明確不因物理或網(wǎng)絡位置、不因資產(chǎn)歸屬而給隱含信任判定粒度一次登錄長期可信per-session、per-request持續(xù)重評估PEP/PDP 位置應用外圍一層攔截器往資源側(cè)搬成為獨立的、要有實時上下文和可撤銷能力的決策服務決策輸入角色角色 設備態(tài)勢 行為 環(huán)境屬性結(jié)論種類allow / denyallow / deny /revoke沒改變什么判定式本身仍是policy(attributes) → permit/deny也就是 ABAC 的語義PEP/PDP 這套詞匯也不是它發(fā)明的——SP 800-207 在給出 PDP/PEP 模型的段落有腳注 3明確寫著概念部分定義于 OASIS XACML 2.0。微分段也不等于零信任NIST 有意把它描述成 ZTA 的一種功能能力“這些定義仍在以某種方式相對邊界來定義自己比如微分段或微邊界”。還有一條常被忽略的適用邊界七條原則針對組織內(nèi)部或與伙伴組織協(xié)作完成的工作不適用于匿名公開或面向消費者的業(yè)務流程。做 C 端產(chǎn)品時把 ZT 原則原樣搬過來會寫出很重的方案。一句話總結(jié)筆者觀點零信任是部署與信任模型不是新的訪問控制模型。它給權限框架出的真正考題是——你的授權決策必須能實時拿到上下文并且能被撤銷。6. 這些模型在 Java 生態(tài)里分別落在哪一層把前面的譜系映射到實際選型上一張表基本夠用模型Java 側(cè)的典型落點客觀狀態(tài)ACL / DAC文件與數(shù)據(jù)庫對象權限、Spring Security ACL 模塊對象級 ACE 存 DB、Shiro 的 Wildcard Permissionsprinter:delete式通配串小眾但沒死ACL 模塊仍是官方文檔里的一章RBAC幾乎所有后臺的角色-菜單-按鈕三件套、Keycloak 的 Role/Group Policy、Casbin 的p, sub, obj, act RBAC matcher事實上的默認起點ABACKeycloak Authorization ServicesRole/Group/User/Client/Time/Regex/JS 策略并對接 UMA、CerbosResource/Principal/Role/Scoped Policy Conditions Derived Roles、OPA/RegoCNCFGraduated2021-01-29、AWS Cedar策略語言化、可測試化ReBACOpenFGACNCF Incubating、SpiceDBZanzibar 血統(tǒng)元組存儲數(shù)據(jù)權限行級PostgreSQL RLS9.5 引入、Oracle VPD、SQL Server RLS2016 引入應用層 MyBatis/JPA 攔截器DB 層兜底 應用層拼接并存數(shù)據(jù)權限列級PostgreSQL 列級GRANT、Oracle “Grants of Privileges on Columns”原生支持但很少被應用用上混合Casbinacl/rbac/abac/orbac/blp/biba 等一整套可運行配置Java 是官方支持語言。注2026-02 已進入 Apache 孵化器官網(wǎng) casbin.org 現(xiàn) 301 至 casbin.apache.org單庫覆蓋多模型代價是模型語法要自己維護兩個技術細節(jié)值得現(xiàn)在就記住第四篇會正面用到RLS 是會被繞過的。PostgreSQL 官方文檔寫明superuser 與帶BYPASSRLS屬性的角色總是繞過行級安全表 owner 默認也繞過可用ALTER TABLE ... FORCE ROW LEVEL SECURITY讓它受約束唯一鍵/主鍵/外鍵這類引用完整性檢查總是繞過行安全。這意味著用了 RLS 就安全是錯的——應用賬號一旦是表 owner策略形同虛設。來源Oracle VPD 的機制是改 SQL而不是過濾結(jié)果。官方定義是創(chuàng)建控制數(shù)據(jù)庫行級與列級訪問的安全策略做法是給命中的表/視圖/同義詞上的 SQL動態(tài)追加一個 WHERE 子句實現(xiàn)入口是DBMS_RLS包配合 application contexts。來源至于策略語言本身的語義有一個容易記錯但很關鍵的點Cedar 是默認拒絕且顯式 forbid 優(yōu)先。官方規(guī)則原文是至少一條匹配策略為 Allow 且恰好零條為 Deny 時整體才是 Allow并明確兩條原則——空策略集的默認結(jié)果是implicit deny任一策略給出 Deny顯式 Deny 總是覆蓋其它策略的 Allow。來源 同一頁還順手回答了這算 RBAC 還是 ABAC只有 scope 沒有附加條件的策略可以作為 RBAC 方案的一部分帶條件的策略可以作為 ABAC 方案的一部分。注Cerbos不在 CNCF 項目列表內(nèi)官方項目頁 404把它寫成CNCF 項目是常見錯誤。7. 標準之外token 這一層現(xiàn)在走到哪了第一篇不該以代碼結(jié)尾但應該給一條時間是否可信的核對結(jié)論。截至 2026-09-29事項狀態(tài)出處OAuth 2.1仍不是 RFC。當前修訂draft-ietf-oauth-v2-1-16Last updated2026-09-02IESG 狀態(tài)僅 “I-D Exists”未進入 Last Calldatatracker草案里已經(jīng)確定的口徑PKCE變?yōu)楸匦鐸mplicit、資源所有者密碼憑證等不再被規(guī)定redirect URI嚴格字符串匹配目標是合并 RFC 8252 / 9700 / 瀏覽器應用草案并移除 RFC 9700 中被認定不安全的特性草案正文OAuth 安全 BCPRFC 9700BCP 2402025-01Updates 6749/6750/6819RFC EditorDPoPsender-constrained token 主路RFC 94492023-09。?? 不是 9440——RFC 9440 是Client-Cert HTTP Header FieldInformational解決TLS 在反向代理終結(jié)、Java 應用拿不到客戶端證書RFC EditormTLS 綁定 access tokenRFC 87052020-02比 OAuth 2.1 時代早得多不是新事物RFC EditorJWT 形態(tài)的 access tokenRFC 90682021-10RFC EditorOIDC Core 1.0OpenID Foundation 側(cè)為Final含 errata set 2。?? OIDC 已是 ISO/IEC 標準一說本次未核實規(guī)范正文只引用 ISO/IEC 29115別在方案里寫規(guī)范這里存在一個對權限框架很鋒利的張力筆者分析非標準表述OAuth 2.1 把 sender-constrained token 留在了擴展DPoP / mTLS而不是核心規(guī)范里因此 Java 框架默認發(fā)出的是不綁定的 bearer token而零信任要求可撤銷、持續(xù)重評估。這兩件事不靠給框架加攔截器解決只能靠短 TTL 撤銷通道或把決策外置到 PDP。第三、第五篇會分別處理這兩條路。最后總結(jié)先選模型再選框架。Spring Security / Shiro / Sa-Token 都是執(zhí)行器它們不阻止你寫出一個 ACL 系統(tǒng)也不保證你能寫出可審計的 ABAC 系統(tǒng)。RBAC 是默認起點而不是終點。它帶來的確定性權限只經(jīng)由角色、角色只經(jīng)由指派非常有價值一旦約束涉及對象屬性和環(huán)境你要么走域/條件補丁要么接受角色爆炸。RBAC 表達不了數(shù)據(jù)權限這句話別原樣引用。標準的態(tài)度是允許你加約束但不告訴你怎么加——真正的問題不是不能表達是表達得不可審計。ABAC 換來的細粒度要用審計成本付。上線前先確認你能回答誰能看這條數(shù)據(jù)而不是只確認這次請求被拒了。ReBAC 值得學的不是名字是關系是一等公民。組織樹、文件夾、共享鏈、租戶層級本來就該是數(shù)據(jù)而不是角色。零信任沒有替代任何模型。它替代的是一次登錄長期可信并把問題從權限判斷放在哪變成決策能不能實時、能不能撤銷。對后端/架構(gòu)崗筆者個人更關注三件事權限點的唯一權威存儲在哪里、需求變更時改動面能不能被枚舉、以及審計能不能在事故前而不是事故后回答誰有權。下一篇測評篇會把鏡頭拉回到三個 Java 框架本身過濾器鏈、Subject、StpUtil三種架構(gòu)到底在哪些地方不可互換。事實說明文中所有標準編號、發(fā)布日期、版本狀態(tài)與引文均在 2026-09-29 逐條核對一手來源Biba 年份1975/1977與 ABAC四類屬性措辭存在來源分歧已在正文標注DAC 的提出年份、TCSEC 確切編號、OIDC 的 ISO/IEC 狀態(tài)未取到一手依據(jù)故正文未作斷言。帶筆者歸納/筆者觀點標記的段落為分析而非標準表述。參考資料 致謝[1] NIST SP 800-162《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》[2] NIST SP 800-162 發(fā)布頁2014-01, Final[3] NIST RBAC 項目頁標準沿革與文獻清單[4] NIST RBAC FAQ四組件、RBAC0-3、約束與批評回應[5] NIST CSRC 術語表DAC MAC[6] NIST SP 800-207《Zero Trust Architecture》PDF2020-08[7] USENIX ATC 19Zanzibar — Google’s Consistent, Global Authorization System[8] OASIS XACML 3.0 Core Specification2013-01-22[9] Bell-LaPadula 原始報告重刊Journal of Computer Security, DOI 10.3233/JCS-1996-42-308 IEEE Computer 29(2):38-47 RBAC ModelsDOI 10.1109/2.485845[10] OpenJDK JEP 411棄用 Security Manager JEP 486永久禁用 Security Manager[11] Jakarta AuthorizationJACC規(guī)范頁[12] Spring Security 參考文檔ACL 模塊 過濾器架構(gòu)[13] Apache ShiroPermissions 與 News3.0.x 發(fā)版動態(tài)[14] Casbin 支持模型清單 RBAC with Domains RBAC with Conditions BLP Biba PBAC OrBAC[15] OpenFGAAuthorization Concepts Configuration Language Conceptsstore/tuple/model/Condition[16] CNCF 項目頁OpenFGAIncubating, 2025-10-28 OPAGraduated, 2021-01-29[17] Authzed SpiceDB與 Zanzibar 的對照 Caveats[18] AWS Cedar 策略語言文檔 Cedar Policy Syntaximplicit deny 與 forbid 優(yōu)先[19] Cerbos 文檔首頁[20] OPA 文檔首頁 Data Filtering with OPA[21] PostgreSQL 文檔Row Security Policies CREATE POLICY GRANT列級權限[22] Oracle Database 19c 安全指南Virtual Private Database[23] Microsoft SQL ServerRow-Level Security[24] IETF datatrackerOAuth 2.1 草案狀態(tài) draft-ietf-oauth-v2-1-16 正文[25] RFC 9700OAuth 安全 BCP RFC 9449DPoP RFC 9440Client-Cert 頭 RFC 8705mTLS 與證書綁定 token RFC 9068JWT 形態(tài) access token[26] OpenID Connect Core 1.0Final, errata set 2