企业做数据安全时经常把“数据权限”理解成一件很简单的事给数据库建几个账号不同部门分配不同账号。但业务真正开始用数据以后很快就会发现这远远不够。同样是一张销售订单表普通销售只能看自己的订单区域经理需要看整个区域财务可以看成本和毛利销售却未必需要看到成本管理层可以看利润率但部分业务岗位只能看到收入和销量。所以数据权限真正需要解决的不是“这个人能不能进入数据库”而是谁在什么业务场景下能够看到哪些数据、哪些字段、哪些指标又能够操作到什么程度。在正式展开之前我整理了一套《数据仓库建设解决方案》里面涉及数据治理、数据安全、权限管理、数据标准等企业数据建设中的常见问题。如果正在梳理数据权限体系可以结合文章一起看资料包https://s.fanruan.com/7igmg复制到浏览器一、为什么数据权限一定要分层设计假设企业有一张订单表里面包含订单编号、客户、销售人员、区域、产品、销售额、成本、毛利、客户手机号。销售、财务、区域经理和公司管理层都会使用这张表但显然不能看到完全一样的数据。这时候就会发现权限其实存在多个层次。库权限决定能不能进入某个数据域表权限决定能不能使用某类业务数据行权限决定能够看到哪些记录列权限决定能够看到哪些字段指标权限决定能够使用哪些经营口径。它们不是五套互相独立的权限而是一层层向下收缩数据可见范围。例如一个华东区销售经理先允许进入销售数据域再允许访问订单表进入订单表以后只能看到华东区域的数据其中成本字段不能查看但可以使用销售额、订单量和回款率等指标。最终真正生效的权限其实是库权限 ∩ 表权限 ∩ 行权限 ∩ 列权限 ∩ 指标权限。这也是权限设计中一个非常重要的原则上层负责划边界下层负责做精细控制。如果所有问题都在数据库层解决就会出现大量数据库账号、视图甚至重复表如果什么都放到报表层解决又容易出现底层数据实际上已经暴露只是页面暂时没有展示。所以权限不能只从“最终谁能看报表”开始设计还要沿着源系统 → 数据集成 → 数仓 → 数据集 → 指标 → 应用一路往前检查。数据团队使用FineDataLink 5.0建数据集成链路时权限通常就可以从数据连接这一层开始拆。哪些人只能使用某个数据连接做开发哪些人可以修改连接配置哪些人还能继续把权限授权给下级人员可以分别管理。这样做的意义不是多加一道权限而是先控制谁有资格把哪些源系统的数据带进数据平台。否则下游权限做得再细上游开发账号却能够随意连接核心数据库整个安全链路依然是不完整的。二、库权限和表权限解决的是“业务边界”库权限和表权限属于整个权限体系最外层。库权限先隔离数据域企业的数据通常天然存在业务边界。例如人力数据财务数据销售数据供应链数据生产数据。普通销售人员没有必要进入人力数据库供应链人员也不应该默认拥有财务明细数据。所以库权限首先解决的是某类人有没有资格进入某个数据域。这里最重要的不是把数据库切得越碎越好而是让数据库或Schema的划分尽量和业务边界保持一致。否则如果一个库里既有公开经营数据又有工资、身份证、银行卡等高度敏感数据后续所有权限都会非常难配置。表权限进一步控制业务对象进入某个数据域以后还需要继续区分具体业务对象。比如财务域可能同时存在总账、费用、应收、应付、预算、资金等数据。财务BP可能需要预算和费用数据却未必需要看到完整资金账户明细。所以表权限控制的其实是一个岗位能够参与哪些业务分析。这里很容易出现一个错误做法为了做权限隔离不断复制数据表。销售一套、经理一套、总部一套。短期确实解决了访问问题但长期会形成大量结构相同、口径不同的数据副本。真正合理的做法应该是数据尽量统一存储权限动态决定谁能够访问。三、行权限真正复杂的是“数据范围”企业权限体系里最容易变复杂的往往是行权限。因为现实中的权限很少只是“有”和“没有”更多是同一张表不同的人看到不同记录。例如一张全国订单表华东负责人只能看到华东上海负责人只能看到上海销售张三只能看到自己负责的客户。如果企业有3000名销售显然不可能维护3000张订单表。所以真正可扩展的方式是建立用户身份 → 业务属性 → 数据范围之间的映射。例如张三 → 上海 → 上海订单李四 → 江苏 → 江苏订单王经理 → 华东 → 华东订单用户登录以后系统先识别身份再根据区域、部门、客户归属、项目归属等属性计算最终的数据范围。这里有一个非常关键的区别权限规则不应该绑定某个具体的人而应该尽可能绑定组织和业务关系。因为人会变化。张三今天负责上海下个月调到杭州。如果权限写成“张三可以看上海数据”就必须手工修改。如果权限写成“用户可以查看其负责区域的数据”组织关系发生变化以后数据范围就可以同步变化。而在数据仓库建设阶段还要再往前想一步这些权限关系本身也是数据。组织架构、人员岗位、区域归属、客户负责人、项目负责人都需要持续从OA、CRM、HR等系统同步到数仓。FineDataLink 5.0在搭这类链路时通常会把订单数据和组织、人员、客户归属等权限基础数据一起同步。对于某些明确只需要部分记录的下游场景也可以在数据处理过程中先按条件过滤再写入目标表。FineDataLink 的数据转换中提供数据过滤能力。这样行权限就不再只是报表里临时写一个WHERE region华东而是形成组织关系持续更新 → 权限关系同步进入数仓 → 下游根据登录身份动态计算数据范围的一整条链路。四、列权限核心不是隐藏而是数据分级如果说行权限解决“哪些记录能看”列权限解决的就是同一条记录里哪些信息能够被看到。例如一张客户订单表里可能同时存在客户名称、手机号、地址、销售额、成本、毛利、身份证号等字段。这些字段的敏感程度显然不同。所以列权限不应该从“这个字段要不要隐藏”开始而应该先做数据分类分级。例如可以分成L1公开数据产品公开信息、公开统计数据。L2内部数据普通经营数据、内部业务数据。L3敏感数据客户联系方式、员工信息、交易明细。L4核心敏感数据身份证号、银行卡号、薪资、核心成本、重大经营数据。之后再建立岗位等级 × 数据等级 × 使用目的之间的授权规则。这样系统管理的就不是“张三能不能看到手机号字段”而是“销售岗位是否能够访问L3级客户联系方式”两种模式的维护成本完全不同。列权限还有一个很容易被忽略的风险页面不显示不等于真正没有权限。如果前端页面隐藏了手机号但下游数据表里仍然完整保存手机号用户又能通过SQL、接口或者其他应用拿到原始数据那么风险依然存在。所以有些数据根本没必要进入某个下游系统时最好在数据集成阶段就处理。例如给经营分析库同步客户数据时如果下游根本不需要身份证字段可以在数据转换过程中直接删除如果手机号仍然要用于关联或业务识别但不应该保存明文则可以通过FineDataLink 5.0的全局清洗规则进行脱敏或加密后再输出。官方文档也将“敏感字段脱敏、加密后输出到下游数据表”列为全局清洗规则的应用场景。这实际上把列权限又往前推进了一层不是等数据已经到下游以后再想办法藏起来而是判断这类数据有没有必要被带过去。五、指标权限权限为什么还要进入业务语义层很多企业做到行、列权限以后就觉得数据权限已经完整。但到了BI和经营分析阶段还会出现另一类问题指标本身也可能是敏感信息。例如销售额可能大部分销售人员都能看毛利额只开放给区域负责人净利润率只有部分管理岗位能够访问战略预算、目标达成率等指标甚至只向管理层开放。指标权限比字段权限更复杂因为指标通常不是一个字段。例如毛利率销售额销售成本÷销售额它同时依赖销售额、成本、计算公式、统计范围和时间口径。所以即使把“毛利率”指标隐藏如果用户仍然能够取得销售额和成本字段完全可以自己重新计算。因此真正的指标权限至少要同时考虑指标是否可见、是否可使用、是否允许下钻、组成指标的底层数据是否能够取得。这就是权限穿透。指标层不能和底层数据层各做一套互不关联的权限。再往数据生产侧看同样存在一个容易忽视的问题不是所有数据开发人员都应该拥有所有指标底表的生产权限。例如薪酬、人效、利润、客户贡献度等指标底层可能涉及人力、财务、CRM多个敏感数据源。搭建这些指标链路时可以先在FineDataLink 5.0中把数据连接和数据开发资源的权限分开让负责普通销售主题的开发人员只使用其职责范围内的数据连接而核心指标链路由对应人员维护。FineDataLink5.0权限体系本身区分数据连接的使用、管理和授权权限也支持对平台资源进行分级管理。这里控制的不是最终“谁能看到毛利率”那仍然属于指标消费层权限控制的是谁能够接触生成这个指标所需要的底层数据以及谁能够修改这条数据生产链路。从这一层开始指标权限才真正形成底层数据访问 → 指标生产 → 指标发布 → 指标消费的完整链路。六、企业真正需要的是一套“动态权限模型”把库、表、行、列和指标全部理解以后还有最后一个问题如果这些权限全部靠管理员逐个人配置企业人数一多系统很快就会失控。成熟的数据权限体系通常不会简单建立用户 → 权限而是采用用户 → 角色/属性 → 权限规则 → 数据资源其中最常见的是两类机制。RBAC角色决定“能做什么”RBAC就是基于角色的访问控制。例如定义销售、销售经理、财务BP、财务经理、区域负责人、数据管理员。销售角色拥有销售分析权限财务角色拥有成本分析权限管理员拥有数据维护权限。角色解决的是相对稳定的功能边界。ABAC属性决定“能看什么”但只有角色仍然不够。华东销售经理和华南销售经理角色一样但看到的数据不能一样。于是还要继续判断部门、地区、项目、客户归属、岗位等级、数据等级等属性。这就是基于属性的访问控制。最终形成角色决定能不能进入这个分析场景属性决定进入以后能看到多少数据。例如销售经理 → 可以访问销售经营分析区域华东 → 只能查看华东数据岗位等级M3 → 可以进一步查看毛利数据等级L4 → 不开放核心敏感字段。这时权限才从一张静态配置表变成一套能够随着人员、组织和业务关系变化而变化的规则体系。最后还要补上一个非常重要的闭环申请—审批—授权—使用—审计—复核—回收。因为权限最大的风险很多时候并不是“第一次给错”而是员工已经调岗半年旧权限还在项目已经结束临时权限没有回收某个账号拥有十年前累计下来的大量历史权限。所以权限治理真正成熟的标志不是系统里有多少种权限颗粒度而是企业能够回答谁拥有什么权限、为什么拥有、什么时候获得、用过哪些数据、什么时候应该失效。结语数据权限不是一道简单的“账号管理题”。它实际上是一套从IT资源一直延伸到业务语义的数据控制体系。库权限负责划数据域表权限划业务对象行权限控制数据范围列权限保护敏感信息指标权限进一步控制经营语义。但真正决定这套体系能不能长期运行的是背后的几条原则数据统一管理权限动态过滤角色决定能力属性决定范围敏感程度跟着数据分级走组织变化带动权限变化关键授权和访问必须能够审计。最终企业真正要回答的并不是“这个人能不能看这张表”而是“这个人在当前岗位、当前业务范围和当前使用目的下究竟应该访问哪些数据又应该被限制到什么程度”把这个问题回答清楚数据权限才真正从“账号配置”进入了数据治理。