第 12 章 — 存取控制與身分
《LLM Primer VII:AI 安全》章節走讀的第十二篇。這一章回答組合性問題 — 誰被允許呼叫一個 LLM 整合應用的哪一項能力,以及如何在系統元件之間結構化執行。
這一章為什麼存在
傳統的存取控制紀律全部適用於 LLM 系統:認證主體、對照政策授權其請求、隔離租戶、限制每主體的消耗、暴露企業治理疊加層。機制是這個領域數十年來用的那些 — OAuth 2.0、mTLS、RBAC、ABAC、token bucket、SAML、SCIM。新的地方是:模型呼叫本身可以變成一個主體 — 一個代使用者行動的 agent,承載自己的身分與自己的權限 — 而多租戶 LLM 平台上,逐租戶的模型行為組態是一等的產品功能。
12.1 認證與授權轉移過來,再加上一些
認證驗證憑證。API 金鑰是最簡單的機制 — 一串高熵字串在佈建時交給主體、在憑證資料庫中被雜湊、在每次請求時透過 header 呈現。它們容易實作、容易使用,也容易透過日誌、CI 輸出、送 commit 的 repository 洩漏。OAuth 2.0 bearer token 以短期 token 與範圍限制改善狀況;OAuth 2.1 草稿收攏了過去十年的安全最佳實務。mTLS 為機器對機器呼叫加上雙向認證,對內部 LLM 服務特別有用。授權詢問已認證的主體被允許做什麼。RBAC — 角色、權限、指派 — 在人群分成穩定群組時有用。ABAC — 屬性型存取控制 — 評估對主體、資源與脈絡屬性的謂詞,處理 RBAC 處理不了的情況:依資源擁有者、請求的時間或位置、或系統中關係而定的權限。兩者並非互斥;生產系統常常疊起來,以 RBAC 做粗粒度存取,以 ABAC 做具體條件。第 10 章的政策引擎 — OPA、Cedar — 就是讓 ABAC 在規模化下可維護的做法。
12.2 多租戶隔離是縱深防禦問題
多租戶系統從單一部署服務多個客戶。隔離要求是:在任何故障模式下,任一租戶都無法看到其他任一租戶的資料、請求或模型互動。三種架構做法坐落在一個光譜上。資料庫層級隔離 — 每租戶一個資料庫 — 最強但作業成本最高。Schema 層級隔離 — 共享基礎設施上每租戶一個 PostgreSQL schema 或 MySQL database — 是中間地帶。列層級隔離 — 共享 schema、每列上帶租戶 ID、資料庫強制的 row-level security — 最便宜,但要求有紀律的應用程式碼。對 LLM 系統來說,隔離延伸到檢索語料(每租戶向量資料庫的 namespace)、prompt 組裝邏輯(不做跨租戶串接)、日誌儲存(不做跨租戶讀取)、以及在租戶專屬資料上微調時的模型本身。速率限制與配額加上資源消耗那條軸線。Token bucket 允許短時爆發到定義的容量;sliding window 以較高計算成本強制較均勻的速率;leaky bucket 平滑下游速率。對 LLM 系統來說,速率限制的維度會擴張:每秒請求、每分鐘 token、每天成本、每小時工具呼叫、每秒 embedding。每一維都有自己的經濟與資安理由,而企業層級常常在其中幾維上做區分。
12.3 企業治理是讓系統能被使用的疊加層
企業客戶有超越認證與速率限制的治理要求。他們得知道哪些員工在使用系統、在什麼資料上、為了什麼目的。他們需要足以做內部合規與外部稽核的稽核日誌。他們需要對哪些模型被允許、哪些工具可用、哪些內容類別被允許的控制。他們需要資料處理承諾 — 訓練使用、加密、駐留地、保存期限、刪除。已成為標準的功能反映了這些要求。透過 SAML 或 OpenID Connect 的 SSO 讓企業身分供應者成為誰能使用系統的真理來源。SCIM 佈建自動傳播使用者變更。稽核日誌匯出把 LLM 系統的遙測送進企業 SIEM。資料駐留承諾保證租戶的資料不會離開指定管轄地。客戶管理加密金鑰讓企業能獨立於供應商輪替或撤銷。私有部署選項把 LLM 服務移到企業自己的雲端帳戶。這些功能每一項都是一個治理表面,得被運行、而不只是被實作;企業治理疊加層,就是把一個多租戶 LLM 平台變成受監管產業能採用之物的關鍵。
第 12 章鋪陳出來的東西
第四部發展了 LLM 安全的系統層面:架構邊界(第 10 章)、可觀測性與事件回應(第 11 章)、身分與存取控制(第 12 章)。處理是機制優先的,給出可辯護的技術姿態。第 13 章開啟第五部,從技術核心往外移向監管周界。歐盟 AI Act 於 2026 年 8 月起對大多數高風險類別完全生效,是最有影響力的單一工具,但美國聯邦姿態(在 EO 14110 到 EO 14179 轉銜後演進中)、州級法律(科羅拉多、加州、紐約市等)、GDPR 套用到 AI,以及新加坡、日本、韓國、印度等地新出現的框架,合起來使合規表面是複數的、而非統一的。這一章檢視這些監管在實務上要求什麼、以及第 3、10、11、12 章的控制如何對映到這些要求。
下一篇 — 第 13 章:監管地景。歐盟 AI Act 的分階段適用、GDPR 對 AI 系統、可稽核性、model card,以及結構化監管架構的風險分級框架。
