Salesforce 字段级安全深度解析：开发人员指南

背景与应用场景

作为一名 Salesforce 开发人员，我们日常工作的核心不仅仅是构建功能强大的应用程序，更重要的是确保这些应用程序的安全性。在 Salesforce 平台提供的多层安全模型中，Field-Level Security (FLS)，即字段级安全，是控制数据访问粒度最精细、也是最常被忽视的一环。它决定了特定用户是否有权限查看或编辑对象上的某个字段，无论这些用户是通过用户界面、API 还是 Apex 代码访问数据。

为什么 FLS 如此重要？想象一个场景：在一家医疗机构的 Salesforce 组织中，销售人员需要看到客户（Patient）的联系方式和预约记录，但绝对不能访问他们的“病史”或“诊断结果”字段。与此同时，医生则需要对这些敏感字段拥有完全的读写权限。如果应用程序在显示或处理数据时忽略了 FLS，就可能导致严重的数据泄露，违反诸如 HIPAA (Health Insurance Portability and Accountability Act) 或 GDPR (General Data Protection Regulation) 等合规性法规，给企业带来巨大的法律和声誉风险。

对于开发人员而言，最大的挑战在于 Salesforce 的一个核心设计：默认情况下，Apex 在“系统模式” (System Mode) 下运行。这意味着 Apex 代码拥有访问所有对象和字段的权限，完全无视运行该代码的用户的 FLS 设置。这种设计赋予了开发人员极大的灵活性，但也带来了一个巨大的安全责任：我们必须在代码中显式地检查和强制执行 FLS，以防止无意中向无权用户暴露或允许其修改敏感数据。本文将从开发人员的视角，深入探讨 FLS 的原理、如何在 Apex 和 SOQL 中正确实施 FLS，以及相关的最佳实践。

---

原理说明

要理解如何在代码中实施 FLS，我们首先需要清晰地了解其工作原理。FLS 是基于 Profile (简档) 和 Permission Set (权限集) 进行配置的。管理员可以为每个简档或权限集，针对特定对象上的每一个字段，设置以下两种访问级别之一：

• Visible (可见): 用户可以读取该字段的值。
• Read-Only (只读): 用户可以读取该字段的值，但不能修改它。如果“Visible”未被勾选，则此选项也无法勾选，因为用户首先需要能看到一个字段才能读取它。

如果一个字段对于某个用户的简档和所有分配给他的权限集都设置为不可见，那么该用户就无法通过任何方式访问这个字段。Salesforce 的标准用户界面（如页面布局、报表、列表视图）会自动遵循 FLS 设置，将无权访问的字段隐藏起来。

然而，当我们编写自定义代码时，情况就变得复杂了。正如前文所述，Apex 默认运行在系统模式下。这意味着，如果一个销售人员运行了一段 Apex 代码，该代码尝试更新他无权编辑的“病史”字段，操作将会成功执行，因为代码是以系统权限运行的，而不是以该销售人员的权限。这显然是一个安全漏洞。

为了解决这个问题，Salesforce 提供了多种机制，让开发人员可以在代码中切换到“用户模式” (User Mode) 的上下文或主动检查权限。主要方法包括：

1. 使用 Schema 方法进行描述性检查: 在执行 DML (Data Manipulation Language) 操作（如 insert, update）或显示数据之前，使用 Apex 的 `Schema` 类动态检查字段的访问权限。
2. 在 SOQL 查询中强制执行 FLS: 使用 `WITH SECURITY_ENFORCED` 子句，让数据库层面在查询时直接强制执行字段和对象级别的安全检查。
3. 使用 `Security.stripInaccessible` 方法: 在 DML 操作之前，使用此方法安全地从 SObject 列表中移除当前用户无权访问的字段。

接下来，我们将通过具体的代码示例来演示如何应用这些技术。

---

示例代码

以下示例将展示作为一名开发人员，如何负责任地在代码中处理 FLS。

方法一：在 DML 操作前使用 Schema 方法检查 FLS

这是最经典和最灵活的方法。在更新记录之前，我们可以遍历需要更新的字段，并检查当前用户是否具有对这些字段的更新权限（`isUpdateable()`）。同样，在读取并显示数据之前，应该检查 `isAccessible()`。

// 假设我们有一个方法，用于更新联系人的姓氏和部门
// 我们必须确保运行此代码的用户有权更新这两个字段

public static void updateContactDetails(Id contactId, String newLastName, String newDepartment) {
    // 1. 获取 Contact 对象的 SObjectType Describe Result
    // Schema.SObjectType.Contact 提供了对 Contact 对象元数据的访问
    Schema.DescribeSObjectResult contactDescribe = Schema.SObjectType.Contact.getDescribe();

    // 2. 获取字段的 Map，键是字段名，值是字段的 token
    Map<String, Schema.SObjectField> fieldMap = contactDescribe.fields.getMap();

    // 3. 检查用户是否对 LastName 字段有更新权限
    Boolean hasLastNameUpdateAccess = fieldMap.get('LastName').getDescribe().isUpdateable();
    // 4. 检查用户是否对 Department 字段有更新权限
    Boolean hasDepartmentUpdateAccess = fieldMap.get('Department').getDescribe().isUpdateable();

    if (!hasLastNameUpdateAccess || !hasDepartmentUpdateAccess) {
        // 如果用户缺少任一字段的更新权限，则抛出异常或进行优雅处理
        // 这样可以防止非法数据更新，并向用户提供明确的反馈
        throw new SecurityException('You do not have permission to update one or more of the required fields.');
    }

    // 5. 只有在权限检查通过后，才执行 DML 操作
    try {
        Contact c = new Contact(
            Id = contactId,
            LastName = newLastName,
            Department = newDepartment
        );
        update c;
    } catch (DmlException e) {
        // 处理其他可能发生的 DML 异常
        System.debug('An error occurred during DML operation: ' + e.getMessage());
    }
}

注释说明：

此方法的核心是使用 `getDescribe()` 方法获取对象和字段的元数据信息，然后调用 `isUpdateable()`、`isCreatable()` 或 `isAccessible()` 等权限检查方法。虽然代码量稍多，但它提供了最精细的控制，允许我们针对不同字段进行不同的逻辑处理。

方法二：在 SOQL 查询中使用 `WITH SECURITY_ENFORCED`

从 API 版本 48.0 开始，Salesforce 引入了一个非常强大的功能：`WITH SECURITY_ENFORCED` 子句。将其添加到 SOQL 查询语句中，Salesforce 会自动在执行查询时检查当前用户对查询中所有字段的 FLS 可见性。如果用户对任何一个字段没有读取权限，查询将直接抛出一个 `System.QueryException` 异常，而不会返回任何数据。

// 假设我们需要查询客户的名称、年度收入和所有者邮箱
// 我们希望确保用户只能看到他们有权查看的字段

public static List<Account> getSecureAccounts() {
    List<Account> accounts;
    try {
        // 在 SOQL 查询语句末尾添加 WITH SECURITY_ENFORCED
        // Salesforce 会自动检查 Name, AnnualRevenue, Owner.Email 这三个字段的 FLS
        accounts = [
            SELECT Name, AnnualRevenue, Owner.Email
            FROM Account
            WHERE AnnualRevenue > 1000000
            WITH SECURITY_ENFORCED
        ];
    } catch (System.QueryException e) {
        // 如果用户对 Name, AnnualRevenue 或 Owner.Email 中任何一个字段没有读取权限，
        // 查询将失败并进入 catch 块
        System.debug('Security exception: The user does not have permission to view one or more fields. ' + e.getMessage());
        // 在实际应用中，这里应该进行更友好的错误处理，比如向用户界面返回一条提示信息
        accounts = new List<Account>(); // 返回一个空列表以避免后续代码出错
    }
    return accounts;
}

注释说明：

这种方法极大地简化了读取操作的安全性检查。开发人员不再需要手动进行 `Schema` 描述调用，只需添加一个子句即可。这使得代码更简洁、更易于维护，并成为当前推荐的最佳实践。

方法三：使用 `Security.stripInaccessible` 清理数据

在进行 DML 更新或插入操作前，如果 SObject 实例中包含了用户无权访问的字段，操作会失败。`Security.stripInaccessible` 方法可以智能地移除这些字段，确保 DML 操作能够安全地执行。

// 假设我们从一个外部系统接收到一个 Contact 对象列表，准备插入或更新
// 我们不确定当前用户是否有权访问列表中的所有字段

public static void processContacts(List<Contact> receivedContacts) {
    // 1. 在执行 DML 之前，使用 stripInaccessible 方法
    // 这个方法需要两个参数：访问检查类型（如 UPDATABLE, CREATABLE, ACCESSIBLE）和 SObject 列表
    // 它会返回一个 SObjectAccessDecision 对象，其中包含了安全处理后的记录列表
    SObjectAccessDecision decision = Security.stripInaccessible(
        AccessType.UPDATABLE,
        receivedContacts
    );

    // 2. 获取移除了无权更新字段的记录列表
    List<Contact> contactsToUpdate = (List<Contact>)decision.getRecords();

    // 3. (可选) 检查哪些字段被移除了
    Set<String> removedFields = decision.getRemovedFields().get('Contact');
    if (removedFields != null && !removedFields.isEmpty()) {
        System.debug('The following fields were removed due to FLS: ' + removedFields);
    }
    
    // 4. 执行 DML 操作，此时 contactsToUpdate 列表是安全的
    if (!contactsToUpdate.isEmpty()) {
        update contactsToUpdate;
    }
}

注释说明：

`stripInaccessible` 是一个非常实用的工具，特别是在处理动态构建的 SObject 或来自不受信任来源的数据时。它自动完成了繁琐的字段权限检查和移除工作，有效防止了因权限不足导致的 DML 失败。

---

注意事项

作为开发人员，在处理 FLS 时，必须牢记以下几点：

• Apex 的系统模式: 永远不要忘记 Apex 默认绕过 FLS。安全不是平台自动提供的，而是需要我们开发人员主动去实现的责任。
• `WITH SECURITY_ENFORCED` 的局限性: 这个子句非常强大，但它只检查 `SELECT` 子句中列出的字段。它不会检查 `WHERE` 或 `ORDER BY` 子句中的字段。例如，即使用户看不到 `AnnualRevenue` 字段，`... WHERE AnnualRevenue > 5000` 这样的查询在 `WITH SECURITY_ENFORCED` 下仍然会基于该字段进行过滤，只是该字段的值不会被返回。
• 异常处理: 当使用 `WITH SECURITY_ENFORCED` 时，必须将查询放在 `try-catch` 块中，以捕获可能因权限不足而抛出的 `QueryException`。否则，整个事务将会因为一个未处理的异常而失败。
• 性能考量: 大量地调用 `Schema.getDescribe()` 会消耗系统资源并对性能产生一定影响，尤其是在循环中。应避免在 `for` 循环内部重复进行描述调用。可以将描述结果缓存到一个静态变量中，或在循环开始前获取所有需要的描述信息。
• 复合字段和多态字段: 在处理地址（Address）等复合字段或所有者（Owner）等多态字段时，需要特别注意 FLS 的检查方式。你需要检查构成复合字段的每个单独字段的权限。
• 不仅仅是 Apex: FLS 的强制执行也同样适用于 Visualforce 控制器和 Lightning 控制器（Aura/LWC）中与 Apex 的交互。虽然标准的 UI 组件（如 ``）会自动处理 FLS，但只要你通过 Apex 控制器自定义数据处理逻辑，就必须手动实施 FLS 检查。

---

总结与最佳实践

正确处理 Field-Level Security 是构建安全、可靠的 Salesforce 应用程序的基石。对于我们开发人员来说，这不仅是一项技术要求，更是一种职业责任。忽略 FLS 可能会导致应用程序在功能上看似完美，实则存在巨大的安全隐患。

总结我们的最佳实践：

1. 优先使用 `WITH SECURITY_ENFORCED` 进行数据查询

   对于所有只读操作，这应该是你的首选方案。它简洁、高效，并将安全责任转移到了 Salesforce 平台层面。

2. 在 DML 操作前进行权限检查

   对于写入操作（insert, update, upsert），使用 `Security.stripInaccessible` 清理数据，或使用 `Schema` 方法进行显式检查。前者更适用于动态场景，后者提供了更精细的控制。

3. 构建可重用的安全工具类 (Utility Class)

   将 FLS 检查逻辑封装到一个集中的 `SecurityUtils` 类中。这样可以避免在代码库中重复编写相同的检查逻辑，提高代码的可维护性和一致性。

4. 始终进行全面的错误处理

   当安全检查失败时，应向用户提供清晰、有意义的反馈，而不是让程序崩溃或静默失败。优雅地捕获异常并转化为用户可理解的提示信息。

5. 结合 Apex 扫描工具

   使用 Salesforce Code Analyzer 或 Checkmarx 等静态代码分析工具，它们可以自动扫描你的 Apex 代码，找出潜在的 FLS 漏洞，作为你安全开发流程的一部分。

通过将这些实践融入到你的日常开发流程中，你不仅能交付满足业务需求的功能，更能构建一个让客户和管理员都信赖的安全、合规的系统。记住，在 Salesforce 开发中，安全永远不是事后的补充，而是在编写第一行代码时就应考虑的核心要素。