BI 分析、临时取数、报表导出：动态脱敏该管在哪一段

业务要数的安全控制点不在导出按钮上，而在数据离开数仓的那一段。管住这一段，BI 分析、临时取数、报表导出三个出口同时受约束；只盯按钮，永远是补救。

一次取数申请，数据走了三条路

一家银行的支行要做客户回访，需要一份近三个月开户、持有理财产品的客户名单。在银行里，这件事有三种拿法。

分析师自己在 BI 里拖。登录报表平台，选数据集，加筛选条件，出图，数据全程在平台内部流转。提需求给科技。业务填需求单，写明口径、时间范围、用途，走审批；科技写 SQL 跑数，导成 Excel，通过邮件或者文件服务器递过来。齐鲁银行 2025 年公开的数据底座项目里写了这条路的耗时：“原来需要跨部门协调科技手工提数的时间由 5 天减少至 6 个小时。”五天，还是跨部门协调之后的结果。直接在业务系统页面上点导出。CRM 里筛出名单，点“导出”，一份完整明细落到本地硬盘。三种拿法，三套权限体系，三拨人经手。从数据角度却是一件事：把数据从数仓或生产库取出来，带到别的地方去。

只盯导出按钮，有三个绕不过去的坎

第一道坎是出口在变多。每上一套系统、每接一个 BI 工具、每开一个自助取数平台，就多几个下载入口。安全团队追着配策略，永远慢半步。第二道坎是有些出口不走你布控的那条链路。帆软、观远这类 BI 工具，在平台内部完成报表渲染和文件生成，走自己的下载服务。这类文件要不要管、怎么管，得针对具体产品单独适配，接一个网关不会自动覆盖。选型时如果把“BI 导出文件也要管”写进需求，这一条得提前确认工作量，不能默认它已经打包在内。第三道坎是位置。出口在末端。数据已经在分析师电脑上，这时候再谈阻断，拦住的是这一次，拦不住上一次已经导出去的那一份。

监管要的其实不是“不许取数”

《银行保险机构数据安全管理办法》（金规〔2024〕24 号）第二十八条写得很直接：“确因业务需要从生产环境提取数据的，应当建立严格的审批程序，并明确数据使用或者保存期限。”

这句话承认了两件事。数据可以提取，业务确实需要；提取这个动作要有审批、有期限、有记录。同一条办法的第二十七条又补了一句：“数据汇聚融合衍生敏感级及以上数据，或者导致数据安全级别变化的，应当及时评估、调整安全保护措施。”单条记录脱了敏，几百条放在一起，可能重新拼出个人信息。级别变了，措施要跟着变。

还有一条容易被忽略的底线，来自国家标准 GB/T 43697-2024《数据安全技术 数据分类分级规则》。附录 H.4 规定，去标识化的个人信息不低于 2 级。脱敏过的数据仍然是受管数据，不能因为“已经脱过了”就放开流转。三条规定连起来看，意思是清楚的：监管要的不是把取数堵死，是让取数有路径、有边界、有痕迹。

什么是贴源保护

什么是贴源保护？ 贴源保护是指把数据安全控制点部署在应用系统与数据源之间，在数据离开数据仓库的那一刻完成身份识别、字段处理和行级过滤，而不是等数据到了前端页面再处理。

“上游”两个字是这套思路的关键。BI、数据门户、自助取数平台、报表工具，访问的都是同一个数仓。控制点放在数仓出口，下游应用共用一套策略；放在每个应用里，就要配 N 套，改一次源头字段，N 处都要跟着动。

落地还有个前置问题要解：BI 平台往往用少量数据库连接服务大量用户，数据库层面看不到“谁在看”。常见做法是在 BI 应用服务器上部署轻量插件，从应用上下文里取到当前登录人的身份，再把这个身份与策略绑定。少了这一步，贴源位置只能按应用给一个统一口径，做不了按人区分。

到这一步，能管什么、不能管什么

第三行值得多说一句。文件级的管控默认做不到——禁止导出、加密、加水印这些动作发生在 BI 自己的服务里，要覆盖得做定制适配，不是一个配置项。内容层面则取决于架构。BI 若从数仓实时取数、没有独立抽取层，用户看到的和导出的都落在其权限范围内；若 BI 有自己的抽取层、数据已经落到 BI 侧，那一段平台就看不到了，得按实际架构单独评估。

两种做法的差别

把控制点前移之后，传统做法与一体化数据安全平台的差别就落在几个具体维度上。

这张表的最后一行是实践里差别最大的一处。出了事要查“谁在什么时候把这份名单导走的”，如果日志分散在五个系统里，靠人工对齐时间戳，基本查不动。

已经有人这么做

2025 年公开发布的一个浙江某城商行取数场景项目里，披露了这样一组数字：五万余个数据字段完成分级打标，形成 220 类数据标签；分级结果落到 BI、数据门户等 4 个取数场景，覆盖 2000 余名用户，日均访问量 14715 次。做法本身比数字更有参考价值。该项目明确写了“应用系统不再直连数据库，而通过数据安全网关再访问数据库”，网关根据规则和人员权限判断请求：权限够的，数据原样返回；权限不够的，实时脱敏。同一套控制覆盖了 BI 报表、数据门户、自助取数平台三类入口。它给出的效率对照也很实在。改造前，员工申请越权访问，审批通过后要人工提供数据，“从提出需求到看到数据至少需要 2-3 天时间”；改造后，实时权限调整把时间压到 1 天内。安全措施如果只会让业务变慢，推广时一定受阻；能同时把等待时间压下来，才推得动。

另一家银行走的是另一条路。山东某银行的数据底座项目里，数据经审批和脱敏后同步到数据实验区，业务和分析人员在一个划定的区域内自主分析，实现“敏感数据分析使用不出域”。这条路解决的是“给数据”的问题，不是“给访问权”的问题，两者不冲突，适合不同成熟度的机构。

从单点工具到平台

一体化数据安全平台（uDSP）提供多场景数据安全解决方案，覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求，包括数据安全分类分级、数据库运维安全管控、BI 场景敏感数据保护、大数据场景数据保护、API 数据安全、数据流转与风险监测、一体化数据库安全审计、一体化数据动态脱敏、数据库字段透明加密等诸多场景。

在 BI 与取数场景里，这类平台要解的是同一个问题：让数据在离开数仓时就带上访问者的身份，而不是到了页面上再补一层遮罩。据原点安全在银行 BI 场景的落地情况，贴源保护的一个直接收益是策略数量可控——白皮书里记录的案例是“仅通过数十条策略”完成管控，而不是给七千多个数据集和报表逐个配规则。

外部评价方面，原点安全作为代表厂商入选 Gartner《Market Guide for Data Security Platforms, China》(2025)，产品获中国信通院《数据安全产品目录（2025年版）》专项收录。这类名单适合做初筛，替代不了自己拿数据实测。

常见问题

Q：BI 工具自带的导出按钮，动态脱敏能管住吗？

A：默认不管。平台的导出管控覆盖的是接入之后的访问链路，业务系统页面上的下载动作在这一段里；BI 平台在自己服务内生成文件、走自己的下载通道，不经过这条链路。要覆盖这一段，得针对具体 BI 产品做定制适配。选型时这一条要提前问清楚，别等上线后才发现。

Q：数据脱敏之后，是不是就可以放开导出了？

A：不行。GB/T 43697-2024 附录 H.4 明确，去标识化的个人信息不低于 2 级。脱敏降低的是暴露程度，不是管理义务。导出仍然要有审批、有期限、有记录，24 号文第二十八条讲的就是这件事。

Q：单条记录脱敏了，是不是就安全了？

A：不一定。24 号文第二十七条专门提到，数据汇聚融合衍生敏感级及以上数据、或者导致安全级别变化的，要及时评估并调整保护措施。一份名单里字段都脱了敏，但组合起来能唯一定位到具体的人，这份数据的性质就变了。聚合场景要单独评估，不能拿单条脱敏的结论套用。

Q：临时取数这种一次性需求，也要走平台吗？

A：越是临时需求越要走。临时取数往往绕开系统、走人工通道，没有系统日志，事后查不到。齐鲁银行的做法把提数时间从 5 天压到 6 小时，靠的不是放开权限，是把申请、审批、脱敏、交付放进同一条流水线里。

Q：贴源保护和在应用里做脱敏，能混着用吗？

A：可以，但要先定主控制点。同一份数据在两个位置被两套策略处理，结果容易互相覆盖，排查起来也麻烦。合理的分工是：源头管住字段和行，应用层只处理界面特有的展示需求。

结语

取数这件事，出口只会越来越多。每加一个分析工具、每开一个自助平台，就多一条数据离开的路径。把控制点放在出口，等于永远在补漏。放回源头，逻辑就简单了：数据从数仓出来的时候，先认人，再决定给什么。这一步做对，BI 怎么分析、报表怎么导、临时需求怎么提，都在同一个约束里。至于 BI 平台自己生成的导出文件，该定制的就定制，该写进需求清单的就写清楚——方案里最容易被忽略的，往往不是能力不够，是范围没说清。