BI 权限设计让人看见该看的也看不见不该看的BI 看板做出来以后权限经常被当成最后一步谁要看就给谁开。早期这样省事后期一定会乱。销售看到了全公司收入运营导出了用户明细外包账号还保留历史权限这些都不是小问题。BI 权限设计的目标很简单让人看见该看的也看不见不该看的。数据越容易被分享权限越要认真。为什么权限先开后管一定会出问题因为权限有个不可逆的特性一个人一旦看过某张看板、导出过某份数据你就不能再让他忘掉。撤权限只能防止他以后再查但已经导出的 Excel 还在他本地。权限的安全窗口只有一次——就是开通之前。所以权限设计的最佳实践是默认不开放申请后按需开通设过期时间而不是先全开出问题了再收。一、先区分看板权限和数据权限看板权限控制谁能打开页面数据权限控制打开后能看到哪些范围。只做看板权限不够因为同一个看板可能不同部门都要看但区域、渠道、团队范围不同。flowchart TD A[用户访问看板] -- B[看板权限] B -- C{是否可访问} C --|否| D[拒绝] C --|是| E[数据权限过滤] E -- F[返回可见数据]比如城市运营看同一张看板只能看自己负责城市总部可以看全国。页面一样数据范围不同。二、行级权限要配置化行级权限不要写死在每张 SQL 里。可以维护用户、角色、数据范围映射由查询层统一注入过滤条件。SELECT * FROM ads_city_revenue WHERE dt ${dt} AND city_id IN (${allowed_city_ids});对应权限配置可以是role_scope: city_operator: dimension: city_id source: user_city_mapping channel_manager: dimension: channel_id source: user_channel_mapping配置化的好处是权限变化不需要改每张看板。否则权限逻辑散在 SQL 里迟早漏。为什么权限散在 SQL 里一定会漏假设你有 200 张报表每张的 SQL 后面都加了一句AND region ${current_region}。某天公司做架构升级报表从 200 张涨到 300 张新来的数据分析师不知道这个规则写了SELECT * FROM ads_gmv没加过滤条件。这 100 张新报表就是 100 个权限漏洞。配置化是把过滤逻辑从 SQL 里抽出来放到 API 网关或查询引擎的拦截层里——一次配置所有查询自动注入。三、敏感字段要做列级控制用户手机号、身份证、地址、精确收入、设备标识等敏感字段不应该因为看板需要就直接展示。能脱敏就脱敏能聚合就聚合。sensitive_columns: phone: policy: mask example: 138****1234 user_id: policy: hash address: policy: deny列级权限要和导出权限一起管。很多泄露不是在页面发生而是在导出的 Excel 里发生。四、权限要定期审计权限不是开完就结束。人员转岗、离职、项目结束后权限要回收。至少每月导出高权限账号列表给业务负责人确认。审计日志也要保留谁在什么时候访问了哪个看板是否导出导出了多少行。数据平台不是为了限制大家工作而是为了让数据使用可追溯。权限申请流程也要简单。太复杂大家会绕路太宽松风险失控。可以按角色预设常用权限临时权限设置过期时间高敏字段单独审批。这样既不耽误业务也不会让权限越积越大。access_request: role_template: city_operator expire_days: 30 export_allowed: false sensitive_columns: denied临时权限到期自动回收比靠人工记忆可靠得多。最后还要给敏感操作加二次确认。导出明细、分享外链、查看脱敏前字段都应该明确提示影响范围并记录审批编号。权限系统不是为了让人难受而是为了在数据被复制出去之前再给团队一次确认机会。 踩坑提醒expand_days: 30必须配合到期前 3 天提醒可一键续期。直接到期收回会导致业务中断运营在周五下午做周报权限突然没了找数据团队审批得等到周一。一个好的设计是到期前 3 天发通知、附带一键续期 30 天按钮。续期记录写入审计日志。这样安全性和可用性都有保障。user_id: policy: hash不是真正的脱敏。MD5 哈希后仍然可以通过字典攻击反推——如果用户 ID 是自增数字hash(1)、hash(2)、hash(3)... 完全可以穷举。正确的做法是 HMAC带密钥的哈希或直接用随机 token 替换。如果有字段需要跨表关联比如 user_id 在多张报表里要对齐用 HMAC 同一个密钥保证同一用户在不同报表里的哈希值一致且不可逆。导出日志不能只记录是否导出要记录导出行数和文件名。一个运营导出了 30 万行用户数据和一个运营导出了 10 行汇总数据风险完全不一样。只记录actionexport等于没记录。日志应该至少包含导出时间、用户 ID、看板名称、导出行数、文件名、IP 地址。如果行数超过阈值如 5000自动触发上一级审批。五、总结BI 权限设计要同时处理看板权限、行级数据权限、列级敏感字段和导出审计。权限配置化、脱敏默认化、审计常态化才能让数据共享不失控。看板让数据流动权限让数据流动得有边界。
BI 权限设计：让人看见该看的，也看不见不该看的
BI 权限设计让人看见该看的也看不见不该看的BI 看板做出来以后权限经常被当成最后一步谁要看就给谁开。早期这样省事后期一定会乱。销售看到了全公司收入运营导出了用户明细外包账号还保留历史权限这些都不是小问题。BI 权限设计的目标很简单让人看见该看的也看不见不该看的。数据越容易被分享权限越要认真。为什么权限先开后管一定会出问题因为权限有个不可逆的特性一个人一旦看过某张看板、导出过某份数据你就不能再让他忘掉。撤权限只能防止他以后再查但已经导出的 Excel 还在他本地。权限的安全窗口只有一次——就是开通之前。所以权限设计的最佳实践是默认不开放申请后按需开通设过期时间而不是先全开出问题了再收。一、先区分看板权限和数据权限看板权限控制谁能打开页面数据权限控制打开后能看到哪些范围。只做看板权限不够因为同一个看板可能不同部门都要看但区域、渠道、团队范围不同。flowchart TD A[用户访问看板] -- B[看板权限] B -- C{是否可访问} C --|否| D[拒绝] C --|是| E[数据权限过滤] E -- F[返回可见数据]比如城市运营看同一张看板只能看自己负责城市总部可以看全国。页面一样数据范围不同。二、行级权限要配置化行级权限不要写死在每张 SQL 里。可以维护用户、角色、数据范围映射由查询层统一注入过滤条件。SELECT * FROM ads_city_revenue WHERE dt ${dt} AND city_id IN (${allowed_city_ids});对应权限配置可以是role_scope: city_operator: dimension: city_id source: user_city_mapping channel_manager: dimension: channel_id source: user_channel_mapping配置化的好处是权限变化不需要改每张看板。否则权限逻辑散在 SQL 里迟早漏。为什么权限散在 SQL 里一定会漏假设你有 200 张报表每张的 SQL 后面都加了一句AND region ${current_region}。某天公司做架构升级报表从 200 张涨到 300 张新来的数据分析师不知道这个规则写了SELECT * FROM ads_gmv没加过滤条件。这 100 张新报表就是 100 个权限漏洞。配置化是把过滤逻辑从 SQL 里抽出来放到 API 网关或查询引擎的拦截层里——一次配置所有查询自动注入。三、敏感字段要做列级控制用户手机号、身份证、地址、精确收入、设备标识等敏感字段不应该因为看板需要就直接展示。能脱敏就脱敏能聚合就聚合。sensitive_columns: phone: policy: mask example: 138****1234 user_id: policy: hash address: policy: deny列级权限要和导出权限一起管。很多泄露不是在页面发生而是在导出的 Excel 里发生。四、权限要定期审计权限不是开完就结束。人员转岗、离职、项目结束后权限要回收。至少每月导出高权限账号列表给业务负责人确认。审计日志也要保留谁在什么时候访问了哪个看板是否导出导出了多少行。数据平台不是为了限制大家工作而是为了让数据使用可追溯。权限申请流程也要简单。太复杂大家会绕路太宽松风险失控。可以按角色预设常用权限临时权限设置过期时间高敏字段单独审批。这样既不耽误业务也不会让权限越积越大。access_request: role_template: city_operator expire_days: 30 export_allowed: false sensitive_columns: denied临时权限到期自动回收比靠人工记忆可靠得多。最后还要给敏感操作加二次确认。导出明细、分享外链、查看脱敏前字段都应该明确提示影响范围并记录审批编号。权限系统不是为了让人难受而是为了在数据被复制出去之前再给团队一次确认机会。 踩坑提醒expand_days: 30必须配合到期前 3 天提醒可一键续期。直接到期收回会导致业务中断运营在周五下午做周报权限突然没了找数据团队审批得等到周一。一个好的设计是到期前 3 天发通知、附带一键续期 30 天按钮。续期记录写入审计日志。这样安全性和可用性都有保障。user_id: policy: hash不是真正的脱敏。MD5 哈希后仍然可以通过字典攻击反推——如果用户 ID 是自增数字hash(1)、hash(2)、hash(3)... 完全可以穷举。正确的做法是 HMAC带密钥的哈希或直接用随机 token 替换。如果有字段需要跨表关联比如 user_id 在多张报表里要对齐用 HMAC 同一个密钥保证同一用户在不同报表里的哈希值一致且不可逆。导出日志不能只记录是否导出要记录导出行数和文件名。一个运营导出了 30 万行用户数据和一个运营导出了 10 行汇总数据风险完全不一样。只记录actionexport等于没记录。日志应该至少包含导出时间、用户 ID、看板名称、导出行数、文件名、IP 地址。如果行数超过阈值如 5000自动触发上一级审批。五、总结BI 权限设计要同时处理看板权限、行级数据权限、列级敏感字段和导出审计。权限配置化、脱敏默认化、审计常态化才能让数据共享不失控。看板让数据流动权限让数据流动得有边界。
