📚 课程目录第4章数据资产Owner的权限管理

4、数据资产Owner的权限管理：数据访问权限、数据修改权限、数据发布权限、权限回收机制

权限管理这事儿，说白了就是给数据资产上锁配钥匙。我见过太多团队，Owner 头衔挂上了，但权限边界模糊，最后数据乱成一锅粥。你想想看，一个数据资产如果谁都能改、谁都能发，那 Owner 还怎么负责？

我个人习惯把权限拆成四个维度来管：访问、修改、发布、回收。每个维度都有它的门道，咱们一个一个说。

访问权限是最基础的防线。我记得刚带数据团队那会儿，有个业务部门把客户画像数据设成了全员可读，结果被非相关同事下载后泄露了。从那以后，我对访问权限的管控就特别较真。

访问权限的核心原则就一条：最小够用原则。不是所有人都需要看到全量数据，也不是所有场景都需要实时数据。

访问权限分级模型（我常用的）

实际操作中，我建议 Owner 在数据资产上线时就打好标签。比如在数据目录里标注「L3-敏感」，这样后续的权限配置就有据可依。

一个小技巧：访问权限最好跟组织架构联动。员工入职/转岗/离职时，权限自动同步，省得手动维护。我曾经吃过亏，一个离职员工的账号半年后才被回收，中间数据被谁看过都查不清。

修改权限比访问权限更敏感。为什么？因为改数据是「写操作」，一旦出错，影响面可能很大。我见过最夸张的一次，有人误改了核心指标的计算口径，导致整个季度的报表全错了。

修改权限我一般分三层：

这里有个坑：编辑权限一定要有变更记录。我习惯要求所有修改操作都走工单系统，哪怕只是改一个字段值。这样出了问题能追溯，谁改的、什么时候改的、改之前是什么，一目了然。

注意：不要给任何人「直接修改生产数据」的权限。我见过一些团队为了方便，让业务人员直接连数据库改数，结果误删了整张表。正确的做法是：修改走审批 -> 测试环境验证 -> 灰度发布 -> 全量更新。

发布权限，管的是数据「对外输出」的环节。不管是生成报表、开放 API，还是导出数据文件，都属于发布行为。

我个人习惯把发布权限分成两类：

内部发布相对宽松，但也要有审批流。我建议 Owner 设置一个「发布审批人」角色，所有内部发布至少经过一人审批。外部发布则必须 Owner 本人审批，必要时拉上法务和安全团队。

发布权限的黄金法则：

嗯，这里要特别提一下「数据发布」和「数据共享」的区别。发布是一次性的，共享是持续性的。如果是持续共享（比如 API 接口），一定要设置有效期和调用频率限制。我遇到过合作方拿着我们的 API 接口疯狂调用，差点把服务打挂。

权限回收，是很多团队容易忽略的环节。大家往往只关注「给权限」，却忘了「收权限」。结果就是权限越积越多，安全隐患越来越大。

我总结了一套回收机制，叫「三时回收法」：

我曾经在季度审计时发现，一个已经离职半年的前同事，居然还有核心数据表的访问权限。原因就是权限回收流程没跟 HR 系统打通。后来我推动做了自动化对接，员工离职当天，所有数据权限自动回收，再也没出过类似问题。

避坑指南：权限回收后，一定要给相关人员发通知。我曾经直接回收了一个业务负责人的权限，结果他正在用的报表突然打不开了，差点耽误了周报。后来我改成「先通知，再回收，给 24 小时缓冲期」，就再没出过这种乌龙。

说了这么多，咱们用一张图把整个权限管理串起来。这张图是我在实际项目中反复打磨出来的，你可以直接拿去用。

这张图的核心逻辑是：Owner 作为权限管理的中心节点，向下管控四个维度，每个维度又有具体的落地策略。最底部的三个原则，是我踩过无数坑后总结出来的底线。

最后说一句：权限管理不是一锤子买卖。它需要 Owner 持续关注、定期审计。我每个季度都会拉一份权限清单，看看哪些权限是多余的、哪些该收还没收。养成这个习惯后，数据安全这块基本没出过大问题。