系統帳號角色與權限設計指南：最小權限、分店資料範圍與離職帳號處理

系統剛上線時，公司可能只有幾個人在用後台，大家共用一組管理員帳號最方便。過了一兩年，人員增加、開了分店、找了工讀生與委外夥伴，問題就浮現了：新人一進來就看得到所有客戶資料、某筆訂單被改了卻不知道是誰改的、離職同仁的帳號還能登入。這些都是系統帳號角色與權限設計沒有在一開始規劃好的結果。

權限設計聽起來像是工程師的事，但真正要回答的問題都是管理問題：誰該看到什麼、誰能改什麼、誰能批准什麼、出事時怎麼追查。工程團隊能做出任何規則，但規則本身要由業主決定。

這篇說明角色與個別授權的差別、最小權限原則、分店與部門的資料範圍怎麼設計、操作紀錄該記哪些內容，以及人員異動與離職時帳號該怎麼處理，最後提供一張可以直接拿來盤點的權限矩陣範本。

為什麼不能所有人都用管理員帳號

共用最高權限帳號會帶來幾個實際風險：

• 無法追溯：資料被改錯或刪除時，查不出是誰在什麼時候做的。
• 誤操作影響大：新手可能因為看得到「刪除」按鈕就按了下去。
• 資料外洩範圍大：任何一個人的電腦或密碼出問題，整個系統的資料都暴露。
• 離職風險：共用密碼不可能只對離職的人失效，只能全體換密碼，而這件事常常被拖延。
• 內部糾紛難釐清：涉及金額或庫存的爭議，沒有紀錄就只能各說各話。

所以權限設計的第一原則是：每個人一個帳號，不共用。其他設計都建立在這個基礎上。整體資安的基本觀念可參考企業網站資安基礎。

角色與個別授權：兩種給權限的方式

給權限有兩種基本做法。

以角色授權：先定義「店長」「會計」「客服」「倉管」等角色，每個角色有一組權限，再把人指派到角色上。新人到職時只要選角色，不必逐項勾選；調整某個職務的權限時，改角色一次，所有該角色的人就同步更新。

個別授權：直接針對每個人勾選他能使用的功能。彈性最大，但人一多就難以管理，久了沒有人說得清楚某個人為什麼有某項權限。

實務上以角色為主、個別授權為例外。大部分人照角色走，少數特殊情況才額外加權限，而且額外授權要有原因與期限。如果發現某個角色經常需要被個別加權限，代表角色定義本身該調整了。

設計角色時的原則

• 角色名稱用職務語言，不要用「權限組 A」這種沒人看得懂的名稱。
• 角色數量夠用就好，太多角色會讓指派時不知道該選哪一個。
• 一個人可以同時擁有多個角色，例如兼任店長與採購，系統要支援角色疊加。
• 角色定義要有文件，寫清楚適用對象與包含的權限。

最小權限原則：給剛好夠用的權限

最小權限是指每個人只拿到完成工作所需的權限，不多給。這不是不信任員工，而是降低誤操作與外洩的影響範圍。

把權限切細一點，通常要區分這幾種動作：

• 檢視：能看到資料。
• 新增與編輯：能建立或修改資料。
• 刪除：能刪除資料，通常應比編輯更嚴格，許多系統會改用「作廢」保留紀錄。
• 核准：能批准退款、折扣、出貨、調整庫存等需要把關的動作。
• 匯出：能把資料下載成檔案。匯出是外洩的高風險點，常被忽略。
• 系統設定：能修改權限、價格規則、系統參數，應只限極少數人。

特別要注意職責分離：同一個人不應該同時能申請和核准同一件事，例如自己開退款單又自己核准。這類規則要在需求階段就列出來，系統才能在流程上擋下。

分店與部門的資料範圍

權限不只是「能用哪些功能」，還有「能看到哪些資料」。兩個店長都有「檢視訂單」的功能，但台北店長應該只看到台北店的訂單，這就是資料範圍。

常見的資料範圍層級：

• 個人：只看自己負責的資料，例如業務只看自己的客戶。
• 部門或分店：看所屬單位的資料。
• 區域：區經理看轄下多家分店。
• 全公司：總部管理者看全部。

設計時要考慮的情況：

• 一人多單位：支援多家分店的人員，要能指派多個資料範圍。
• 跨單位協作：A 店的客人到 B 店消費，B 店要能查到該會員的必要資訊，但不一定要看到他在 A 店的完整紀錄。
• 組織調整：分店合併、區域重劃時，資料範圍要能批次調整，而不是逐一改帳號。
• 報表的範圍：報表與匯出也要套用同一套資料範圍，常見漏洞是畫面上看不到，但報表或匯出檔裡全都有。

資料範圍牽涉到資料表的設計，上線後再補往往要大幅修改，因此建議在內部後台系統規劃初期就確定組織層級。會員資料涉及個人資料，範圍設計也要配合會員與 CRM 系統的規劃一起考慮。

權限矩陣範本：業主明天就能填

在和開發團隊討論前，可以先填一張權限矩陣。橫列是角色，直欄是功能，交叉格填上權限與資料範圍。以下是骨架：

功能	店員	店長	會計	總部管理者
訂單	檢視、新增（本店）	檢視、編輯、作廢（本店）	檢視（全部）	全部權限（全部）
退款	申請（本店）	核准（本店）	檢視（全部）	核准（全部）
會員資料	檢視（本店）	檢視、編輯（本店）	不可見	檢視、匯出（全部）
庫存調整	申請（本店）	核准（本店）	檢視（全部）	核准（全部）
報表	不可見	檢視（本店）	檢視、匯出（全部）	檢視、匯出（全部）
帳號與權限設定	不可見	不可見	不可見	全部權限

填寫時的步驟：

1. 列出所有職務，合併實際工作相同的職務。
2. 列出系統所有功能模組，包含匯出與設定。
3. 每一格先問「這個職務不做這件事，工作會卡住嗎？」答案是否就留空。
4. 標出需要核准的動作，確認申請與核准不在同一個角色。
5. 請各單位主管確認自己單位的那一欄。

這張表填完，就是權限需求文件的核心，後續撰寫需求可參考軟體需求怎麼寫。

操作紀錄：出事時能回答「誰、何時、做了什麼」

操作紀錄（稽核紀錄）是權限設計的另一半。權限再嚴謹，也一定會有人在權限範圍內做錯事，這時候靠的是紀錄。

建議記錄的內容：

• 登入與登出：時間、帳號、登入來源，以及登入失敗的嘗試。
• 重要資料的變更：誰在何時把哪個欄位從什麼改成什麼，特別是價格、金流、庫存、會員資料。
• 刪除與作廢：被刪的是哪筆資料、原因。
• 匯出：誰匯出了什麼範圍的資料。
• 權限變更：誰把誰的權限改成什麼，這類紀錄最容易被忽略也最重要。

紀錄本身也要保護：一般人員不應該能修改或刪除操作紀錄，保存期間要依業務需要與相關法規決定。紀錄要能依帳號、時間、資料查詢，否則存了也找不到。

人員異動與離職：帳號生命週期

帳號問題最常發生在人員異動時。到職時開帳號通常沒人忘記，但調職與離職時的調整很容易被拖延。

帳號處理流程

• 到職：由主管提出申請，依角色開立帳號，首次登入強制更改密碼。
• 調職：移除舊職務角色、加上新職務角色，不要只加不減，否則權限會隨年資一路累積。
• 留職停薪或長假：暫時停用，返回時再啟用。
• 離職：最後工作日當天停用，不要等到離職手續全部跑完。
• 定期檢視：建議固定時間由各單位主管確認轄下帳號與權限是否仍正確。

離職帳號建議停用而非刪除。刪除會讓過去的操作紀錄失去對應的人，也可能連帶影響該帳號建立的資料。停用後保留一段時間，再依公司政策處理。

如果公司使用 Google、Microsoft 等企業帳號，可以考慮讓系統用單一登入串接，離職時停用公司帳號就同步失去系統存取權，減少遺漏，做法可參考社群登入與 SSO 指南。

上線前後的檢查重點

權限做完不代表做對。驗收時要用不同角色的帳號實際登入測試，而不是只用管理員帳號看功能有沒有出現：

• 以每個角色登入，確認看得到該看的、看不到不該看的。
• 直接輸入其他分店資料的網址，確認系統會擋下，而不是只把按鈕藏起來。
• 測試報表與匯出是否套用了資料範圍。
• 確認停用的帳號無法再登入，原本的登入狀態也會失效。
• 確認權限變更有被記錄。

「只把按鈕藏起來」是最常見的漏洞：畫面上看不到，但知道網址或直接呼叫介面仍能存取。權限檢查一定要在伺服器端執行。驗收方式可參考軟體驗收怎麼做。

權限設計做得早，成本最低；系統用了幾年再補，常常要動到資料表與每一支功能。如果你的後台正準備開發，或現有系統還在共用帳號、分店資料互相看得到，可以和 NETVANA 聊聊你的組織與權限需求，我們會先和你一起把權限矩陣與資料範圍釐清，再規劃系統的實作方式。軟體服務一律採詢問報價制，服務內容請參考軟體服務介紹。

延伸閱讀：後台系統整體怎麼規劃，先看內部後台系統開發指南；會員資料的範圍與保護，讀會員與 CRM 系統開發指南；想用公司帳號統一登入，看社群登入與 SSO 指南；帳號與資料的基本防護，參考企業網站資安基礎；不同角色怎麼驗收，看軟體驗收怎麼做；要把權限規則寫成需求，看軟體需求怎麼寫；知識庫裡的文件也得決定誰能看、誰能改，可以看企業內部知識庫系統怎麼建；不同經銷商看到的價格與資料範圍各不相同，可以看經銷商下單平台怎麼規劃。