權限設計:誰能看、誰能改、誰能刪

系統剛上線時人少,大家共用一個管理員帳號,什麼都能看、什麼都能改,方便。半年後問題來了:價格被改了不知道是誰改的;工讀生誤刪了整批商品;離職員工的手機還登著後台。權限設計就是在回答三個問題——誰能看、誰能改、誰能刪——而且最好在系統設計初期就回答,因為事後補權限,比一開始做進去貴得多。

先畫角色權限矩陣,再寫程式

權限設計的第一步不是技術,是一張表:直的列出系統裡的角色(老闆、店長、店員、會計、工讀生),橫的列出功能(查訂單、改價格、退款、匯出報表、刪除資料),格子裡填「可看 / 可改 / 不可見」。這張表叫角色權限矩陣,填的過程會逼出很多平常沒想過的決策:店員可以看到成本價嗎?店長可以退款到多少金額?會計需要改訂單,還是只需要看?

我們自己營運的進銷存 SaaS 服務加盟體系,這張表更關鍵——加盟主能看自己店的營收,不能看別店的;總部能看全體報表,但日常操作下放給門市。連鎖與加盟場景的權限,本質上是「資料範圍」加上「功能開關」兩個維度:不只是「能不能用退款功能」,還有「能對哪些店的訂單退款」。這一層想清楚,系統才撐得起組織長大。

最小權限原則:預設不給,需要再開

資安領域有個核心觀念叫最小權限原則:每個人只拿到工作所需的最小權限,多的不給。聽起來理所當然,實務上大家常反著做——「先全開,有問題再關」,因為開權限要人來要,關權限沒人記得。結果就是權限只增不減,三年後沒有人說得清楚誰能幹嘛。

務實的做法有幾條:

• 用角色管人,不要一個一個人設定。新店員來,指派「店員」角色就好;要調整店員能做什麼,改角色一次生效。逐人設定的系統,最後一定變成一團沒人敢動的義大利麵。
• 高風險操作單獨拉出來。刪除資料、批次改價、匯出全部客戶名單、退款——這些動作即使角色有權限,也值得多一道確認,甚至限定極少數人。
• 離職流程要包含帳號。人資辦離職的檢查清單裡,「停用系統帳號」要跟繳回門禁卡同一天發生。這是最便宜、也最常被忽略的資安措施。
• 定期盤點。每季花半小時看一次帳號清單:這個人還在職嗎?還需要這個權限嗎?

權限設計的重點不是防賊,是讓每個人手上的刀剛好夠切自己的菜——切傷人的機會自然就少了。

例外處理:權限太死,大家就會繞過它

權限設計有個弔詭:設計得太嚴,現場反而更不安全。店長臨時請假,退款沒人能按,於是大家開始共用店長密碼——權限系統形同虛設。所以設計時要預留合法的例外通道:代理人機制(店長休假期間授權給副手,有期限、有紀錄)、臨時提權(需要上級核可、事後留痕)。讓正路好走,大家才不會走歪路——這條原則跟我們做後台 UX 的邏輯一模一樣。

另外,權限和紀錄是一對的:光控制「誰能做」不夠,還要記下「誰做了」。改價格、刪訂單這類敏感操作,系統要留下操作人、時間與改動前後的值——這部分展開來是另一個題目,我們寫在操作紀錄與稽核那篇。權限決定門開給誰,紀錄告訴你門被誰走過;兩者都有,出事時才有得查。

如果你的系統還在「一組帳號打天下」的階段,或者權限已經亂到沒人敢整理,這其實是系統健檢裡最常見的項目之一。歡迎參考我們的客製化系統與 SaaS 服務,權限矩陣這張表,我們陪你一起畫。