權限模型

在實踐中

權限模型與一條權限之間的區別，就像國際象棋的規則與一步棋之間的區別。決定一套模型能否扛過安全審查的，是模型本身的三個性質，而不是任何一條規則。容器是什麼——角色、使用者組、Profile、權限集——其中是否有不止一種在幹同一件事？一個人同時持有多份授權時，它們如何疊加：只做加法、任一份命中即放行，還是存在會壓過其它規則的拒絕項，於是求值順序和優先順序決定結果？以及什麼都不匹配時的預設值是拒絕還是放行？產品會在多年裡累積出彼此重疊的容器，結果「這個人為什麼能看到這條記錄」這個問題，不模擬一遍引擎就答不出來——而這恰恰是審計員開口問的第一個問題。

ObjectStack 刻意把這個面收窄。能力容器只有一種——權限集——它按並集合並，且純粹是加法：裡面沒有任何一位是拒絕。崗位是一個扁平的分發組，負責把權限集綁到人身上；業務單元是可見性層級；完全不存在 Profile 這個概念。預設拒絕在字面意義上成立：每一個 allow 位預設為 false，所以在某條定義開口之前，一個物件是讀不到的。在這一套模型之上疊著四層強制：物件級 CRUD、欄位級讀與寫、行級謂詞（見「行級安全」），以及針對協作例外的按記錄共享——否則這類例外只能靠放寬整個角色來解決。匯出是一條獨立的軸，而不是「讀」的順帶結果，因為「在螢幕上看一條記錄」和「把整張表拉成 CSV 拖走」是兩種不同的特權——Salesforce、Dynamics、NetSuite 和 SAP 都做了這個切分，而粗粒度的模型會悄悄把它丟掉。

「只做加法、沒有拒絕」是一條實打實的約束，選它是為了可審閱性，不是為了表達力。因為授權只會做加法，「這個人為什麼能看到這個」的答案就是列出授予它的那幾個權限集——一份有限、可讀的清單；而在一個允許拒絕的模型裡，同一個問題需要在可能相隔數年、由不同人寫下的規則之間推理優先順序。同一個性質也讓 AI Agent 無需為它另發明一套東西就能被治理：Agent 以登入使用者的身份行動，按那個使用者的權限集解析，於是不存在一個需要單獨推理其權限的特權服務身份——審閱「Agent 能做什麼」與審閱「這個人能做什麼」，是同一件事。