設計權限系統的順序是：先盤點系統裡有哪些資料與動作、哪些職務會使用，再把權限綁在角色上，依最小權限原則只開放完成工作所需的範圍；接著訂出權限怎麼申請與核准、調職與離職時怎麼回收、多久覆核一次，並讓登入、授權失敗、權限變更與資料匯出都留下稽核紀錄。角色型權限（RBAC）是常見的起點，但只靠角色不夠：「業務只能看自己的客戶」這類依資料歸屬的限制，要另外設計資料範圍規則，而且伺服器端每一次請求都要檢查權限，不能只靠隱藏按鈕。
角色型權限（RBAC）的設計步驟
角色型權限是先定義角色，再把可執行的動作指派給角色，人員只要掛上角色就取得對應權限。後台權限表的基本格式可參考後台管理系統的權限角色規劃，這裡補充設計時的步驟：
- 盤點資料與動作：列出訂單、客戶、薪資等資料，以及查看、修改、刪除、匯出、核准等動作，標出敏感動作。
- 指定資料擁有者：每類資料由一個部門主管負責，日後由他判斷誰該有權限。
- 從職務定義角色：用「門市店長」「應收帳款會計」這類職務命名，不要用人名。
- 分層設計顆粒度：功能層決定能不能進某個畫面，資料範圍層決定看得到哪些部門、門市或自己負責的資料，欄位層決定身分證號、電話等欄位是否遮蔽。
- 控制角色數量：用基本角色加上少數附加權限組合，避免為每個例外開新角色。
Open Worldwide Application Security Project（OWASP）的授權指引提醒，角色過多會出現角色爆炸，測試與稽核都更困難，並指出應用程式開發通常應優先考慮屬性型或關係型的存取控制。可以用角色管功能，再用部門、門市、負責人等屬性管資料範圍。
最小權限與職責分離怎麼落實
美國國家標準與技術研究院（NIST）把最小權限描述為系統應將使用者的存取權限限制在完成指派工作所需的必要範圍。OWASP 的授權指引另外提醒要預設拒絕，也就是未明確授權的功能與資料一律不開放，並注意權限蔓延：人員換過幾個職務後，舊權限沒收回、新權限又加上去。
職責分離則是讓任何一位使用者都不具備足以獨自濫用系統的權限。NIST 的術語表舉例，核准薪資支付的人不應同時是準備薪資的人，並說明職責分離可以靜態落實，也就是定義不能由同一人擔任的衝突角色，或在存取當下動態控制，例如由兩人共同完成的操作。後台可以這樣設計：
- 建立廠商資料與核准付款分屬不同角色。
- 申請人不能核准自己的申請，系統直接擋下。
- 大量刪除、修改金額或匯出全部名單，需要第二人確認後才執行。
權限申請與審核流程
權限不應憑口頭要求直接開通。申請單至少包含申請人、系統、要求的角色或權限、用途說明與使用期限，送出後依序由直屬主管確認工作需要、由資料擁有者確認可以開放，再由系統管理員開通。開通的人和核准的人分開，本身就是一種職責分離。
流程中還有幾個細節要先定好：
- 臨時權限：專案或代理期間的權限一律設到期日，到期由系統自動收回，不靠人工記得。
- 緊急權限：系統故障時需要立即開通的情況，可以先開通、事後補簽核，並在紀錄中標示原因。
- 外部人員：委外廠商與顧問使用個人帳號，權限只開到合約範圍，合約結束日即為帳號到期日。
- 保存紀錄：每一筆申請、核准、開通與駁回都保留，覆核與查核時才有依據。
調職與離職的權限回收
NIST 的安全要求列出，使用者離職或調職時應通知帳號管理者，帳號不再對應到使用者時要停用。建議由人資的異動資料觸發流程，不要等各部門自己想起來：
- 離職：生效時停用所有系統帳號，停用而不刪除，保留操作紀錄以備日後查詢；同時檢查是否有以他名義申請的 API 金鑰、排程作業或共用帳號密碼，一併更換。
- 調職：先移除舊職務的角色，再依新職務申請，不要只在原有權限上加新角色，這是權限蔓延常見的來源。
- 交接：名下的資料、待簽核單據與排程報表，先移轉給接手的人再停用。
離職當天也要檢查信箱轉寄設定，避免帳號停用後仍有資料外流的管道。
定期權限覆核怎麼做
NIST 的安全要求包括定期檢視指派給角色或使用者類別的權限，確認仍有需要。以 Microsoft Entra 為例，存取權檢閱可以定期檢閱群組成員資格、企業應用程式的存取權與角色指派，並以一定頻率定期進行（官方舉例每週、每月、每季或每年），但需要 Microsoft Entra ID Governance 或 Microsoft Entra Suite 訂用帳戶，部分功能也可用其他特定的 Microsoft Entra ID 授權。客製系統沒有內建這類功能時，可以照下列流程進行：
- 匯出帳號、角色與資料範圍清單，標出上次登入時間。
- 依部門寄給主管或資料擁有者，逐筆勾選「保留」或「移除」。
- 事先規定期限內未回覆的處理方式，例如先暫停該帳號的敏感權限。
- 移除不需要的權限，並把覆核結果與執行紀錄存檔。
系統管理員、可匯出個資或修改金額的高權限角色，覆核頻率可以比一般角色更密。
稽核紀錄要記什麼、誰能看
OWASP 的紀錄指引建議記錄登入成功與失敗、授權失敗、新增或刪除使用者與變更權限等管理動作，以及資料匯入與匯出，每筆紀錄要能回答何時、何處、何人、何事。NIST 的安全要求列出的紀錄內容，包括事件類型、發生時間、發生位置、來源、結果，以及相關人員或物件的身分。密碼、存取權杖與加密金鑰不應寫進紀錄，工作階段識別值若需要追蹤，改存雜湊值。
紀錄本身也要保護。OWASP 建議內建竄改偵測、盡早把紀錄複製到唯讀的儲存位置、所有對紀錄的存取都要記錄與監控，讀取紀錄的權限要限制並定期檢視，在規定的保存期限屆滿前不得銷毀。權限紀錄若涉及個資，個人資料保護法施行細則第十二條列舉的安全維護措施，得包括資料安全稽核機制，以及使用紀錄、軌跡資料及證據保存，實際做法請以主管機關公告或專業意見為準。
上線前驗證權限設定是否正確
OWASP 的授權指引建議為授權邏輯撰寫單元與整合測試，確認存取預設會被拒絕。上線前用一張測試表，替每個角色各準備一個測試帳號，逐項驗證：
- 該看到的畫面與資料看得到，不該看到的真的看不到。
- 水平越權：把網址或請求裡的訂單編號、客戶編號改成別人的，確認系統拒絕回應。
- 垂直越權：一般帳號直接呼叫管理功能的網址或 API，確認被擋下。
- 匯出檔案與附件下載也受同樣的權限控管，不能靠猜檔名取得。
- 權限檢查失敗時安全結束，錯誤訊息不透露其他資料。
系統改版或調整角色後，都要重跑一次測試表。身分驗證與最小權限放進整體資安架構的做法，可參考零信任架構的原則。
常見問題
權限系統和帳號系統有什麼差別？
帳號系統處理身分驗證，確認登入的人是誰；權限系統處理授權，決定這個人能看什麼、做什麼。兩者設計時分開處理，日後換登入方式也不必重做權限。
小公司也需要角色型權限嗎？
需要，只是可以簡化。即使只有幾個角色，也應避免所有人共用管理員帳號，至少把可以刪除資料、修改金額與匯出名單的權限收在少數人手上。
主管可以看所有部屬的資料嗎？
依工作需要決定，不是職位越高就看越多。主管通常需要看部屬負責的業務資料，但薪資、健康等敏感欄位，應由資料擁有者另外判斷是否開放。
稽核紀錄要保存多久？
依公司內規、合約與適用法規決定，先確認是否有法定或契約要求的保存期間。保存期間內紀錄不能被一般管理員刪除或修改，到期後再依程序銷毀。
現成系統的權限不夠細，可以補強嗎？
可以先確認系統是否支援自訂角色或資料範圍設定；不支援時，可以在前面加一層自建的入口與權限檢查，透過 API 只取用必要資料，再評估是否改用客製系統。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先把現有系統的帳號、角色與可匯出資料的權限列成一張表，找出共用帳號與長期未覆核的高權限。京采的網頁設計服務可以協助釐清權限需求，開發含角色、資料範圍、申請審核與稽核紀錄的客製後台，或與既有系統串接；歡迎與我們聯繫討論。
