如果你以前在 Power BI 里配过行级安全（RLS），一定熟悉这套流程：打开语义模型 → 添加角色 → 写 DAX 过滤表达式。一个模型还好，但当你手上有多个报表、多个语义模型、还有 SQL 分析端点时，同一个安全规则要在不同地方反复配置，改一次就要全部重来一遍。
现在数据都进了 Fabric OneLake，其实有个更省事的做法：把安全规则直接定义在 OneLake 上游，让下游所有对象自动继承。
这就是 OneLake Security。定义一次，lakehouse、SQL 分析端点、语义模型、报表全都跟着走，不用再逐层配置。
什么是 OneLake Security
简单说，就是把行级安全的过滤逻辑从 Power BI 语义模型里「上移」到 OneLake 层。
数据存在 OneLake 里，任何基于它构建的对象——lakehouse、SQL 分析端点、语义模型、报表——都会自动遵循同一套安全配置。
对团队协作来说，这一点很关键：SQL 开发者、自助式 Power BI 用户、最终查看报表的业务人员，全部处在同一套受管控的安全体系下。
先回顾一下 RLS
行级安全就是让每个用户只看到属于自己的那部分数据。加州销售经理只看加州的销售数据，其他州的经理看自己州的数据，以此类推。
传统做法是在 Power BI 语义模型里配置，分静态和动态两种。静态适合固定人员，动态适合用户量大、需要按登录身份自动过滤的场景。
问题在于，一旦数据架构分层，安全配置也要跟着分层。同一个规则在语义模型里配一遍，在 SQL 端点里可能还要再配一遍，维护成本高，还容易漏配。
OneLake Security 解决的正是这个重复劳动的问题。
前置条件
要启用 OneLake Security，需要满足几个条件：
- 这是 Fabric 专属能力，数据必须放在 Fabric lakehouse 中
- 需要一个关联了 Fabric 容量的工作区
- 容量大小无所谓，F2、F4、F64 都一样支持，不挑 SKU
原文示例中，lakehouse 包含四张关联表：Customer、Geography、Product 和 Fact Internet Sales，通过 SQL 分析端点进行查询。
配置流程概览
整体思路是从上游到下游打通：
- 在 OneLake 层定义安全规则，指定过滤条件（比如按地区、按部门）
- 规则自动向下传递，lakehouse 和 SQL 分析端点直接生效
- 语义模型继承安全配置，不需要在模型里重复写 DAX 角色
- 报表端自动遵循，最终用户看到的数据范围由上游规则决定
这样带来的好处是：安全逻辑只有一份，改一处，全链路生效。
国内用户怎么看
对于已经上了 Fabric 的团队，OneLake Security 确实能省掉不少重复配置的工作量，尤其是数据团队和 BI 团队分开协作的场景，安全规则由数据平台统一管控，BI 侧不用再操心。
不过也要注意，目前国内 Fabric 的落地还在推进中，如果还在用 Power BI 独立版或本地部署，这套方案暂时用不上，还是得在语义模型里配 RLS。另外，把安全规则上移到 OneLake 后，权限管理的职责边界会发生变化，建议提前和 IT 安全团队对齐，避免出现「谁负责维护规则」的模糊地带。
总的来说，这是一个值得关注的方向：安全配置从「每层各管各的」走向「上游统一定义、下游自动继承」，随着 Fabric 生态成熟，这类能力会越来越实用。
