權限管理怎麼設計？角色權限 RBAC、權限表範本與操作紀錄，系統上線前要想清楚的事

權限管理就是把四樣東西對起來：誰（帳號）、用什麼身分（角色）、能動哪些功能、看得到哪些資料。這四樣在系統上線前寫清楚，後面才不會出現「新人一進來就看得到全公司薪資」「離職三個月的業務還登得進後台」「主管要看分店報表卻被擋在門外」這類事。

我們在客製系統的需求訪談裡，最常被老闆一句帶過的就是權限：「大家都可以看，老闆可以改就好。」等系統跑了半年，人變多、分店變多、外包廠商也要進來，這句話就撐不住了。這篇把我們規劃權限時實際用的做法整理出來：常見的權限模型怎麼選、一張可以直接拿去填的角色權限表、資料範圍怎麼切、操作紀錄要留什麼，最後附上交給外包前要寫進需求書的權限清單。

如果你要找的是整個後台要有哪些模組、報表和驗收怎麼做，可以先看 後台管理系統怎麼做；這篇只專心講權限這一塊，寫得比那篇細。

權限管理是什麼？四種常見權限模型一次看懂

先講結論：20 人以下、單一據點的公司，角色制就夠；有分店、有部門要互相看不到資料，就要在角色上再加一層資料範圍；欄位級權限只留給薪資、成本、個資這幾個欄位。下表是四種常見做法，以及各自適合的公司規模。

RBAC 是 Role-Based Access Control 的縮寫，美國國家標準暨技術研究院（NIST）有一個 角色制存取控制的專案頁，把這個模型的定義與標準整理得很完整，想看原始定義可以去翻。對老闆來說，記住一句就好：權限掛在角色上，不要直接掛在人身上。掛在人身上的權限，人一換職務就沒人記得要收回。

這件事為什麼要認真處理？網站與應用程式的資安清單 OWASP Top 10 在 2025 年版裡，把「存取控制失效」（Broken Access Control）排在第一名，而且受測的應用程式 100% 都被找到某種形式的存取控制缺陷。換句話說，權限沒做好在業界是常態，問題只在於你什麼時候發現。

角色權限矩陣範本：角色 × 功能 × 五個動作

權限表最實用的格式，是一張「角色 × 功能」的矩陣，每一格填五個動作：查看、新增、修改、刪除、核准。下面是一家有業務、會計、倉管的中小企業常見的版本，你可以直接拿去改成自己公司的。

填這張表有三個小規則，照著做可以少吵很多架：

• 刪除權限給得越少越好。多數單據用「作廢」代替刪除，留下作廢的人和原因，帳才對得起來。
• 核准跟新增分開給。自己開的單自己核准，等於沒有核准。這也是 電子簽核系統 最基本的設計。
• 「老闆全部」那一格要有備援。權限設定只有老闆一個人能改，老闆請假時新人就開不了帳號，最後大家只好共用帳號。

角色不用多。我們的經驗是，一般中小企業 5 到 8 個角色就夠用；超過 15 個角色，通常代表有人把「例外」做成了新角色，這時該回頭整理的是流程。

角色一多，系統要面對的就是「同一份資料，不同的人看到不同的樣子」。這件事我們做過規模比較大的版本：高雄市幼兒園招生系統 有家長、園所、教育局三端，家長只看得到自己孩子的報名，園所只管自己園的名冊與抽籤，教育局看得到全市登記狀況。抽籤這種牽涉入學權益的環節，我們設計成全程留痕、事後可以重演驗證。如果你的系統也有好幾種身分要分開看，我們可以先幫你看權限怎麼切比較順，或直接 加 LINE 跟我們聊。公部門多角色系統還要準備哪些稽核文件，可以看 政府標案系統開發跟企業案差在哪；招生系統本身的規劃細節則在 招生系統怎麼規劃。

資料範圍怎麼切：本人、部門、分店、全公司

角色決定「能做什麼」，資料範圍決定「能對哪些資料做」。同樣是「查看訂單」，業務只看自己的、主管看部門的、老闆看全公司的，這就是資料範圍。很多系統上線後報表吵架，原因都出在這一層沒寫清楚。

最容易漏掉的是表格最後一列。給外部廠商開帳號時，很多公司直接借一個內部角色給他用，結果廠商看得到所有客戶。外部對象一律要有自己的角色和範圍，而且帳號要有到期日。

如果你的系統要服務好幾家公司（例如做成 SaaS 賣給同業），範圍就再往上一層，叫做「租戶隔離」，A 公司永遠不能看到 B 公司的資料。那是另一套架構決定，細節可以看 多租戶架構怎麼選。

權限開太大、離職沒收：上線後最常出事的五個時間點

權限出事很少發生在設計當天，多半發生在「人變了，權限沒跟著變」的那一刻。下表是我們整理出的五個時間點，每一個都該在系統裡有對應的動作，不要只靠 IT 記得。

離職那一列最常出問題。去年酷澎個資外洩事件，起因就跟離職員工的存取權限有關，我們另外寫過一篇 離職員工權限回收 SOP，可以搭配這張表一起看。

這裡講一個比較有稜角的看法：我們認為中小企業的權限問題，九成出在「共用帳號」，跟權限設計本身關係不大。只要一個帳號有兩個人在用，前面所有的角色、範圍、操作紀錄都會失準，因為你永遠不知道是誰做的。所以我們做系統時，寧可多開帳號、多花一點授權費，也不建議客戶共用帳號。如果是 SaaS 按人頭收費，這筆錢省不得。

操作紀錄與稽核：權限管理出事時唯一能查的東西

權限設得再好，也一定會有人做錯事；操作紀錄是事後唯一能還原「誰、什麼時候、改了什麼」的東西。台灣的 個人資料保護法施行細則第 12 條，把「資料安全管理及人員管理」「資料安全稽核機制」「使用紀錄、軌跡資料及證據保存」都列在安全維護措施裡，系統只要存了客戶或員工的個資，這一塊就躲不掉。

操作紀錄有兩個要求：一是一般使用者不能改、也不能刪，管理者也只能看；二是保存期間要先講好，常見做法是線上可查一年、之後轉存。保存多久沒有標準答案，要看你的產業規範與合約，但一定要寫在需求書裡，不然廠商會用最省事的方式做，或是根本不做。

如果你正打算讓 AI 工具讀公司資料，權限問題會再多一層：AI 能讀到的，就是它可以回答給任何人的。這部分我們另外整理在 AI 導入前的資料權限盤點。

SaaS 內建權限還是客製化權限管理？看這五件事

如果你的權限需求只到「角色制」，現成 SaaS 的內建權限通常就夠；需要依分店、依客戶、依案件切資料範圍，或要讓外部的人登入，客製化才划得來。下表是兩邊的實際差異。

最後一列的成本要算長一點，三年下來的差距常常超出預期，算法可以參考 客製化系統與 SaaS 三年總成本拆解。

跨系統共用帳號這件事，我們自己就踩過。恆遠的自有產品越做越多，每個產品都要各寫一次註冊、登入、訂閱和權限驗證，使用者也得在每個產品各開一個帳號。後來我們把這一層抽出來，做成 恆遠會員中樞系統：所有自有產品共用同一套登入（Email 與 Google 帳號），中樞只管使用者是誰、訂閱什麼方案、權限到什麼時候，業務資料留在各產品自己的資料庫。新產品要上線，接上中樞就有完整的帳號與權限。如果你公司也有好幾套系統要共用帳號，規劃方式可以看 會員整合系統怎麼規劃。

交給外包前，權限管理要寫進需求書的十件事

權限寫進需求書，廠商才會照著報價、照著做、照著驗收。沒寫的部分，多半會被做成「一個管理員什麼都能做」的最簡版本。下面十件事，建議逐條寫進你的 系統需求書：

• 角色清單：每個角色的名稱、對應的職稱、大概有幾個人。
• 角色權限矩陣：用前面那張表的格式，每一格寫清楚五個動作。
• 資料範圍規則：每個角色看的是本人、部門、分店，還是全公司。
• 敏感欄位：哪些欄位要另外控管（薪資、成本、身分證字號、病歷）。
• 核准流程：哪些單據要核准、幾層、金額多少以上要多一層。
• 代理人機制：請假時怎麼代理、代理期間誰負責。
• 帳號生命週期：到職、調職、離職、外部合作結束時系統要做什麼。
• 操作紀錄：要記哪些事件、保存多久、誰可以查。
• 登入安全：密碼規則、登入失敗幾次鎖定、要不要兩步驟驗證。
• 權限管理畫面：誰可以新增角色、調整權限，改了以後要不要通知。

驗收時，請廠商用每一個角色實際登入一次，照矩陣逐格點過，特別是「應該被擋下來」的那幾格。只測「做得到」不測「做不到」，是權限驗收最常見的漏洞，完整的驗收節奏可以看 客製化系統交付驗收 SOP。整個專案從需求到上線的流程與費用，則在 客製化系統開發完整指南。

看到這裡，如果你手上已經有一張畫到一半的權限表，或是公司現在就有共用帳號、離職沒停的困擾，我們很樂意 聽你聊聊現在的情況。把你的組織圖和想管的單據丟過來，哪些用現成工具的權限就夠、哪些值得客製，我們會直接告訴你。習慣用 LINE 的話，也可以 直接加我們 LINE。