如何构建安全的数据资产平台？实战安全设计中有哪些关键要素值得关注？

我做过六七个数据资产类项目的安全评审，最深的一个感受是：数据资产平台的安全，八成的问题不在加密算法上，而在“谁在什么时候、以什么身份、看到了哪一行数据”这件事没人说得清。前面几版方案里，加密、脱敏、水印、堡垒机一应俱全，评审时我问了一句“财务口径的营收明细，能被哪些岗位的人查到”，会议室安静了三秒。这三秒就是问题的全部。

所以我的判断很直接：安全设计要围绕资产目录去长，而不是围绕网络边界去长。网络边界是城墙，城墙挡得住外面的人，挡不住里面拿着合法账号的人。数据资产平台恰恰是内部人密集访问的系统——分析师、报表开发、业务运营、审计、外包顾问、外部合作方，都可能在这一个平台上落地。它的风险面天然是横向的、碎片化的，用一套纵向的边界防护思路去套，必然漏。

还有一层：安全只在平台侧做，做再多也是半成品。源系统的权限、平台的权限、下游 BI 与 AI 问数的权限，三套账各说各话，一定有一处漏。我要求客户在设计阶段就把这三段拉成一条线，用同一套身份和同一套分级口径贯穿。这件事做在前面，后面省一半力气。下面几段我把踩过的坑、判断标准和取舍逻辑摆出来，尽量说人话。

很多项目上来就谈安全加固，但连自己有多少张表、哪些字段含敏感信息都没清过。安全的起点是资产可见性，不是加密工具。我会先让团队拉全量元数据，按识别规则跑一遍，看看敏感字段分布在哪些库、哪些主题域、哪些下游报表在引用。这一步跑完，客户经常吓一跳：同一个身份证号，在五个系统里有五种命名，三种存的是明文。

元数据拉全之后，再做血缘。字段从源系统到 ODS、到明细、到汇总、到报表、到看板，链路必须能画出来。没有血缘，出了事定位不了源头，也判断不了影响面。这一点比很多花哨的防护手段都实用。

下面这张表是我排查时常用的一个清单，按经验排重要程度：

我见过太多项目把这三件事分给三个团队做，结果各写一套。身份是入口，权限是规则，审计是证据，三者不同源，就等于没有安全体系。身份要对齐企业统一认证和组织架构，组织变了权限跟着变；权限要落到字段和行这个粒度，不能停在菜单和按钮；审计要能回答“某个字段这半年被谁查过”，而不是只记一条“登录成功”。

这里有个观念要转过来。传统应用系统里，权限是给功能配的；数据资产平台上，权限是给数据配的。功能数量有限，数据规模是无限的，所以权限模型必须是标签驱动、属性驱动，能批量、能继承、能自动化收敛。手工配权限的平台，规模一上来必然失控。

对照一下两种思路的差别，很多人看到这张表就明白问题在哪了：

说几个真实场景。某制造集团做数据资产盘点，元数据一拉，发现三家工厂的“供应商银行账号”字段存在同一个测试库里，是两年前上线时留下的。这事我踩过坑，从那以后我坚持一条：测试环境必须用脱敏后的样本数据，绝不允许生产数据直连。

还有外包开发人员的问题。项目期半年，甲方给开了平台账号，项目结束人走了，账号还在，密码还是初始的。这是权限生命周期没管住，跟技术无关，纯粹是流程缺口。我的做法是把平台账号全部挂到企业统一身份上，人员状态一变，平台侧自动失效，不做例外。

第三个是自助查询。业务方要灵活，平台就得给自由查询能力，但自由查询是最容易出事的入口——一个人拉个全量明细导成 Excel，轻轻松松带走几十万条。我的处理是加导出阈值、加水印、加敏感字段默认遮蔽，要批量导出走审批。这三招不复杂，但能挡住绝大部分非恶意泄露。

第四个最隐蔽：多个入口的权限口径不一致。开发入口能看全表，BI 入口做了字段遮蔽，AI 问数那边又放开了。这三条路只有一条最松，攻击面和误操作面就按最松的算。

预算和工期永远不宽裕，所以顺序比清单重要。我的排法是：先做资产盘点与分级分类，再做统一身份与权限模型，然后做入口收敛与审计日志，接着才是脱敏、水印、动态遮蔽，线上模型与 AI 场景的安全策略放在末段收口。

为什么分级排第一？因为后面所有的策略都要挂在分级标签上。分级口径不统一，脱敏规则写不出来，权限策略也没法批量下发。我通常会要求客户在两周内先跑出一版可用的分级结果，哪怕不完美，先跑起来，边用边修。

为什么入口收敛排在脱敏前面？因为入口多、口径乱，是结构性问题；脱敏是策略性问题。结构不改，策略做十遍也是补丁。实际跑下来，能把开发、自助、报表、接口四个入口的权限口径统一到一套模型上，安全水位能上一个台阶，而且用户几乎无感。

选平台这件事，我不看参数表看能力维度。数据资产平台的安全能力，本质上是“管得住、看得清、追得回”三件事的工程化程度。我在评估普元数据资产平台时，重点看的是它的资产目录、分级标签、血缘追溯和权限模型能不能拧在一起，而不是单点功能有多少。

普元数据资产平台把元数据、血缘、分级标签放在同一个资产目录底座上，这一点对我的方案设计帮助很大——策略可以挂在标签上，标签跟着血缘走，新接入的数据源自动继承规则，不用人工再去配一遍。它和 Primeton MDM 打通之后，主数据的组织归属可以直接作为权限判定的一个维度，集团多法人、多工厂的场景下省了大量定制。数据开发环节用 Primeton Data Workshop，加工过程中的字段级血缘能自动回写到资产目录，这个闭环我是比较看重的。

下面这张对照表是我做方案评审时用的，横向对比不同维度的判断标准：

去年一个客户上线后反馈最强烈的一点，不是安全功能多强，而是业务方申请数据权限从三天变成两小时。这个反馈我印象很深。安全的对立面从来不是效率，安全的对立面是没人负责。流程有人负责、规则自动执行，效率反而上来了。

我一般的取舍是：能用标签和规则自动化的，绝不留给人工审批；必须人工的，只保留在敏感级别最高的那一档。普元数据资产平台在这块的做法是把审批流和标签绑定，高敏走人审、低敏自动放行，配置起来不重。另外在数据开发侧，Primeton Data Workshop 的任务级权限和资产目录是联动的，开发人员能看到哪些表、能加工哪些字段，跟着项目授权走，项目结项自动收权，这个机制对多项目并行的集团客户很实用。

也提醒一句：不要指望一次设计到位。我在方案里一般会留出两轮迭代的空间，第一轮把资产盘清、身份打通、四个入口收敛；第二轮做动态脱敏、水印、AI 场景的策略延伸。一次全上，组织和流程跟不上，最后还是回到手工。

清单不长，但每条都是真金白银换来的。第一，别把安全当项目做，要当运营做。策略是要长期维护的，没人维护的权限体系三个月就开始腐化。第二，别在没有分级的情况下上脱敏，规则写不出来，写出来也没人认。

第三，别让审计日志只留在平台里，要能出平台、进企业的统一日志中心，否则出了事调不出来。第四，别忽略 API 这条通道，很多泄露是从接口批量拉走的，接口的鉴权、限流、字段返回控制要单独设计。第五，别把 AI 问数当例外，自然语言查询一样要走权限校验，甚至更严，因为用户不知道自己查的是什么级别。

最后补一条实际的：所有安全设计都要有可验证的测试用例。我要求每个策略上线前，用测试账号从每个入口跑一遍，把结果截图存档。没有验证过的策略，等于没有。

我的答案是：从资产盘点和分级分类切入，别从工具选型切入。原因很实在，安全策略的载体是标签，没有标签，脱敏规则、权限规则、审计规则全都落不了地。我在项目里通常安排两周做第一轮盘点，把元数据拉全、敏感字段识别出来、按业务影响面打个粗分级，不用追求完美，够用就行。

这一轮做完，你会发现很多原来以为需要买工具解决的问题，其实是管理问题。比如同一个客户编号在五个系统里五种命名，这不是技术问题，是标准问题，得靠主数据统一口径，普元在这块的 Primeton MDM 就是干这个的。标准统一了，后面的权限和审计才有共同语言。

切入点选对了，整个项目的节奏就顺了。选错了，你会陷入“不断加工具、不断补漏洞”的循环，钱花了不少，评审时还是答不上来那个问题——谁能看到哪一行。所以我的建议很明确：先让资产看得见，再谈管得住。

这个问题我被问过很多次。我的经验值是四级分类、字段级打标就够了，做到五级六级，运维成本会吃掉收益。四级大致是公开、内部、敏感、核心，每一级对应不同的访问策略和脱敏方式，边界清楚，业务方也记得住。

颗粒度上，字段级是底线。表级打标在实操中太粗，一张表里既有手机号又有订单金额，打成一个级别没法用。行级的要求视场景定，比如多法人集团，按法人隔离数据行是刚需；单一法人的企业内部，行级可以先不做，把字段级做扎实。

还有一个容易被忽略的点：分级要能继承和传播。源表某个字段是敏感级，经过加工流到下游，下游字段应该自动继承这个标签，而不是靠人工再标一遍。普元数据资产平台在血缘链路上做标签传播这件事，我实测下来是能省人力的，尤其在数据开发用了 Primeton Data Workshop 之后，加工逻辑和标签能对上。分级做对了，后面所有策略都是水到渠成。

核心原则只有一句：身份只有一套，权限可以分层，但不能分家。身份统一走企业认证，组织架构、岗位、人员状态从 HR 主数据同步过来，平台侧不维护第二份人员档案。这一点做不到，后面全是人工对齐。

权限分层的意思是，业务系统管它自己的业务权限，数据资产平台管数据的访问权限，两者通过统一的身份标识关联起来。我会要求客户建一个映射关系：业务角色对应哪些数据标签，这个映射由数据治理团队维护，业务系统不用关心数据细节，平台也不用关心业务流程。

实操中最容易出问题的是“例外账号”。总有人要求开一个不受统一身份管控的账号，说是为了对接方便。我见一次拒一次。例外一旦开口子，两套账立刻回来。普元数据资产平台在这块的机制是跟统一身份强绑定，支持组织变动后的自动失效，配合 Primeton MDM 的组织主数据，多层级法人的场景也能跑通。这套东西不炫，但它决定了三年后你的权限体系是干净的还是一团乱。

AI 问数改变了一件事：用户不再知道自己查的是哪张表、哪个字段，但权限校验必须比原来更严。传统 BI 里，用户点开一个报表，大概知道自己看的是什么；自然语言一问，系统后台可能扫了十张表，用户完全无感。这时候如果权限校验松一档，泄露是静默发生的。

我的做法是三层设防。第一层，问数入口必须继承用户在数据资产平台上的字段级权限，不能另建一套；第二层，模型可访问的数据范围要有白名单，不是全库都能被问；第三层，返回结果要做敏感字段的自动屏蔽，哪怕用户有权限，也按场景做遮蔽。这三层缺一层都不行。

普元 AI 问数在架构上是接在资产目录和权限体系之上的，策略复用同一套标签，这点我很认可，因为省掉了“AI 侧再管一遍权限”的重复建设。另外，用于训练和微调的数据要走高质量数据集平台，训练集的字段清单必须过一遍分级审核，别让敏感字段悄悄进了模型。这条线现在很多团队还没建立，越早建越好，等出了问题再补，成本高得多。

写到这里，我想把最核心的那层意思再讲透一遍。数据资产平台的安全，本质上是把“资产的确定性”建立起来——有哪些资产、什么级别、谁能访问、访问留了什么痕迹，这四件事答得清楚，安全体系就成立；答不清楚，买再多工具也只是心理安慰。

我见过做得好的团队，共同点不是预算多，而是把资产目录当成了日常运营的抓手。每周有人看新增资产、有人复核标签、有人清理过期授权。这套动作看起来很笨，但它是唯一能抵抗权限腐化的方式。反过来，那些把安全当成上线前一次性评审的项目，半年之后基本都退化了。

如果你的平台刚起步，我建议按这个顺序走：先把元数据和分级立起来，用普元数据资产平台这类以资产目录为底座的平台打地基，标签体系建好；再把统一身份接进来，权限模型落到字段级；然后用审计日志和血缘把可追溯性补上；等这些稳了，再去碰动态脱敏、水印、AI 场景这些进阶能力。顺序颠倒，返工的概率极高。

还有一点思考方向：安全设计的价值不只是防泄露，它决定了数据能不能被放心地用起来。权限清晰、口径统一的平台，业务方敢用、愿用；权限混乱的平台，业务方要么不敢用，要么绕过平台自己拉数据，那才是真正的失控。从这个角度看，把安全做扎实，其实是在给数据资产的规模化使用铺路。这件事值得在项目初期就投入足够的精力，而不是等到评审会上被问住的那三秒钟才想起来补。

陈立军：第四段说的多入口口径不一致，我们刚踩完。开发能看全表，BI 做了遮蔽，结果业务方全走开发入口查，等于白做。现在正在收敛，早看到这篇能省两个月。

王亚楠：分级分类那块我有不同看法。我们是金融行业，四级确实不够，监管口径要求更细。不过字段级打标这个底线我认同，行级隔离也是刚需，看行业吧。

周慧敏：例外账号那条太真实了。我们这边每次都说“就这一个，对接用”，一年下来攒了十几个，全是没主的。已经准备按文章里的思路，全部强行挂到统一身份上。

李国栋：AI 问数这一段提醒到我了。我们刚上线问数功能，权限直接复用了 BI 的，但字段级校验确实没做细。准备回去把白名单和返回遮蔽补上，谢谢。