数据权限（Data Permissions）

什么是数据权限

数据权限（Data Permissions）主要解决：“这个用户可以访问哪些数据。”

例如，两名后台用户都拥有 Customer View 权限，但 User A 可以查看全部客户，User B 只能查看 Japan Entity 的客户，User C 只能查看自己负责的客户。

这些用户拥有相同的功能权限，但实际能够访问的数据范围不同，这就是数据权限。

01　数据权限与功能权限的区别

功能权限决定“可以做什么”，例如查看客户、查看订单、编辑产品、发布通知或查看报表。

数据权限决定“可以对哪些数据执行这些操作”。例如拥有 Customer View，同时数据范围为 Japan Entity，则只能查看 Japan Entity 的客户。

因此，一个完整的后台访问能力通常由功能权限 + 操作权限 + 数据权限共同决定。

02　全部数据

对于集团管理员或高级管理人员，可以配置 All Data / All Organizations，允许用户访问授权模块中的全部数据。

例如 Group Administrator 可以查看 Japan Entity、Hong Kong Entity、Singapore Entity 对应的客户、产品、交易及其他业务数据。

这种权限范围较大，通常只建议授予高级管理员或集团级岗位。

03　当前组织数据

最常见的数据权限是 Current Organization，用户只能访问自己所属 Organization 的数据。

例如后台用户属于 Japan Entity，则可以查看 Japan Entity 客户、产品、订单、持仓、通知和报表，而无法访问 Hong Kong Entity 或其他组织的数据。

04　指定组织

除了当前组织，也可以单独指定允许访问的 Organization。

例如某区域负责人可以访问 Japan Entity 和 Hong Kong Entity，但不能访问 Singapore Entity。

这样可以建立更加灵活的跨组织数据访问范围。

05　团队数据

机构内部还可以按照 Team 控制数据范围。

例如 Institutional Team 只能查看机构客户，Retail Team 只能查看零售客户，VIP Service Team 只能查看分配给 VIP 团队的客户。

这样即使多个团队属于同一个 Organization，也可以进一步进行数据隔离。

06　本人负责的数据

部分岗位可以配置为 Assigned to Me，即只允许查看分配给当前后台用户的数据。

例如客户经理 A 只能查看自己负责的客户，客户经理 B 只能查看分配给自己的客户。

这适合 Relationship Manager、Account Manager、Customer Service、Sales、Institutional Coverage 等需要按负责人划分客户的数据场景。

07　指定客户数据

管理员也可以根据业务需要，允许后台用户访问特定客户或客户集合。

例如某客服人员只负责 Client A、Client B、Client C，则可以仅授予这些客户的数据访问权限。

这样可以实现更加精确的客户级数据控制。

08　Desk 数据权限

对于交易管理场景，可以按照 Desk 设置数据权限。

例如 US Equity Desk 只能查看美股订单、美股持仓、美股交易信号及相关客户数据；FX Desk 只能查看外汇订单、外汇持仓和 FX 交易信号。

这样不同交易团队可以在同一个 Finger Manager 中独立管理各自业务。

09　市场数据权限

数据权限还可以按照市场范围进行设置，例如 US Stocks、Japan Stocks、Hong Kong Stocks、Forex、Crypto 和 Commodities。

例如 Japan Market Operations 只拥有 Japan Market 相关数据访问权限。即使其拥有订单查看权限，也不能查看其他市场订单。

10　产品数据权限

对于更精细的控制，也可以按产品或产品组限制数据范围。

例如某后台用户只能查看 AAPL、TSLA、NVDA，或者只查看 US Equity Products 对应的交易及客户数据。

这种方式适合需要对特定产品线进行独立管理的机构。

11　客户数据权限

客户管理模块中的数据权限可以控制用户能够查看哪些客户。

例如 All Customers 查看全部客户，Organization Customers 只查看所属组织客户，Team Customers 只查看所属团队客户，Assigned Customers 只查看本人负责客户，Selected Customers 只查看指定客户。

不同岗位可以采用不同的数据范围。

12　交易数据权限

交易管理模块可以按照组织、Desk、市场、客户或产品进行数据限制。

例如某用户拥有 Order View，但数据权限为 US Equity Desk，那么该用户只能看到 US Equity Desk 对应的订单，无法查看 FX Desk 或其他 Desk 的交易数据。

同样的规则可以应用于持仓、历史订单、实时交易信号、成交记录和风险数据。

13　通知数据权限

内容与通知模块也可以配置数据范围。

例如 Japan Operations 只能查看和管理 Japan Entity 创建的公告、Banner、Popup、Push Notification 和 App 内通知；Hong Kong Operations 则只能管理 Hong Kong Entity 的内容。

这样可以避免不同机构运营团队之间相互修改通知。

14　报表数据权限

报表与分析模块通常涉及大量汇总数据，因此也需要数据权限控制。

例如某用户可以查看 Japan Entity Report，但不能查看 Group Consolidated Report；或者某 Desk Manager 只能查看自己 Desk 的交易统计。

报表权限可以与原始数据权限保持一致，避免通过报表绕过数据访问限制。

15　日志数据权限

操作日志和系统日志也可以按照数据范围进行管理。

例如 Organization Admin 只能查看本组织后台用户产生的操作日志，Group Admin 可以查看多个组织的日志。

部分高敏感安全日志可以进一步限制为只有 Super Admin 才能访问。

16　数据权限继承

对于存在组织层级的机构，可以根据配置使用数据权限继承。

例如 Group → Japan Entity → Japan Retail Team。如果 Group Administrator 拥有集团级数据权限，则可以访问下级组织的数据，但 Japan Retail Team 的普通员工只能访问本团队范围内的数据。

通过继承机制，可以满足大型集团的层级管理需求。

17　多条件组合

数据权限可以根据多个条件组合。

例如某后台用户的数据范围可以设置为 Organization = Japan Entity、Market = US Stocks、Desk = Retail Desk。

那么该用户只能访问 Japan Entity 中属于 Retail Desk 的美股相关数据。通过多个维度组合，可以建立更精细的数据访问规则。

18　数据权限与角色

数据权限可以直接包含在角色配置中。

例如 Japan Operations 角色拥有 Product View、Notification Manage、Customer View 等功能权限，同时数据权限为 Organization = Japan Entity。

当用户获得这个角色后，即自动拥有对应的数据范围。

19　不同角色可以拥有不同数据范围

即使属于同一个 Organization，不同角色也可以访问不同范围的数据。

例如 Japan Admin 查看 Japan Entity 全部数据，Japan Operations 查看产品与运营相关数据，Japan Customer Service 查看客户相关数据，Japan Trading Operations 查看交易相关数据。

通过角色和数据权限组合，可以避免不必要的数据暴露。

20　用户级数据权限

除了角色默认的数据权限外，也可以根据需要为单个用户设置特殊的数据范围。

例如某个 Compliance 用户正常只查看 Japan Entity，但由于临时负责 Hong Kong Entity 的审核，可以临时增加 Hong Kong Entity 数据访问范围，任务结束后再移除该权限。

21　数据隔离

数据权限是 Finger Manager 数据隔离机制的重要组成部分。

例如 Organization A 和 Organization B 同时使用 Finger Manager，Organization A 的普通后台用户不会看到 Organization B 的客户、交易、产品、通知、报表和后台用户。

只有拥有明确跨组织数据权限的用户才可以访问。

22　导出数据权限

查看数据和导出数据可以分别控制。

例如某用户可以查看客户列表，但不能导出客户数据；或者可以查看订单，但不能下载完整订单文件。

对于涉及大量客户信息或交易数据的导出操作，建议使用更严格的权限控制。

23　敏感字段权限

除了记录级数据范围，还可以进一步控制敏感字段。

例如某些角色可以查看客户基本资料，但不能查看完整手机号、完整邮箱、身份证件号码、银行账户信息或其他敏感字段。

系统可以根据权限对部分字段隐藏、脱敏或只显示部分内容，从而进一步降低敏感数据暴露风险。

24　数据权限变更

当员工岗位、团队或负责范围发生变化时，可以调整其数据权限。

例如客户经理原本负责 Team A，调岗后负责 Team B，管理员可以将数据范围从 Team A 修改为 Team B，无需重新创建后台账户。

25　数据权限检查

当后台用户访问数据时，Finger Manager 会进行权限判断。

流程通常为：用户登录 → 读取 Organization → 读取角色 → 读取功能权限 → 读取数据权限 → 判断请求的数据是否属于授权范围 → 允许访问或拒绝访问。

因此，即使用户知道某条数据的 ID，如果没有对应数据权限，也不能通过正常后台访问该数据。

26　操作日志

数据权限相关变更可以记录在操作日志中。

例如修改组织数据范围、增加跨组织权限、修改团队范围、调整客户访问范围、修改 Desk 权限、修改市场权限和修改敏感字段访问权限。

系统可以记录操作人、操作时间、被修改用户、修改前范围和修改后范围，方便机构进行权限审计。

数据权限管理逻辑

数据权限管理逻辑可以理解为：后台用户 → 拥有角色 → 角色包含功能权限 → 系统确认允许进入对应模块 → 读取数据权限 → 判断 Organization → 判断 Team / Desk / Market / Customer 等范围 → 只返回授权范围内的数据 → 用户查看或执行操作。

典型应用场景