深入解析 Salesforce 事务安全策略以增强组织安全

背景与应用场景

作为一名 Salesforce 管理员，我们日常工作的核心之一就是保护公司最有价值的资产——数据。我们通过精细地配置简档 (Profiles)、权限集 (Permission Sets) 和组织范围默认设置 (Organization-Wide Defaults) 来构建坚实的安全基础。然而，这些传统的安全模型主要关注“谁能访问什么”，属于静态的、基于身份的访问控制。在当今复杂多变的安全环境下，我们还需要回答一个更深层次的问题：“用户正在用他们的数据访问权限做什么？”

这就是 Transaction Security Policies (事务安全策略) 发挥巨大价值的地方。它是 Salesforce Shield 这一高级安全产品套件的一部分，但 Salesforce 也为所有 Enterprise, Performance, Unlimited, 和 Developer Edition 的组织免费提供了创建最多两条事务安全策略的功能。这项功能使我们能够实时监控和拦截 Salesforce 中的用户活动（即“事务”），并根据预设的条件自动执行相应的操作，从而实现动态的、基于行为的风险控制。

试想以下几个常见的安全挑战：

数据大规模泄露风险：一名即将离职的销售人员，试图一次性导出包含数万条客户联系信息的报告。我们如何能及时发现并阻止这种行为，而不是在事后才发现数据已经外泄？

可疑的登录行为：

敏感数据的非授权访问：

事务安全策略正是为了解决这类问题而设计的。它将我们的安全防护从“预防性”的静态配置，提升到了“响应式”的实时监控层面，为 Salesforce 组织增加了一道至关重要的动态防线。

原理说明

要理解事务安全策略的工作原理，我们需要了解其三大核心组件：Events (事件)、Policies (策略) 和 Actions (操作)。

1. Events (事件)

事件是用户在 Salesforce 中执行的特定操作。事务安全策略监控的是一系列预定义的实时事件对象 (Real-Time Event Monitoring Objects)。每个事件对象都包含了该操作的详细上下文信息。例如：

ReportEvent: 当用户执行报告操作时触发，如导出或查看报告。它包含了执行操作的用户 ID、报告 ID、处理的行数 (`RowsProcessed`) 等关键信息。
ApiEvent: 当通过 API 进行查询时触发。它包含了被查询的对象 (`QueriedEntities`)、执行的 SOQL 语句、客户端 IP 地址等。
LoginEvent: 用户登录时触发。包含了登录的地理位置信息、使用的浏览器、IP 地址等。
ListViewEvent: 用户访问列表视图时触发，记录了访问的范围、对象等。

管理员需要首先确定希望监控哪种类型的用户行为，然后选择对应的事件作为策略的触发器。

2. Policies (策略)

策略是定义“什么情况下触发响应”的规则集合。它评估来自事件的数据，如果满足特定条件，则触发相应的操作。创建策略主要有两种方式：

Condition Builder (条件生成器): 这是声明式工具，允许管理员通过点击式界面创建简单的规则，无需编写代码。例如，您可以轻松创建一个规则：“当 ReportEvent 的 RowsProcessed 大于 2000 时”。这对于快速部署常见的安全场景非常有效。
Apex: 对于更复杂的、需要自定义逻辑的场景，我们可以使用 Apex 编写一个实现了 `TxnSecurity.PolicyCondition` 接口的类。这提供了极大的灵活性，比如可以查询其他对象的数据、调用外部服务、或者实现复杂的业务逻辑来判断当前事件是否构成安全风险。例如，判断一个 API 查询是否包含了多个敏感对象的组合。

3. Actions (操作)

当策略的条件被满足时，系统会执行预定义的操作。主要有以下几种操作：

Block: 直接阻止用户的操作。例如，如果用户尝试导出超过规定行数的报告，操作将被立即中止，用户会看到一条错误消息。
Freeze User: 冻结用户账户，阻止其进一步访问系统，需要管理员手动解冻。
Two-Factor Authentication (多因素认证): 不阻止操作，但要求用户在继续之前完成多因素认证流程。这对于可疑登录或访问敏感资源等场景非常有用，既保证了安全又不会完全中断正常工作流程。
End Session: 结束当前用户的会话，强制其重新登录。
No Action (仅通知): 不对用户操作进行任何干预，但会发送一封电子邮件或应用内通知给指定的管理员或负责人。这适用于需要监控但暂时不想影响用户体验的“审计”类场景。

通过组合这三个组件，一个完整的事务安全策略流程就形成了：事件发生 → 策略评估条件 → 条件满足 → 执行操作。这个流程是实时发生的，确保了安全响应的即时性。

示例代码

让我们来看一个经典的场景：阻止用户一次性导出超过 2,000 行数据的报告。虽然这个场景可以通过条件生成器实现，但使用 Apex 作为示例更能展示其强大的自定义能力。以下是一个实现 `TxnSecurity.PolicyCondition` 接口的 Apex 类，其代码严格遵循 Salesforce 官方文档。

这个策略会检查 `ReportEvent` 事件，并判断其 `RowsProcessed` 字段是否超过了设定的阈值。

Apex Policy Condition: BlockLargeReportExport

global class BlockLargeReportExport implements TxnSecurity.PolicyCondition {

    /**
     * @description This method is invoked when a transaction security policy is triggered.
     * @param event The event that triggered the policy, which contains contextual information.
     * @return Boolean Returns true if the policy conditions are met, otherwise false.
     */
    public boolean evaluate(TxnSecurity.Event event) {
        // 在此处编写我们的核心逻辑
        // 首先，获取触发事件的底层SObject记录，以便访问其字段
        // 对于ReportEvent，底层SObject是ReportEventStore
        SObject sObj = event.getSObject();
        
        // 从事件中获取处理的行数。这是最关键的判断依据。
        // 使用 get() 方法可以动态获取字段值，避免编译时依赖
        Decimal rowsProcessed = (Decimal)sObj.get('RowsProcessed');
        
        // 从事件中获取执行该操作的用户的信息
        // 这对于后续获取用户简档或角色等信息非常有用
        String userId = event.UserId;
        User user = [SELECT Id, Profile.Name FROM User WHERE Id = :userId];
        
        // 设定我们的安全阈值
        Integer rowLimit = 2000;
        
        // 设定一个例外规则：允许具有“系统管理员”简档的用户不受此限制
        // 这增加了策略的灵活性，避免阻塞管理员的正常工作
        String adminProfileName = 'System Administrator';

        // 开始评估条件
        // 条件1: 检查导出/查看的报告行数是否超过阈值
        // 条件2: 检查执行操作的用户是否不是系统管理员
        if (rowsProcessed > rowLimit && user.Profile.Name != adminProfileName) {
            // 如果两个条件都满足，则返回true，表示策略应被触发
            return true;
        }
        
        // 如果不满足条件，则返回false，操作将正常继续
        return false;
    }
}

代码注释说明：

`global class ... implements TxnSecurity.PolicyCondition`: 这是定义一个事务安全策略 Apex 条件类的标准语法。类必须是 `global` 的，并且实现 `TxnSecurity.PolicyCondition` 接口。
`evaluate(TxnSecurity.Event event)`: 这是接口要求实现的唯一方法。当关联的事件发生时，Salesforce 会调用这个方法，并将事件的详细信息作为 `TxnSecurity.Event` 对象传入。
`event.getSObject()`: 这个方法返回一个通用的 `SObject` 对象，它代表了具体的事件记录（如 `ReportEvent` 或 `ApiEvent`）。通过这个对象，我们可以访问事件的特定字段。
`sObj.get('RowsProcessed')`: 我们从 `SObject` 中获取 `RowsProcessed` 字段的值。这个字段记录了报告操作所涉及的数据行数。
`[SELECT ... FROM User ...]`: 在 Apex 条件中，我们可以执行 SOQL 查询来获取额外的信息。这里我们查询了执行操作的用户的简档信息，以便创建豁免规则。请注意：在策略中执行 SOQL 会增加事务的执行时间，必须确保查询是高效且经过优化的。
`return true;`: 当 `evaluate` 方法返回 `true` 时，意味着“风险已确认”，策略配置的操作（如 Block）将被执行。
`return false;`: 当返回 `false` 时，意味着“操作安全”，用户的行为将不受影响，正常继续。

编写完这个 Apex 类后，管理员需要在“设置”中的“事务安全策略”页面创建一个新策略，选择 `ReportEvent` 作为事件，然后选择“Apex”作为条件类型，并指定我们刚刚创建的 `BlockLargeReportExport` 类。最后，将操作设置为“阻止”，即可完成部署。

注意事项

在实施事务安全策略时，作为管理员，我们需要仔细考虑以下几点：

性能影响: 事务安全策略是同步执行的，这意味着它们会在用户操作的事务中运行。一个设计不佳、逻辑复杂或包含低效 SOQL 查询的 Apex 策略，可能会明显拖慢用户操作的响应速度，影响用户体验。因此，策略逻辑应尽可能简洁高效。
许可要求: 事务安全策略是 Salesforce Shield 的一部分。购买 Shield 许可后，可以创建的策略数量会更多。如果没有购买 Shield，每个组织也免费享有创建最多两条活动策略的权利。这对于满足最核心的安全需求非常有帮助。
Governor Limits (治理限制): Apex 策略同样受到 Salesforce 的 Apex 治理限制的约束，例如 SOQL 查询数量、CPU 时间等。如果策略逻辑过于复杂，可能会触及这些限制，导致策略执行失败，用户的操作也可能因此失败。
全面测试: 绝对不要在没有经过充分测试的情况下，在生产环境中激活一个“阻止”操作的策略。务必在 Sandbox 环境中，针对各种用户简档和场景进行详尽的测试，确保它只阻止了预期的恶意行为，而不会影响正常的业务流程。错误的策略可能会导致关键业务中断。
用户沟通: 如果您部署了会阻止用户操作的策略，请务信必提前与用户进行沟通，并提供清晰的错误提示信息。让用户知道为什么他们的操作被阻止，以及在需要时应该联系谁来获取帮助。
事件覆盖范围: 并非 Salesforce 中的所有操作都有对应的实时事件。在设计策略前，请查阅官方文档，确认您想要监控的操作是否在支持的事件列表之中。

总结与最佳实践

Transaction Security Policies 为 Salesforce 管理员提供了一个强大而灵活的工具，它将我们的安全防护能力从静态的权限配置提升到了动态、实时的行为监控。通过合理利用这项功能，我们可以主动防御数据泄露、账户盗用和内部滥用等多种安全威胁。

以下是一些最佳实践建议：

从小处着手: 从最关键、最明确的安全风险开始，例如大规模数据导出或来自不信任 IP 的登录。先用“仅通知”模式运行策略，观察其触发情况，确认没有误报后再切换到“阻止”或“多因素认证”等强制性操作。
优先使用声明式工具: 对于简单的逻辑，优先使用条件生成器。它更易于维护，且性能开销通常低于 Apex。只有在需要复杂逻辑、外部查询或自定义判断时，才选择 Apex。

代码保持高效:

建立清晰的警报和响应流程:

定期审查和调整:

总之，事务安全策略是每位负责任的 Salesforce 管理员都应该了解和掌握的高级安全工具。它赋予了我们洞察和控制用户实时行为的能力，是守护组织数据安全的又一重坚固铠甲。

Salesforce Einstein AI 编程实践：开发者视角下的智能预测

九月 15, 2025

阅读全文

Salesforce中文网