權限（Permissions）

什麼是權限

權限（Permission）決定後台用戶能看什麼、能操作什麼、能管理什麼。

Finger Manager 的權限可以覆蓋多個層級，例如頁面訪問權限、功能權限、操作權限、數據權限、API 權限和管理權限。

系統會根據用戶擁有的角色及權限，決定後台最終向其開放哪些內容。

01　功能權限

功能權限決定用戶可以進入哪些 Finger Manager 模組。

例如工作台、市場與產品管理、客戶管理、交易管理、內容與通知、組織與權限、系統設定、日誌與問題排查、報表與分析。

如果用戶沒有某個模組的訪問權限，該模組可以不顯示，或者禁止用戶進入。例如客服人員可以擁有客戶管理權限，但不擁有系統設定權限，那麼該用戶無法訪問系統配置相關頁面。

02　操作權限

進入模組後，還可以進一步控制用戶能夠執行哪些操作。

常見操作權限包括 View、Create、Edit、Delete、Publish、Approve、Export、Import、Enable、Disable 和 Manage。

例如在「內容與通知」模組中，某用戶可以擁有 View、Create 和 Edit，但沒有 Publish 和 Delete。這意味著該用戶可以建立和修改通知，但不能正式發布或刪除內容。

03　查看權限（View）

查看權限是最基礎的權限類型。擁有 View 權限後，用戶可以查看對應頁面或數據。

例如 Customer View 允許查看客戶列表，Order View 允許查看訂單，Product View 允許查看產品配置。

只有查看權限而沒有編輯權限時，系統可以將相關頁面設定為唯讀狀態。

04　建立權限（Create）

Create 權限決定用戶是否可以新增數據。

例如新增產品、建立通知、建立用戶、建立角色、建立用戶組、建立組織和建立定時任務。

如果用戶只有 View 權限，則可以查看已有數據，但無法建立新的記錄。

05　編輯權限（Edit）

Edit 權限決定用戶是否可以修改已有內容。

例如修改產品資訊、修改客戶資料、編輯公告、修改 Banner、修改用戶分組和修改系統配置。

機構可以將查看和編輯權限分別授予不同崗位。

06　刪除權限（Delete）

Delete 屬於風險相對較高的權限。擁有刪除權限的用戶可以刪除系統允許刪除的數據。

例如刪除草稿、刪除用戶組、刪除未使用配置和刪除部分後台記錄。

對於訂單、交易記錄、操作日誌等需要長期保留的數據，系統可以限制永久刪除。在實際管理中，建議只向少數管理員授予 Delete 權限。

07　發布權限（Publish）

Publish 權限用於控制內容或配置是否可以正式生效。

例如發布公告、發布普通彈窗、發布跑馬燈、發布 Banner、發送 Push Notification 和發布產品配置。

例如營運人員可以負責 Create + Edit，而主管負責 Publish，這樣可以建立「製作」和「發布」分離的內部管理流程。

08　審批權限（Approve）

對於需要內部審核的業務，可以使用 Approve 權限。

例如客戶審核、KYC / KYB 審批、高風險操作審批、產品上線審批、通知發布審批和權限申請審批。

沒有 Approve 權限的用戶可以提交業務，但無法執行最終批准。

09　匯出權限（Export）

Export 權限決定用戶是否可以將系統數據匯出。

例如客戶數據、訂單數據、交易記錄、報表、日誌和統計數據。

由於匯出可能涉及大量業務或客戶資訊，建議將匯出權限與普通查看權限分開管理。例如某用戶可以在後台查看客戶資料，但不能批量匯出客戶數據。

10　數據權限（Data Permissions）

功能權限解決「可以進入哪個模組」，數據權限則解決「進入以後可以看到哪些數據」。

例如同樣擁有客戶管理權限，User A 可以查看全部客戶，User B 只能查看 Japan Entity 的客戶，User C 只能查看自己負責的客戶。

因此，數據訪問範圍可以獨立於功能權限進行配置。

11　常見數據範圍

Finger Manager 可以根據機構結構設定不同的數據訪問範圍。

例如 All Organizations 訪問全部組織的數據，Current Organization 只訪問目前所屬組織的數據，Specific Organizations 只訪問指定組織，Team 只訪問所屬團隊負責的數據，Assigned Users 只訪問分配給目前用戶的客戶或業務，Selected Markets 只訪問指定市場相關數據，Selected Desk 只訪問指定 Desk 相關數據。

透過數據權限，可以在同一個後台功能中進一步建立數據隔離。

12　權限與組織

權限可以受到 Organization 範圍限制。

例如 Japan Entity 的 Operations 用戶擁有 Product Edit，但其數據範圍為 Japan Entity，那麼該用戶只能修改 Japan Entity 的產品。即使 Hong Kong Entity 也存在產品，該用戶也無法進行操作。

因此，一個完整權限通常可以理解為：功能權限 + 操作權限 + 數據範圍。

13　權限與角色

實際使用中，通常不會逐個為每位用戶設定大量權限。

更常見的方式是先建立權限，將多個權限組合成角色，再把角色分配給用戶。

例如 Operations Role 包含 Product View、Product Edit、Banner View、Banner Edit、Notification Create 和 Notification Publish。當用戶獲得 Operations 角色後，即自動獲得這些權限。

14　直接權限

在部分特殊情況下，也可以為單個用戶授予額外權限。

例如某位 Operations 員工正常情況下沒有 Export Report 權限，但由於該員工臨時負責報表工作，可以額外授予 Report Export。

這種權限可以作為角色權限之外的補充。對於長期權限，通常仍建議透過角色統一管理。

15　權限繼承

對於存在組織層級的機構，可以根據系統配置使用權限繼承機制。

例如 Group Administrator 擁有集團級訪問權限，則可以訪問下級 Japan Entity、Hong Kong Entity 和 Singapore Entity，而子組織管理員只能管理自己所屬組織。

透過權限繼承，可以減少大型集團重複配置權限的工作量。

16　功能權限示例

17　敏感權限

部分權限涉及較高風險，應謹慎授予。

例如 Permission Manage、Organization Manage、User Delete、Customer Export、Trading Manage、API Manage、Security Settings、System Settings 和 Audit Log Export。

這些權限通常建議只授予 Super Admin、高級管理員和指定負責人，並透過操作日誌記錄相關行為。

18　權限組合

Finger Manager 可以透過權限組合建立不同級別的訪問能力。

例如唯讀用戶擁有 View，普通操作人員擁有 View + Create + Edit，營運主管擁有 View + Create + Edit + Publish，管理員擁有 View + Create + Edit + Publish + Delete + Manage。

不同模組不一定需要採用完全相同的權限組合。機構可以根據實際風險進行配置。

19　最小權限原則

建議機構按照最小權限原則（Principle of Least Privilege）配置後台權限，也就是說後台用戶只獲得完成目前崗位職責所必要的權限。

例如客服人員需要查看客戶資料，但不一定需要匯出全部客戶數據；營運人員需要發布活動內容，但不一定需要修改系統安全配置；交易營運人員需要查看訂單，但不一定需要管理後台角色。

透過最小權限原則，可以降低系統內部風險。

20　職責分離

對於重要業務，可以透過權限拆分實現職責分離。

例如營運人員負責 Create + Edit，營運主管負責 Approve，管理員負責 Publish，這樣一條重要通知需要經過不同人員處理後才能正式發布。

對於交易、客戶審核或高風險系統操作，也可以使用類似機制。

21　權限變更

管理員可以根據員工職責變化調整權限。

例如員工原本只有 Customer View，之後由於職責變化，需要增加 Customer Edit，管理員可以透過修改角色或用戶權限完成調整。

權限變更後，系統按照新的權限規則控制其後台操作。

22　權限停用

當某項權限不再需要時，可以從角色或用戶中移除。

例如員工調離崗位後，可以移除 Notification Publish，保留 Notification View。

這樣用戶仍然可以查看歷史通知，但不能繼續發布新的內容。

23　API 權限

除後台頁面權限外，Finger Manager 還可以對 API 訪問進行獨立控制。

例如 Market Data Read、Customer Read、Order Read、Order Write、Notification Send 和 Account Manage。

API 權限可以與後台操作權限分開管理。這可以避免獲得後台訪問權限的用戶自動擁有 API 操作能力。

24　權限檢查

當用戶執行後台操作時，系統會進行權限檢查。

流程通常為：用戶發起操作 → 識別目前用戶 → 讀取所屬 Organization → 讀取用戶角色 → 讀取角色權限 → 讀取數據訪問範圍 → 判斷是否允許執行 → 允許或拒絕操作。

如果沒有相應權限，系統不會執行該操作。

25　操作日誌

權限相關操作可以進入 Finger Manager 的操作日誌。

例如新增權限、修改角色權限、授予權限、移除權限、修改數據範圍和調整 API 權限。

日誌可以記錄操作用戶、操作時間、權限名稱、修改對象、修改前狀態和修改後狀態。這有助於機構追蹤權限變化並進行內部審計。

權限管理邏輯

權限管理邏輯可以理解為：定義系統權限 → 按照業務模組分類 → 設定操作級權限 → 設定數據訪問範圍 → 將權限組合到角色 → 將角色分配給後台用戶 → 用戶登入 Finger Manager → 系統讀取角色與權限 → 判斷功能訪問範圍 → 判斷數據訪問範圍 → 判斷具體操作權限 → 允許或拒絕操作。