行級安全

在實踐中

這個概念比任何 AI 平臺都老，值得先按它本來的樣子講一遍。PostgreSQL 從 9.5 起就帶著它：CREATE POLICY tenant_isolation ON accounts FOR SELECT USING (tenant_id = current_setting('app.current_tenant_id')) 把一個條件掛在表上，此後每一次 SELECT——來自 ORM、來自報表工具、來自某人凌晨兩點開的一個 psql 會話——都帶著它。Salesforce 用共享規則和歸屬層級達到同一個結果。兩者買到的是同一個性質，也正是 RLS 值得費這個勁的原因：限制隨資料一起走，於是新加的端點、新加的匯出路徑、新來的呼叫方會自動繼承它，不需要誰記得再補一個 WHERE。寫在呼叫方里的訪問控制是一條約定；寫在表上的訪問控制才是一條邊界。

ObjectStack 把同一個構造表達成可編寫的後設資料。一個權限集帶著 rowLevelSecurity 陣列，每一條指明物件與操作，然後宣告謂詞：讀側（SELECT、UPDATE、DELETE）用 using，寫側（INSERT、UPDATE）用 check，寫法是受約束的 CEL 表示式，例如 owner_id == current_user.id 或 assigned_to_id in current_user.team_member_ids。引擎把每條謂詞下降成一個 ObjectQL 過濾條件並推進查詢裡，於是那些行根本不會進入程序記憶體——當下一跳是 AI 模型的上下文視窗時，這一點比平時更要緊，因為「取回之後再過濾掉」的行早已被讀過了。適用的策略之間取並集，任一條命中即放行；引用的上下文值解析為 null 或空陣列時，那條策略退出而不是放寬；而編譯器無法下降的謂詞根本不產生過濾條件，此時讀路徑會替換成一個拒絕哨兵，該物件返回零行。失敗方向永遠是關閉，不是敞開。

最後這種情形正是安全審閱者該盯住的，因為它從後設資料上看不出來：一條讀起來像「按範圍授權」、行為上卻是「一律拒絕」的規則，而編寫時點沒有任何東西指向那一行。ObjectStack 的答案是一道編譯期可執行性關卡——validateRlsPredicateEnforceability 在構建時遍歷每一條宣告的 using 與 check，把任何永遠不會生效的謂詞當作錯誤拒絕掉。這道關卡值得信任的關鍵在於：它不去建模執行時的行為、也不去做模式匹配，而是拿同一份輸入去呼叫執行時自己的判定過程 isSupportedRlsExpression——編譯器判斷一條被丟棄的策略究竟是編寫錯誤還是有意跳過時，問的正是同一個函式。於是「被 linter 拒絕」和「被丟棄、無強制」是同一個布林值，二者不可能漂移開。這就是該向任何平臺索要的那件東西。不是問「你們支援行級安全嗎」——人人都說支援。要問的是：你們的構建能不能拒絕一條會悄無聲息什麼都不做的安全規則？