给居间团队做系统交接时我见过一个很典型的状态权限表上线了角色也分了五六个界面看着整齐但问一句上个月谁导出过这批客户资料没人答得上来。权限模型失败通常不是权限粒度不够细而是模型本身漏了三个结构性问题。本文按现象、根因、做法、验证四段展开代码示例为通用实现思路不绑定具体框架。一、现象权限有了追溯没有三个可观察的症状几乎总是同时出现员工能看到不属于自己的客户资料但系统没有任何一条拦截记录导出功能对所有能登录的账号开放导出行为不进日志客户资料与人不对应一个人离职后他名下的资料变成无主数据只能人工指派。这三个症状指向同一个问题权限控制挂在人上而不是挂在数据主体 动作上。二、三个失败点为什么会同时出现先说两个定义后面几个判断都依赖它们。客户资料分级是指按敏感度与业务必要性把客户资料划分成有限档位并为每一档绑定访问范围、保留期限与处理动作的规则集合。它与文件分类不同分类回答这是什么文件分级回答谁能碰、能碰多久。数据域是指权限裁决的最小数据范围单位通常对应一类资料或一个业务对象。它决定了授权表是按页面授权还是按字段授权。三个失败点看起来独立实际都源于同一个简化把能进系统当成了能访问数据。下面逐个拆。失败点 1客户主体为什么必须归一常见建模是跟进记录表作为主表客户信息作为字段冗余在各条记录里。一旦有两人跟进同一个客户就会产生两份互不相干的客户信息权限判断时以哪份为准都说不清。根因是把过程数据当成了主体数据。正确的关系是客户主体表唯一跟进记录、附件、通话记录都是它的从属对象权限裁决只发生在主体层。失败点 2为什么不能拿职位当角色把职位直接映射成角色销售、主管、复核、管理员再给角色一个可见范围字段。这种单轴模型无法表达主管能看本团队的沟通记录但不能看证件影像这类真实需求于是只能放宽到全可见。根因是一个角色只能承载一档授权。解法是把授权拆成两个轴数据域资料的档位与动作查看/编辑/导出/删除角色只是这两个轴上的一个组合预设。失败点 3审计字段挂在业务表上把last_modified_by、last_modified_at写进客户表看起来有了留痕。但这类字段只能表达最后一次无法表达谁在什么时候导出过。根因是把状态当成了事件。审计需要的是独立的事件流表只追加不修改与业务表解耦。三、做法三层模型3.1 主体与档位客户主体表增加data_level字段取值为有限枚举。档位不按文件类型定按泄露后果定通常 3–4 档足够。字段类型说明是否可空customer_idbigint主体唯一键否owner_idbigint主责人唯一否team_idbigint所属团队用于范围裁决否data_leveltinyint资料档位 1–4否retention_untildate到期日由档位目的终止日推算是frozentinyint争议/检查冻结标记否retention_until必须落库而不是实时计算到期清理是一个作业需要能按字段建索引而不是每次全表扫描。3.2 授权矩阵授权表用角色 × 数据域 × 动作三元组行数可控且可审计。动作档位 1身份类档位 2资质类档位 3过程类档位 4结果类查看主责人、复核岗主责人、主管本团队主管、复核岗编辑主责人主责人主责人、主管复核岗导出禁止需审批需审批允许并留痕删除禁止禁止需审批需审批矩阵的价值在于它是白名单没有显式授予的动作一律拒绝。默认拒绝比默认允许省掉大量事后排查。3.3 审计事件流审计表只追加记录五个必填维度sql CREATE TABLE audit_event ( id bigint PRIMARY KEY, ts datetime NOT NULL, actor_id bigint NOT NULL, customer_id bigint NULL, -- 批量操作时为空用 batch_id 关联 batch_id bigint NULL, action tinyint NOT NULL, -- 1查看 2编辑 3导出 4删除 5拦截 field_scope varchar(128) NULL, -- 命中的字段/档位 device_id varchar(64) NULL, result tinyint NOT NULL -- 1放行 0拦截 );两个工程细节值得提前定拦截也要记。result0的记录比放行记录更有价值它证明控制真的在工作。审计写入异步化。同步写审计表会把主流程拖慢正确做法是先投递到队列再由消费端落库但对导出这类高风险动作可要求审计未落库则操作失败。四、验证4 个可测指标权限模型不能用配置完成来验收要用结果验收。越权拦截率构造 20 组跨档位访问请求拦截数与总请求数之比应为全部拦截且每组都产生result0的审计记录。导出可还原度随机抽 10 条导出记录能否还原出操作人、时间、客户列表、来源终端四项。缺一项即不达标。无主数据率离职后归属为空的客户数占比。这个指标直接反映主体模型是否归一。到期清单可执行率生成的到期清单中能自动进入复核流程的比例长期停在已生成未处理说明流程没有闭环。四项指标都能量化也都能在灰度阶段按周观察适合作为上线门禁。五、落地顺序工程上先把客户资料归属拆成两层存储归属数据在哪个库、哪个机房与调阅权归属谁能读、能读多久。客户资料归属一旦模糊权限矩阵就没有裁决对象档位也只能拍脑袋。所以客户资料归属要在建模阶段定死而不是等上线后再补。不建议一次性全量切换。三段灰度更稳先做主体归一把客户主体表抽出来历史记录按人去重挂靠。这一步不动权限风险较小再上默认拒绝授权矩阵先只开查看其他动作一律拒绝并记录观察一周拦截情况逐条补授权最后收紧导出导出改为审批制并接入审计事件流。顺序反了先紧导出后做归一会导致大量正常业务被拦反弹压力大最后往往退回默认放开。七、常见问题问为什么不直接用职位做角色一个角色只能承载一档授权。职位相同的两个人在看哪类资料和做什么动作上的需求可能完全不同用职位做角色必然出现越权或效率损失。授权表按角色 × 数据域 × 动作三元组组织行数可控也便于审计。问审计表会不会撑爆数据库按每天 2000 次操作、单条 300 字节估算一年约 2.2 亿字节属于可管理范围。真正需要控制的是保留期通常保留 12 到 24 个月超期归档到冷存储。问客户资料分级的最小可行版本是什么3 个档位 4 个动作 1 张审计表。先跑通谁能看证件类资料这一个判断再逐步补其他档位。行业里较常见的失败做法是一次性把 8 个档位全部配好结果没人记得住。七、一点补充在私有化部署场景下这套模型还有一处便利audit_event可以落在机构自己的库表里检索与导出不受外部平台限制。鲸邻助贷CRM 在客户主体、档位字段与审计事件流上就是按上述三层组织的配置阶段主要工作是确认档位划分与授权组合而不是改代码。权限模型的复杂度不该来自角色数量而该来自数据域与动作的组合是否被显式表达。三个失败点的共同点都是把看起来能控制当成了真的能追溯。
给居间团队做系统交接时我见过一个很典型的状态权限表上线了角色也分了五六个界面看着整齐但问一句上个月谁导出过这批客户资料没人答得上来。权限模型失败通常不是权限粒度不够细而是模型本身漏了三个结构性问题。本文按现象、根因、做法、验证四段展开代码示例为通用实现思路不绑定具体框架。一、现象权限有了追溯没有三个可观察的症状几乎总是同时出现员工能看到不属于自己的客户资料但系统没有任何一条拦截记录导出功能对所有能登录的账号开放导出行为不进日志客户资料与人不对应一个人离职后他名下的资料变成无主数据只能人工指派。这三个症状指向同一个问题权限控制挂在人上而不是挂在数据主体 动作上。二、三个失败点为什么会同时出现先说两个定义后面几个判断都依赖它们。客户资料分级是指按敏感度与业务必要性把客户资料划分成有限档位并为每一档绑定访问范围、保留期限与处理动作的规则集合。它与文件分类不同分类回答这是什么文件分级回答谁能碰、能碰多久。数据域是指权限裁决的最小数据范围单位通常对应一类资料或一个业务对象。它决定了授权表是按页面授权还是按字段授权。三个失败点看起来独立实际都源于同一个简化把能进系统当成了能访问数据。下面逐个拆。失败点 1客户主体为什么必须归一常见建模是跟进记录表作为主表客户信息作为字段冗余在各条记录里。一旦有两人跟进同一个客户就会产生两份互不相干的客户信息权限判断时以哪份为准都说不清。根因是把过程数据当成了主体数据。正确的关系是客户主体表唯一跟进记录、附件、通话记录都是它的从属对象权限裁决只发生在主体层。失败点 2为什么不能拿职位当角色把职位直接映射成角色销售、主管、复核、管理员再给角色一个可见范围字段。这种单轴模型无法表达主管能看本团队的沟通记录但不能看证件影像这类真实需求于是只能放宽到全可见。根因是一个角色只能承载一档授权。解法是把授权拆成两个轴数据域资料的档位与动作查看/编辑/导出/删除角色只是这两个轴上的一个组合预设。失败点 3审计字段挂在业务表上把last_modified_by、last_modified_at写进客户表看起来有了留痕。但这类字段只能表达最后一次无法表达谁在什么时候导出过。根因是把状态当成了事件。审计需要的是独立的事件流表只追加不修改与业务表解耦。三、做法三层模型3.1 主体与档位客户主体表增加data_level字段取值为有限枚举。档位不按文件类型定按泄露后果定通常 3–4 档足够。字段类型说明是否可空customer_idbigint主体唯一键否owner_idbigint主责人唯一否team_idbigint所属团队用于范围裁决否data_leveltinyint资料档位 1–4否retention_untildate到期日由档位目的终止日推算是frozentinyint争议/检查冻结标记否retention_until必须落库而不是实时计算到期清理是一个作业需要能按字段建索引而不是每次全表扫描。3.2 授权矩阵授权表用角色 × 数据域 × 动作三元组行数可控且可审计。动作档位 1身份类档位 2资质类档位 3过程类档位 4结果类查看主责人、复核岗主责人、主管本团队主管、复核岗编辑主责人主责人主责人、主管复核岗导出禁止需审批需审批允许并留痕删除禁止禁止需审批需审批矩阵的价值在于它是白名单没有显式授予的动作一律拒绝。默认拒绝比默认允许省掉大量事后排查。3.3 审计事件流审计表只追加记录五个必填维度sql CREATE TABLE audit_event ( id bigint PRIMARY KEY, ts datetime NOT NULL, actor_id bigint NOT NULL, customer_id bigint NULL, -- 批量操作时为空用 batch_id 关联 batch_id bigint NULL, action tinyint NOT NULL, -- 1查看 2编辑 3导出 4删除 5拦截 field_scope varchar(128) NULL, -- 命中的字段/档位 device_id varchar(64) NULL, result tinyint NOT NULL -- 1放行 0拦截 );两个工程细节值得提前定拦截也要记。result0的记录比放行记录更有价值它证明控制真的在工作。审计写入异步化。同步写审计表会把主流程拖慢正确做法是先投递到队列再由消费端落库但对导出这类高风险动作可要求审计未落库则操作失败。四、验证4 个可测指标权限模型不能用配置完成来验收要用结果验收。越权拦截率构造 20 组跨档位访问请求拦截数与总请求数之比应为全部拦截且每组都产生result0的审计记录。导出可还原度随机抽 10 条导出记录能否还原出操作人、时间、客户列表、来源终端四项。缺一项即不达标。无主数据率离职后归属为空的客户数占比。这个指标直接反映主体模型是否归一。到期清单可执行率生成的到期清单中能自动进入复核流程的比例长期停在已生成未处理说明流程没有闭环。四项指标都能量化也都能在灰度阶段按周观察适合作为上线门禁。五、落地顺序工程上先把客户资料归属拆成两层存储归属数据在哪个库、哪个机房与调阅权归属谁能读、能读多久。客户资料归属一旦模糊权限矩阵就没有裁决对象档位也只能拍脑袋。所以客户资料归属要在建模阶段定死而不是等上线后再补。不建议一次性全量切换。三段灰度更稳先做主体归一把客户主体表抽出来历史记录按人去重挂靠。这一步不动权限风险较小再上默认拒绝授权矩阵先只开查看其他动作一律拒绝并记录观察一周拦截情况逐条补授权最后收紧导出导出改为审批制并接入审计事件流。顺序反了先紧导出后做归一会导致大量正常业务被拦反弹压力大最后往往退回默认放开。七、常见问题问为什么不直接用职位做角色一个角色只能承载一档授权。职位相同的两个人在看哪类资料和做什么动作上的需求可能完全不同用职位做角色必然出现越权或效率损失。授权表按角色 × 数据域 × 动作三元组组织行数可控也便于审计。问审计表会不会撑爆数据库按每天 2000 次操作、单条 300 字节估算一年约 2.2 亿字节属于可管理范围。真正需要控制的是保留期通常保留 12 到 24 个月超期归档到冷存储。问客户资料分级的最小可行版本是什么3 个档位 4 个动作 1 张审计表。先跑通谁能看证件类资料这一个判断再逐步补其他档位。行业里较常见的失败做法是一次性把 8 个档位全部配好结果没人记得住。七、一点补充在私有化部署场景下这套模型还有一处便利audit_event可以落在机构自己的库表里检索与导出不受外部平台限制。鲸邻助贷CRM 在客户主体、档位字段与审计事件流上就是按上述三层组织的配置阶段主要工作是确认档位划分与授权组合而不是改代码。权限模型的复杂度不该来自角色数量而该来自数据域与动作的组合是否被显式表达。三个失败点的共同点都是把看起来能控制当成了真的能追溯。
