限制规则 Restrict Rule

Restrict Rule

前言

19年当时在埃森哲，公司接了一个SFDC项目需要人，就组织让我们转SFDC。
我考了Admin，App Builder， Develop I就进项目开始干了。公司开始还请了一个SFDC讲师讲了两天，建立了一个整体的印象，我记得最清楚的一句话：Salesforce只有加权限一说，没有减权限。在考虑权限设计时候要遵循最小权限原则，再一步步根据需要给用户加权限。
没想到今天这个话要变了，面试时候就问了能否限制用户权限，我自信的说限制不了，只能加权限不能减权限。设计时候就必须考虑好，所有人给最小权限。
面试官告诉我可以用 Restrict Rule，我心想这是什么玩意。但是听名字好像就是用来限制的。调查后记录一下。

限制规则

作为Salesforce从业人员，数据的权限管理是一个特别重要的内容。我们熟知的设置权限的方式就是先设置 OWD进行一下 high level的设置。然后通过 Role Hierarchy / Share Rule / Manual Share进行数据权限的扩充从而达到不同的场景下，不同的USER可以扩充他可以看到的数据范围。

限制规则允许您通过允许特定用户访问指定的记录来增强安全性。它们阻止用户访问可能包含敏感数据或与工作无关信息的记录。限制规则会过滤用户可访问的记录，使其只能访问符合你指定条件的记录。
限制规则仅适用于自定义对象、外部对象、报价、合同、事件、任务、工时表和工时表条目。在企业版和开发者版中，每个对象最多可创建两个活跃限制规则，在性能版和无限版中每个对象最多可创建五个活跃限制规则。
限制规则适用于以下 Salesforce 功能：Links 链接、List Views 列表视图、Lookups 查询、Records 纪录、Related Lists 相关列表、Reports 报告、Search 搜索、SOQL、SOSL

当用户被应用限制规则时，用户通过组织默认设置、共享规则及其他共享机制获得访问权限的记录会根据你指定的标准进行过滤。
例如，如果用户访问“今日任务”标签页或活动列表视图，他们只看到符合限制规则条件的记录。如果用户有链接到在限制规则应用后无法访问的记录，用户会看到错误信息。

它的作用是：对符合条件的用户，把他们能看到的记录限制在指定范围内，即使共享模型本身允许他们看到更多记录。

工作方式
用户条件：指定哪些用户受规则约束，例如某个字段等于特定值的用户。
记录条件：指定这些用户只能访问哪些记录，例如某个字段满足条件的记录。
最终访问 = 共享模型允许的范围 且 限制规则允许的范围。限制规则只会收窄访问，不会扩大访问。

典型场景是合规要求，比如某些地区或业务线的员工只能访问本区域的客户数据，即使他们因为角色层级或共享规则能看到更多记录。

需要注意的点

适用对象和版本有限制：并非所有标准对象都支持，具体需要查看你所在 org 的版本和许可证。
系统权限会绕过规则：拥有 View All Data 或 Modify All Data 的用户通常不受影响，所以不能把它当作绝对的安全边界，管理员权限需要单独管控。
对集成的影响：如果集成用户属于受限制的用户群体，它的 API 查询结果也会被收窄，设计集成时需要确认集成用户是否在规则范围内。
与 Scoping Rules 的区别：Scoping Rules 主要收窄列表视图和搜索结果中显示的记录，用于减少干扰，不是访问控制。两者目的不同，不要混用。
Apex 的行为：with sharing 的类会遵守限制规则，without sharing 则不会，这一点在设计 Apex REST 接口时要注意。

我的看法

虽然有这种功能了，但我还是保留我的观点，限制规则像一个补丁。
默认只增不减的模型更容易推理，也更利于设计期做好权限规划。

只增不减的优点
权限计算简单：要判断某人能看什么，只需要把 OWD、角色、共享规则、手动共享的结果取并集，不用再减去一层。
设计阶段倒逼最小权限：OWD 设为 Private，只开放必要的共享，比先放开再回收更安全，也更符合最小权限原则。
性能和排查更好：共享计算的路径更清晰，出问题时更容易定位是哪条规则授予了访问。
维护成本低：权限变更只会扩大，不会出现"某个限制规则把别的规则覆盖掉"的隐性冲突。
Restriction Rules 的定位
它的价值在于补救，而不是常规设计手段。适合的情况包括：

历史遗留的 org 中已经存在过度共享，短期内无法重构共享模型。
合规要求明确限定了数据可见范围（如按地区、业务线隔离），而且这个限制必须由平台强制执行。

如果是新设计，我觉得还是应该先用 OWD、角色层级、共享规则和权限集把边界画清楚，只在确实必要时才引入限制规则。

需要额外注意的一点

只增不减的前提是设计者能穷尽所有授予路径。实际项目中，权限往往会随着时间不断叠加：某个临时的共享规则没有删除，某个角色被调整了层级，某个权限集被误加给了不该拥有的人。
这时候仅靠"设计之初做对"很难保证长期正确，所以需要配套的定期权限审计，例如用 Permission Set 报告、Org Health 或第三方工具检查有效访问。

所以我的建议是：以只增不减为基本原则，把设计和审计做扎实，限制规则作为兜底手段保留，但不作为常规模式使用。

Source：限制规则 |Salesforce 帮助 --- Restriction Rules | Salesforce Help