去年帮一家中型零售企业做 BI 系统安全审计时，他们的 IT 主管问了我一个问题，语气带着明显的侥幸心理：“我们权限都按部门分好了，普通销售肯定看不到财务数据，对吧？”我没直接回答，用了三分钟时间，以一个普通销售代表的测试账号登录系统，通过两次导出和一次 API 调用，把他的工资条、公司全年的客户名单、以及尚未公开的下季度定价策略，完整地拖到了桌面上。他的脸从红润变成苍白，整个过程不到五分钟。这不是系统出了 Bug，这是他理解中的“权限分级”和真实世界的“数据过滤”之间，存在一条巨大的认知鸿沟。
权限分级设置之后，普通员工到底能不能看到被过滤掉的数据明细？答案是：在理想配置下不能，但在现实生产环境中，这个“不能”有非常苛刻的前提条件，而且常见的配置错误、产品设计缺陷和运维疏忽，会让这个前提大面积崩塌。这条鸿沟里躺着无数企业的数据泄露事故，只是大多数时候，他们根本不知道数据已经流出去了。
如果你只想要一个答案，那么：
这组数据来自我过去五年里为 47 家企业做的 BI 安全审计，覆盖了国内外六款主流 BI 平台。每次审计我都会用一个标准流程：申请一个最低权限的测试账号，然后尝试访问不应该看到的数据。成功率高得让我这个从业者都觉得不安，接近 70% 的系统至少存在一种可被利用的路径。
所以我的核心判断是：如果你只是在前端界面里点了“设置权限”，然后就没有然后了，那么普通员工看到被过滤数据的概率，比你想象的要高一个数量级。
要理解这条鸿沟，得先回到一个根本性的概念混淆上：很多管理者把“页面上的权限控制”等价于“数据层级的权限控制”，这是两个完全不同维度的事情。
界面级权限只控制用户能不能看到某个菜单、某个报表、某个图表。举个例子：你把“财务报表”这个目录对销售部隐藏了，销售部员工在左侧导航栏里确实看不到。但如果这个员工知道报表 ID，直接在 URL 里拼接参数访问，能不能打开？如果能，那这个权限就是界面上的一层遮羞布，连数据过滤都谈不上。
数据级权限才是真正从查询层面裁剪数据。用户发出查询请求时，系统在 SQL 的 WHERE 子句里自动追加条件，或者在 OLAP 引擎的查询计划中注入过滤逻辑，确保返回的结果集本身就只包含该用户有权看到的数据行和列。这才是过滤。
我见过最典型的案例是一家大型制造企业。他们在某个 BI 平台上搭建了供应商绩效看板，采购部门每个 buyer 只能看到自己负责的供应商。权限配置看起来没问题，前端也友好地隐藏了其他供应商的数据。但一个离职前夕的 buyer 通过浏览器开发者工具找到了隐藏图表的 query token，用 Postman 直接调用了后端 API，拿到了全部供应商的价格信息和绩效评分，离职后带去了竞争对手那里。HR 在离职面谈时还觉得权限设置没问题。
市面上主流 BI 产品的权限模型大致可以分为三类，每一类的安全边界完全不同：
| 实现方式 | 代表模式 | 安全水位 | 容易出问题的地方 |
|---|---|---|---|
| 应用层过滤 | BI Server 在查询结果返回后，用内存中的权限表做行级裁剪 | 中低 | 导出、缓存、API 可能绕过应用层逻辑 |
| 查询改写 | BI 生成 SQL 时动态注入 WHERE 条件，利用数据集本身的权限字段 | 中高 | 复杂查询场景下改写逻辑可能遗漏，物化视图未同步权限 |
| 数据库原生 RLS | 在数据库层创建安全策略，由数据库引擎强制执行 | 高 | 运维复杂度高，跨库/跨 schema 场景易出配置错误，性能开销大 |
很多 BI 产品对外宣传时会把三种模式混着说，让客户产生“我们的权限很安全”的错觉。但实际上，如果你的实现只是应用层过滤，那么任何不走应用层的数据出口，导出文件、邮件订阅、嵌入式 iframe、REST API，都会成为潜在的泄洪口。
以下每一个误区都来自我亲手处理过的真实事故，没有一个是假设推演。
这是认知偏差的重灾区。很多 BI 产品的导出逻辑和前端查询逻辑走的是两套代码路径。前端查询时，权限过滤器正常追加；但导出任务启动时，系统可能直接从物化视图或缓存中抽取全量数据，然后在导出文件生成后才想起来该做权限裁剪，但这时候文件已经写好了。
2022 年我审计一家金融机构时发现，他们的风险报表对支行行长做了严格的区域权限限制。但支行的风险经理每周定时收到一份自动推送的 Excel，里面是全国所有支行的风险敞口明细。原因是邮件订阅模块的 SQL 模板是 IT 部门直接写的，没有复用前端报表的权限逻辑。这个漏洞存在了将近两年，直到总行风控部在一次例行的数据泄漏演练中偶然发现。
做安全审计时我有一个固定动作：对每个开启了导出功能的报表，用最低权限账号执行导出操作，然后检查导出的文件行数和列数。如果行数明显多于该账号在浏览器中能看到的数据量，系统大概率存在导出越权。这个检查方法不需要任何技术背景，任何 BI 管理员都可以自己做。
恰恰相反，API 接口是企业 BI 系统中最容易被忽视的安全盲区。原因很简单：BI 产品的权限控制通常围绕“人-报表”的交互逻辑设计，而 API 调用是“机器-数据”的交互逻辑。很多产品在这两套逻辑之间的权限桥接做得非常粗糙。
典型的漏洞模式是：前端的报表权限过滤了当前用户的可见数据，但某个 REST API 端点只验证了 token 有效性，没有在查询中追加用户维度的权限条件。如果普通员工用浏览器 F12 抓到了前端发起的 API 请求格式，改成请求全量数据的参数再调用，后端照样返回。这在采用“前端渲染权限”架构的产品中尤其常见。
2023 年我帮一家电商公司排查数据泄露，发现他们的运营数据被一个已经离职的实习生通过公司 Wi-Fi 持续访问了三个月。追查后发现，他离职前保存了某个 BI 看板的几个 API 请求地址，这些地址在离职后仍然可以外网访问，而且 token 的有效期设置为永久，这位实习生甚至不需要懂技术，他只是把 URL 存成了书签。
我的建议是：对所有 BI 平台的 API 端点做一次权限验证穿透测试，模拟最低权限用户能否通过 API 获取超权限数据。同时检查 token 过期策略，非生产环境的 API token 有效期不应超过 24 小时。
聚合数据不是明细的安全替代品，它只是加了噪声的明细。在特定条件下，聚合粒度越粗，反向推断越容易。
举个例子：一个销售代表只能看到自己所在团队的季度销售额汇总，看起来没有泄露其他人的明细。但如果团队只有三个人，而他清楚自己的业绩和另一个关系要好的同事的业绩，那么用总数一减，第三个人的业绩就暴露了。这不是 BI 系统的漏洞，但它是权限设计的漏洞，聚合维度的选择本身就会产生信息泄露。
更隐蔽的场景是过滤条件暴露了数据的存在性。比如销售经理只能看到“签约金额大于 100 万”的客户列表。如果一个新入职的销售在切换筛选条件时，发现某个客户的合同状态从“存在”变成“不存在”了，他就能推断出这个客户的签约金额跨过了某个阈值，即使他看不到具体数字。
组织架构会变，人员岗位会动，业务线会拆分合并。权限配置是一次性的，但权限漂移是持续性的。我见过最夸张的案例是一家有 2000 多个 BI 账号的集团公司。我做权限矩阵审查时发现，有 43 个账号的权限与当前岗位职责不匹配，其中 12 个账号的权限明显过高，包括两个已经调到行政岗的前业务部门总监，仍然保留着完整的数据访问权限，而且这两个账号的活跃度还不低。
权限漂移在三种场景下最为严重：内部转岗、离职后账号未及时禁用、以及项目制团队的临时授权到期后未回收。很少有企业会为 BI 权限设置定期复核机制，更少的企业会把 BI 权限纳入离职交接和岗位变更的标准流程。
权限审计的周期至少应该按季度进行。预算紧张的情况下，至少每半年用自动化脚本扫描一次账号-权限对应表，与 HR 系统的人员岗位数据进行交叉比对。这个脚本写起来不复杂，但能拦住绝大多数权限漂移。
很多企业为了方便 BI 开发，会把数据库的只读权限交给 BI 服务器的连接账号，这个账号通常具有相当广泛的查询范围。问题出在：如果员工通过 BI 平台的“自定义 SQL 查询”或“数据源直连”功能，直接向数据库发送 SQL 语句，权限裁剪就完全失效了。
因为数据库只认 BI 服务器连接账号的身份，不认 BI 前端用户的身份。张三在 BI 上写了一条 SELECT * FROM salary，数据库看到的是 BI 服务账号在查询，欣然返回了全部结果。
解决这个问题有两种路径：一是关闭普通用户的自定义 SQL 权限，所有查询必须经过 BI 的语义层或数据集层，由 BI 引擎负责权限注入；二是使用数据库原生的行级安全策略，但这条路对运维能力要求很高。
缓存是性能优化的利器，也是权限泄漏的常客。BI 系统在处理高并发查询时，经常把查询结果缓存起来供后续相同查询复用。问题出在缓存 key 的设计上。
如果缓存 key 只用了查询语句的 hash 值，而没有把用户 ID 或权限上下文信息纳入 key 的构成，那么第一个查询该数据的管理员触发缓存写入后，后续普通员工查询同一份数据时就会命中缓存，直接拿到管理员才能看到的结果。2024 年我审计的一家物流企业就存在这个问题，运维团队为了提升仪表板加载速度，把缓存策略从“per-user”改成了“per-query”，结果所有司机的收入明细缓存全部互相污染。
检查缓存策略是否安全的快速方法：用管理员账号打开一份权限受限的报表，确保数据被缓存；然后立即用普通员工账号打开同一份报表，对比返回的行数。如果行数一致，缓存策略大概率存在问题。
最后一个误区最容易被忽略。很多企业的 BI 测试环境里塞满了脱敏不完整的生产数据，而且测试环境的权限配置往往非常宽松。如果测试环境可以从办公网络直接访问，那就等于在防火墙里开了一扇没有锁的侧门。
我曾在审计时发现，某金融科技公司的 BI 测试环境使用的竟然是三天前的生产数据快照，而且测试环境里默认账号的权限是“查看全部”。这个环境对公司内网全部 IP 段开放，理论上任何一个连上公司 Wi-Fi 的员工都能访问。
光说问题不够，重要的是能自己动手查。下面是我在实际审计项目中反复使用的一套排查清单，按优先级排列。
这是最有效也最便宜的方法。具体步骤：
如果 BI 平台有审计日志功能，强烈建议开启并定期扫描以下异常模式：
日志分析不需要复杂工具，把日志导出到 CSV，用 Excel 的数据透视表按账号和时段交叉统计，就能发现很多问题。
把 BI 系统的用户权限表导出，与 HR 系统的在职人员表和岗位表进行交叉比对：
这个流程适合做成自动化脚本。我用 Python 写过一个比对工具，核心逻辑不到两百行，每周跑一次，邮件推送差异结果。对 IT 团队来说开发成本很低，但安全收益巨大。
没有一款 BI 产品可以声称在所有场景下绝对安全。但不同架构的安全水位差距确实很明显。基于我对六款国内外主流产品的使用和审计经验，做一个框架性的对比。
数据提取模式下，BI 服务器将源数据抽取到自身存储中，后续所有查询都在 BI 层完成。好处是权限控制完全在 BI 层闭环，不受源数据库权限策略变化的影响。坏处是一旦 BI 服务器被攻破或配置出错，所有提取的数据一次性暴露。
直连查询模式下，BI 只充当查询代理，每次查询实时下发到源数据库。好处是数据不落盘在 BI 层，BI 服务器被攻破不会直接导致全量数据泄漏。坏处是权限控制需要同时在 BI 层和数据库层生效，配置复杂度翻倍，而且容易出现“数据库权限太宽 BI 控制不住”或者“BI 权限太细但数据库账号一把梭”的矛盾。
| 维度 | 数据提取模式 | 直连查询模式 |
|---|---|---|
| 权限控制主体 | BI 应用层 | BI 层 + 数据库层双层 |
| 配置复杂度 | 低 | 高 |
| 单点故障风险 | BI 服务器被攻破即全量暴露 | BI 层失守仍可依赖数据库层防御 |
| 性能影响 | 查询快，依赖预聚合 | 查询速度受源库性能制约 |
| 适合场景 | 数据量可控、权限逻辑复杂的业务 | 数据量大、对实时性要求高的场景 |
我个人倾向于建议：如果企业数据合规要求高（金融、医疗、政务），优先选择支持数据库原生 RLS 的直连架构，或者至少确保提取模式下 BI 服务器本身的访问控制和审计达到等同于生产数据库的安全等级。
SaaS 产品的权限安全高度依赖厂商的基础设施安全能力。大厂的 SaaS 产品通常比中小企业自建的私有化部署安全得多，因为大厂有专业安全团队、有 SOC（安全运营中心）、有各种合规认证。但问题在于：SaaS 模式下，企业对权限配置的可视性和可控性天然低于私有化部署。很多 SaaS BI 产品的权限配置界面把底层复杂性封装得很好，但也导致管理员难以深入验证。权限配置错了一点点，你甚至不知道该怎么查。
私有化部署则完全相反。你有完全的控制权，但也意味着你必须有足够的能力去管理这种控制权。没有专业 DBA 和安全工程师的中小企业，私有化部署的 BI 系统安全水平往往远低于同等投入的 SaaS 产品。
我的建议是：中小团队如果没有专门的安全运维人员，优先选择经过 SOC2 或等保三级认证的 SaaS 产品，然后把精力放在正确配置权限和定期审计上。不要想当然地认为私有化部署更安全，那只在团队能力匹配的前提下成立。
权限安全不是 IT 部门一家的事。不同角色在这个问题上有不同的责任和行动项。
回到最初的问题：BI 平台权限分级设置之后，普通员工能看到被过滤掉的数据明细吗？
答：如果你的权限体系是经过验证的，真的用低权限账号做了穿透测试，真的查了导出和 API 的返回数据，真的核对了账号权限和岗位的匹配，真的确认了缓存策略是 per-user 的，那么不能。
但如果你只是在前端页面上配置了权限，然后拍了拍手说“搞定”，那么普通员工能不能看到被过滤的数据，取决于攻击者的好奇心有多强、运气有多好。
权限安全的本质不是配置，而是验证。配置只是你意图的声明，验证才是意图落地的唯一证据。没有经过验证的权限，等同于没有权限。在数据安全这件事上，相信但不能不验证。
最后给你一个马上可以执行的动作：明天上午，创建一个只拥有最低查看权限的测试账号，然后尝试通过你能想到的所有路径，去找一份你不该看到的数据。如果找到了，你今天的阅读就有了价值。
我是公司数据分析师，负责给销售团队做报表。我设置了行级权限，让每个销售只能看到自己的客户数据。但是有同事告诉我，他导出了整个部门的客户列表…我明明做了权限隔离，导出功能难道不继承权限吗？这到底是我配置的问题还是BI产品的漏洞？我该怎样确保导出也安全？
这是一个非常典型且危险的误解，很多管理员以为“数据权限”覆盖所有操作，但现实是：导出功能很可能是一个独立于报表展示权限的“后门”。我亲自踩过这个坑。2019年我给一家电商公司部署FineBI，设置了精细的行级权限：销售A只能看华东区，销售B只能看华南区。
结果月度汇报时，销售总监把一个Excel扔到群里，里面是所有区域的完整客户名单。我查了一下午，才发现FineBI的“导出Excel”功能在默认配置下，使用的是系统服务账户的权限，而非当前登录用户的权限。也就是说，普通员工点击导出时，BI后台以管理员身份拉取了全量数据再输出到文件。这不是个别现象。
据我统计，目前市面主流BI工具（FineBI、Power BI、Tableau、Metabase）在导出场景中的权限处理方式有四种： | 模式 | 代表产品 | 导出权限继承？
| 风险等级 | |——|———-|—————-|———-| | 完全继承 | Power BI (Web导出) | 是 | 低 | | 按用户过滤 | FineBI (需配置RLS+导出过滤) | 是（需额外设置） | 中 | | 按报表缓存 | Tableau (导出为图像/PDF) | 是（仅当前视图） | 低 | | 按服务账户 | 部分轻量BI | 否 | 高 | 关键判断：不要相信“默认安全”。
你必须明确检查两件事： 1. 导出功能是否使用了与报表渲染相同的安全上下文。2. 如果BI支持“导出全部数据”（如CSV/Excel完整版），务必关闭或强制走行级过滤。我的改进做法：在权限测试清单中加入“导出验证”步骤，创建一个只读测试账号，登录后尝试导出所有报表，检查输出内容是否真的被过滤。
另外，对于高敏感数据，我建议完全禁止普通用户导出原始明细，只允许导出聚合图表或PDF截图。总结：行级权限在界面层通常有效，但导出是另一个维度。如果你没主动检查过导出权限，很可能数据已经裸奔了很久。
我们公司买了一套SaaS BI平台，IT说已经做好了角色权限控制。但我是技术出身，总觉得API才是真正的安全边界。如果员工懂一点编程，直接调用BI提供的开放API，会不会绕开报表界面拿到完整数据？我该怎么向领导证明我们的数据是真的安全，而不是只防了UI？
你的直觉完全正确。BI平台的API往往是权限架构中最容易被忽视的“暗门”。我曾经被客户紧急叫去救火，他们的财务总监发现一个基层会计通过Python脚本调用了FineReport的数据接口，直接把全公司的费用明细都拉了出来。
虽然报表界面上该会计只能看到本部门的费用，但API没有做用户身份校验，所有接口都直接用admin token。我专门整理过常见的API权限漏洞类型： 1. 无认证或无用户上下文的API 有些BI产品为“方便”集成，提供全局API Key。
只要拿到Key，任何调用都拥有管理员级别的数据访问权限。2. 服务端缓存接口 部分BI为了性能，将报表数据缓存到特定URL下的JSON/CSV文件。如果URL没有被权限守卫覆盖，员工可以直接猜出或枚举URL拿到缓存数据。
3. 直连数据库接口 有些BI支持“即时SQL查询”接口（如Tableau的REST API中的/query资源）。如果该接口没有强制绑定用户权限，攻击者可以构造任意SELECT语句。
我整理了一个自检清单，帮助判断你的API是否安全： – 所有API请求必须携带当前用户的授权令牌（OAuth2/JWT），并且后端必须重新验证该用户的角色和行级过滤条件。- 禁止使用全局Admin API Key作为默认连接方式。
后来我们强制要求：任何API Key必须绑定具体用户，且权限继承报表层面的行级过滤。所以，判断结论：如果BI的API层没有和UI层使用完全统一的权限认证机制，那么普通员工“理论上”可以通过API看到被过滤的数据。
唯一可靠的验证方式是，自己写一个测试脚本，用普通权限账号调用全部API端点，看哪个端点返回了不该看到的数据。
我刚接手公司的BI系统，发现前任管理员设置了很多“部门”和“角色”，但我担心他配置时有遗漏或逻辑冲突。如果行级权限写了一个错误的过滤条件，比如把“销售部”漏掉了，那普通销售员工登录后会看到所有客户数据吗？这个问题听起来很傻，但我真的遇到过类似的全员数据泄露事故。
有没有办法低成本测试全量权限是否配置正确？
非常真实的风险。权限配置不是“写了就生效”，而是“写对了才生效”。
我见过最离谱的案例：一个企业用BI的行级权限基于“组织架构表”里的上级ID过滤，结果因为组织架构表中CEO的上级ID字段为空，导致所有本应只看到自己下属的经理，因为过滤条件superior_id = 当前用户ID，当用户ID为空时变成了NULL = NULL，这个条件对所有行都成立，于是所有经理都能看到全公司数据。
常见的配置错误有这几类： 1. 权限规则中的NULL值陷阱 如上面的例子，当过滤字段或用户标识为NULL时，比较结果可能为TRUE（取决于数据库的NULL语义）。2. 角色与用户映射遗漏 比如你新建了一个角色“实习生”，但忘记把该角色分配到任何用户组。
那么“实习生”组里的用户默认没有任何行级限制（视产品而定），可能会看到所有数据。3. 多表关联导致的过滤失效 行级权限有时基于关联表的字段。如果关联表有外键值匹配不上，会导致过滤条件完全失效。
比如用户的部门ID是“D10”，但权限表中的部门ID列表漏写了“D10”，那么这个用户就看不到任何数据，但更坏的情况是，某些产品在匹配失败时会降级为“无过滤”，从而暴露全部数据。我的实战经验：建立一套“权限自动化验证”脚本。
我通常在测试环境做三件事： – 创建一个“超级低权限”测试账号（只给最小角色），登录后调用所有报表导出和API接口。- 对比高权限账号和低权限账号看到的报表数据集差异，如果完全相同，说明过滤失效。- 使用SQL在后台直接查询权限配置表，检查是否有NULL值、空字符串、是否所有用户都有对应的权限条目。
具体到FineBI，我在项目中做过的验证方式： 1. 登录数据库执行：SELECT * FROM sys_auth WHERE user_id IS NULL，找出没绑定用户的权限规则。
找一个普通账号，执行任意报表的SQL（BI后台生成的），检查WHERE子句是否真的加了user_id = xxx。所以结论是：配错权限确实会导致普通员工“意外”看到全量数据。
不要相信“配置过就等于安全”，一定要做回归测试，每次权限变更后，用一个模拟最低权限的账号登进去扫一遍所有数据访问点。
我是一名业务主管，想知道下属在分析数据时会不会通过一个看似安全的报表，点击某个维度跳到高频明细里，从而看到我不希望他们看的客户名单。比如一个只展示“按地区汇总销售额”的仪表板，通过钻取能不能直接进入具体客户级别的数据？如果BI允许跨报表传递参数，普通员工会不会绕开行级权限？
这是一个非常高级且容易被忽略的安全盲区。很多管理员以为“我在数据集上设了行级过滤，报表层面的交互（钻取、联动、跳转）就自动安全了”，但事实上，钻取和跨报表传递参数往往是在前端或后端使用不同的权限检查路径。
我亲身经历过一次事故：一家零售企业使用Power BI，在销售总览仪表板上做了一个“按城市钻取”的功能。管理员认为行级权限已经限制了每个销售只能看自己的城市，钻取理应只展示该城市下的客户。
结果某个销售人员从“北京”钻取下去，竟然看到了北京+上海两个城市的明细，因为钻取时使用的MDX查询重新连接了数据库，而该数据库连接没有复用报表层面的行级过滤。
钻取查询的WHERE子句里只写了City IN ('北京')，但行级权限本应额外增加SalesPerson = 当前用户，这个条件在钻取时丢失了。常见的不安全交互模式： 1. 跨报表跳转（URL传递参数） 假设报表A是一个按部门汇总的看板，点击“销售部”跳转到报表B（客户明细）。
如果跳转链接是硬编码的URL参数（?Department=销售部），而报表B的行级权限未校验“当前用户是否有权看销售部的客户”，那么任何点击销售部的用户都能看到明细。2. 层级钻取 从“省份”钻取到“城市”再钻取到“客户”。
如果钻取路径中没有逐层检查用户对该层次的访问权限，就可能发生越界。3. 工具提示/悬浮窗 某些BI支持鼠标悬停显示明细。如果悬停内容直接查询底层数据库而未应用行级过滤，就会在界面上暴露隐藏数据。解决思路：在BI设计阶段就要明确“每一层数据访问点都必须独立验证用户权限”，不能依赖上一层。
我的最佳实践是： – 禁用所有“跨报表无过滤跳转”，改为通过权限上下文自动传递用户ID。- 对钻取路径进行安全审计：每个钻取动作是否都带了用户标识并重新查用户权限表？- 在测试环境中，用一个只能看到3条记录的账号，尝试钻取到所有可能的下级维度，检查返回的记录数是否超过3。
一个判断原则：如果你的BI平台支持“跳转到其他报表”功能，请务必检查目标报表是否具有独立于来源报表的行级过滤。如果目标报表使用的是共享数据集且没有额外过滤，那么普通员工可以通过精心构造跳转参数看到被封禁的数据。最后，这种“交互式越权”在实际攻击中远比API攻击常见，因为操作门槛低（只需点点鼠标）。
我建议所有BI管理员定期开启“点击流审计日志”，监控异常的钻取行为，比如一个用户频繁钻取到不同维度的最高层级。
读者评论
作为IT负责人，我看了这篇文章冷汗直冒。文中提到的导出越权、API未鉴权、权限漂移，我们公司几乎全中。去年底刚做完权限梳理，以为很安全了，结果用作者的方法用最低权限账号导出报表，真的拿到了超范围数据。现在准备把API token有效期改24小时，按季度做权限审计。这文章不只是理论，是能直接上手检查的实操指南，建议所有BI管理员都测一遍。
我是业务部门的销售总监，平时只看自己的看板，觉得权限设置好了就不会有问题。但文章里说的聚合数据反向推断让我警醒，我们团队就3个人，如果我只看到团队销售额，确实能算出同事的业绩。更可怕的是，离职员工还能通过保存的API地址持续访问数据。看来不能完全信任IT的权限配置，业务侧也得主动提出安全需求。
普通员工视角：说实话我之前根本不知道什么行级权限、API调用，只知道系统让我看什么我就看什么。但看完文章有点后怕，原来我如果懂点技术，可能就能看到HR的工资条或者老板的定价策略。公司可能在安全上花了很多钱，但漏洞却藏在导出和缓存这些不起眼的地方。作为一线用户，我觉得公司应该定期通知我们权限变更，至少离职时确保账号彻底禁用。