後台系統設計：RBAC 權限模型與稽核日誌實戰

幾乎每個產品背後都有一套後台：客服查訂單、營運上架商品、財務做退款。後台看起來不性感，但它直接碰的是最敏感的資料和最危險的操作。我做過好幾套後台，這篇講兩件最核心的事：權限怎麼設計、操作怎麼留痕。

為什麼不要用「職稱」當權限

新手最常見的寫法是：在使用者上面放一個欄位叫 role，值是 admin、staff、manager，然後程式裡到處寫 if role == admin。

這在第一個月很爽，第三個月開始崩潰：

• 老闆說「客服主管可以退款，但一般客服不行」——你多一個 role
• 又說「這個資深客服比照主管」——你開始在 if 裡塞特例
• 半年後沒人說得清楚某個 role 到底能做什麼

問題在於：你把「身分」和「能做什麼」綁死了。

RBAC：把權限拆成三層

比較能撐的作法是標準的 RBAC（Role-Based Access Control），核心是把關係拆開：

• Permission（權限）：最小的能力單位，例如 order.refund、product.edit、user.export
• Role（角色）：一組權限的集合，例如「客服主管」= order.view + order.refund
• User（使用者）：被指派一個或多個角色

程式裡判斷的永遠是「有沒有某個 permission」，而不是「是不是某個 role」。這樣：

• 新增能力 = 新增一個 permission，掛到該掛的角色上
• 老闆要調整誰能做什麼 = 改角色的權限組合，不用動程式
• 權限檢查的程式碼長期穩定，因為它只問 permission

我的習慣是把權限檢查收斂成一個地方（middleware 或 decorator），業務邏輯裡只宣告「這個 API 需要 order.refund」，不要把 if 散落各處。

別忘了「資料範圍」這一維

RBAC 解決「能不能做這個動作」，但後台還有一個常被忽略的維度：能對哪些資料做。

例如：區域經理只能看自己區域的訂單。這不是 permission 能表達的，這是 data scope。常見作法是在查詢層自動注入範圍條件（例如自動加上 region = 使用者的區域），確保就算 API 有權限，也只撈得到他該看的資料。把這層做在資料存取的共用層，而不是靠每個 API 自己記得加 where，才不會有人漏掉造成越權。

稽核日誌：誰、在什麼時候、做了什麼

後台的第二根支柱是稽核（audit log）。當有一筆退款出問題、或客戶資料外洩，你第一個要回答的問題是：誰做的、什麼時候、改了什麼。沒有稽核日誌，你只能兩手一攤。

我的稽核日誌至少記：

• 操作者是誰（user id，不是只記名字，名字會改）
• 操作時間
• 動作類型（refund、export、update 等）
• 操作對象（哪一筆訂單、哪一個使用者）
• 變更前後的值（敏感操作尤其重要）
• 來源資訊（IP、request id）

幾個實務原則：

• 稽核日誌要獨立於業務資料，最好是 append-only、不可被一般操作刪改。連工程師都不該能隨手刪
• 高風險操作（退款、改金額、匯出個資、改權限）一定要記，而且要記「變更前後」
• 不要把敏感資料（密碼、完整卡號）原文寫進日誌
• 日誌要能查：給定一筆訂單，要能拉出它所有被動過的歷史

危險操作要再加一道

有些操作一旦做錯就無法挽回（大額退款、批次刪除、改別人權限）。對這些我會再加：

• 二次確認或雙人覆核（maker-checker）
• 對「改權限」這件事本身也要稽核——提權是攻擊者最愛的一步

小結

後台系統的價值不在 UI 多漂亮，而在它安全、可控、可追溯：

• 用 RBAC 把 Permission / Role / User 拆開，程式只問 permission
• 補上 data scope，控制「能對哪些資料」操作
• 稽核日誌記錄誰、何時、對什麼、做了什麼、變更前後，且不可竄改
• 高風險操作加二次確認與覆核

我的體會是：後台是那種「做得好沒人會稱讚，做不好就上新聞」的系統。把權限和稽核這兩件事做扎實，是後端工程師的基本責任。