精通 Salesforce 字段级安全性：开发者综合指南

背景与应用场景

作为一名 Salesforce 开发人员，我们日常工作的核心不仅仅是构建功能强大的应用程序，更重要的是确保这些应用程序的安全性。在 Salesforce 平台提供的多层安全模型中，Field-Level Security (FLS)，即字段级安全性，是最基本也是最关键的一环。它决定了用户是否可以查看或编辑对象上的特定字段。

想象一个常见的业务场景：在一家公司的销售流程中，“Opportunity”（业务机会）对象上有一个名为 'Discount_Percentage__c' 的自定义字段，用于记录给予客户的折扣率。业务要求如下：

销售代表（Sales Rep）可以创建和编辑业务机会的大部分字段，但只能查看折扣率，不能修改。
销售经理（Sales Manager）不仅可以查看，还可以编辑折扣率，以批准或调整折扣。
财务部门的用户（Finance User）在业务机会关闭后需要审计数据，他们对所有字段都只有只读权限。

如果不实施 FLS，所有用户都可能看到并修改这个敏感字段，从而导致数据不一致、未经授权的折扣以及潜在的财务风险。FLS 允许管理员通过 Profile (简档) 和 Permission Set (权限集) 精确地控制每个字段的“可见”和“只读”状态，从而满足复杂的业务需求。

然而，对于我们开发者而言，一个常见的误区是认为管理员在界面上配置好的 FLS 会自动在我们的 Apex 代码中生效。事实并非如此！默认情况下，Apex 在“系统模式” (System Mode) 下运行，它会忽略 FLS 和对象级权限。这意味着，如果不采取额外措施，我们编写的 Apex 代码可能会无意中暴露或修改用户本无权访问的字段，从而打开严重的安全漏洞。因此，理解并以编程方式强制执行 FLS，是我们作为开发者不可推卸的责任。

原理说明

FLS 的核心原理是为每个字段、每个用户简档或权限集定义访问级别。这些级别通常是“无权限”、“可见”（只读）和“可编辑”（读写）。当用户通过标准 UI（如记录页面、报表）与数据交互时，Salesforce 平台会自动强制执行这些设置。

然而，当代码执行进入 Apex 领域时，情况就变得复杂了。我们需要主动在代码中“请求”平台检查并强制执行 FLS。Salesforce 提供了多种强大的工具来帮助我们实现这一目标：

1. SOQL 中的 `WITH SECURITY_ENFORCED` 子句

这是在数据查询阶段强制执行 FLS 和对象级权限的最直接、最现代的方法。当你在 SOQL 查询中加入此子句时，如果查询的任何字段或对象是当前用户根据其简档和权限集无权访问的，查询将不会返回结果，而是会立即抛出一个 System.QueryException 异常。这是一种“全有或全无”的强制执行模式，非常适合需要严格安全性的场景。

2. Schema Describe 方法

当需要更精细、更动态的权限检查时，我们可以利用 Salesforce 的 Schema 命名空间。通过 DescribeSObjectResult 和 DescribeFieldResult 类，我们可以在代码运行时检查任何字段的访问权限。关键方法包括：

isAccessible(): 检查当前用户是否对字段有读取权限。
isCreateable(): 检查当前用户是否可以在创建记录时为该字段赋值。
isUpdateable(): 检查当前用户是否可以更新现有记录上的该字段。

这种方法非常灵活，允许我们根据用户的权限动态地构建 SOQL 查询、在页面上显示/隐藏字段或决定是否执行 DML (Data Manipulation Language，数据操作语言) 操作。

3. `Security.stripInaccessible()` 方法

在执行 DML 操作（如 insert 或 update）之前，我们需要确保不会写入用户无权编辑的字段。Security.stripInaccessible 方法是解决这个问题的完美工具。它会接收一个 sObject 列表和期望的访问级别（如 AccessType.UPDATABLE），然后返回一个“净化”过的新 sObject 列表，其中所有用户无权访问的字段都已被自动移除。这样，我们就可以安全地执行 DML 操作，而不必担心会因 FLS 冲突而导致异常。

这三种机制共同构成了开发者强制执行 FLS 的“三驾马车”，让我们能够编写出既功能强大又安全可靠的代码。

示例代码

以下示例均基于 Salesforce 官方文档，展示了如何在 Apex 代码中正确处理 FLS。

示例 1: 使用 `WITH SECURITY_ENFORCED` 进行安全查询

假设我们要查询联系人的姓名和电话，但需要确保运行代码的用户对这些字段拥有访问权限。

// 这是一个在 AuraEnabled 方法中的示例，该上下文通常在用户模式下运行
// 我们需要确保查询操作尊重用户的 FLS
public static List<Contact> getContacts() {
    List<Contact> contacts;
    try {
        // 在 SOQL 查询中添加 WITH SECURITY_ENFORCED
        // 如果当前用户无权访问 Id, Name, 或 Phone 字段中的任何一个，
        // 这行代码将抛出 System.QueryException，而不是返回部分数据。
        contacts = [SELECT Id, Name, Phone FROM Contact WITH SECURITY_ENFORCED];
    } catch (System.QueryException e) {
        // 优雅地处理异常
        // 例如，记录错误日志，并向用户显示一条友好的错误消息
        System.debug('FLS 或对象级权限检查失败: ' + e.getMessage());
        // 可以选择抛出一个自定义的 AuraHandledException 来通知前端组件
        throw new AuraHandledException('您没有权限查看联系人信息。');
    }
    return contacts;
}

详细注释: 这个例子展示了 `WITH SECURITY_ENFORCED` 的基本用法。关键在于 `try-catch` 块。我们必须预料到查询可能会因为权限不足而失败，并捕获 `QueryException`，以防止整个事务失败并向用户提供清晰的反馈。

示例 2: 使用 Schema Describe 方法动态检查字段权限

在某些情况下，我们需要在执行 DML 之前动态地检查字段是否可更新。例如，一个通用组件需要更新传入的任意 sObject。

// 此方法尝试更新 Opportunity 上的 StageName 和 Amount 字段
public static void updateOpportunity(Id oppId, String newStage, Decimal newAmount) {
    // 首先，获取 Opportunity 字段的描述信息 Map
    Map<String, Schema.SObjectField> fieldMap = Schema.SObjectType.Opportunity.fields.getMap();

    // 检查用户是否对 StageName 字段有更新权限
    if (!fieldMap.get('StageName').getDescribe().isUpdateable()) {
        // 如果没有权限，则抛出异常或进行其他处理
        throw new SecurityException('当前用户无权更新业务机会的阶段 (StageName) 字段。');
    }

    // 同样，检查 Amount 字段的更新权限
    if (!fieldMap.get('Amount').getDescribe().isUpdateable()) {
        throw new SecurityException('当前用户无权更新业务机会的金额 (Amount) 字段。');
    }

    // 只有在所有权限检查都通过后，才执行 DML 操作
    Opportunity oppToUpdate = new Opportunity(
        Id = oppId,
        StageName = newStage,
        Amount = newAmount
    );
    update oppToUpdate;
    System.debug('业务机会已成功更新。');
}

详细注释: 此方法在执行 DML 之前，先通过 `Schema.SObjectType.Opportunity.fields.getMap()` 获取字段元数据，然后逐个调用 `isUpdateable()` 进行检查。这种方式提供了非常精细的控制，允许我们针对不同字段提供不同的错误信息，但代码会相对冗长。

示例 3: 使用 `Security.stripInaccessible()` 清理 DML 数据

这是处理 DML 权限的最佳实践，因为它比手动检查更简洁、更高效，特别是当需要处理大量字段或 sObject 列表时。

public static void safeUpdateAccounts(List<Account> accountsToUpdate) {
    // 在执行 DML 之前，我们需要移除用户无权更新的字段。
    // AccessType.UPDATABLE 指定了我们关心的权限级别。
    // sObjects.stripInaccessible 方法会检查 FLS，并返回一个安全的 sObject 列表副本。
    // 注意：原始的 accountsToUpdate 列表不会被修改。
    SObjectAccessDecision decision = Security.stripInaccessible(
        AccessType.UPDATABLE,
        accountsToUpdate);

    // 从决策对象中获取净化后的记录列表
    List<Account> sanitizedAccounts = (List<Account>)decision.getRecords();

    // 现在可以安全地执行 DML 操作了
    // 即使用户传入了他们无权编辑的字段（例如 AnnualRevenue），
    // 这些字段也已经被从 sanitizedAccounts 中移除了，因此 update 操作不会失败。
    try {
        update sanitizedAccounts;
    } catch (DmlException e) {
        // 处理其他可能的 DML 异常（如验证规则失败）
        System.debug('DML 操作失败: ' + e.getMessage());
        throw e;
    }

    // 打印出被移除的字段，用于调试或记录
    for (String fieldName : decision.getRemovedFields().keySet()) {
        System.debug('字段 ' + fieldName + ' 因 FLS 限制被移除。');
    }
}

详细注释: `Security.stripInaccessible` 是一个非常强大的工具。它不仅返回了净化后的记录，还通过 `SObjectAccessDecision` 对象提供了额外的信息，比如哪些字段因为权限问题被移除了。这使得代码既安全又易于维护，是处理 DML 安全性的首选方案。

注意事项

API 版本: WITH SECURITY_ENFORCED 是在 API v48.0 中引入的，而 Security.stripInaccessible 是在 API v45.0 中引入的。在为旧版本的 Org 或代码编写时，请确保检查 API 兼容性。如果版本过低，你将不得不回退到使用 Schema Describe 手动检查。
性能考虑: 反复调用 Schema Describe 方法（尤其是在循环中）可能会消耗大量 CPU 时间。如果需要对同一对象的字段进行多次检查，最佳实践是在代码开始时调用一次 `getMap()` 并将结果缓存起来，以供后续使用。
错误处理: 当 FLS 检查失败时，代码的行为至关重要。WITH SECURITY_ENFORCED 会抛出异常，你需要捕获它并提供有意义的用户反馈。对于 `stripInaccessible`，它不会抛出异常，而是静默地移除字段。你需要决定这种静默行为是否符合业务需求，或者是否需要检查 `getRemovedFields()` 并通知用户某些字段未被更新。
FLS 与页面布局/必填字段: FLS 是最终的权限控制。一个字段可以在页面布局上是“必填”的，但如果用户通过 FLS 对该字段没有编辑权限，他们在尝试保存记录时仍然会遇到错误。作为开发者，要确保权限模型和 UI 设计是一致的。
复合字段: 对于地址（Address）或地理位置（Geolocation）等复合字段，FLS 是在组件字段级别上应用的（例如，`BillingStreet`、`BillingCity`）。你需要检查每个组件字段的权限，而不是整个复合字段。

总结与最佳实践

对于 Salesforce 开发者来说，字段级安全性绝不是一个可以忽略的“管理员问题”。它是我们构建安全、可信赖应用程序的基石。不尊重 FLS 的代码不仅是技术债务，更是一个随时可能被利用的安全漏洞。

最佳实践总结:

查询优先使用 `WITH SECURITY_ENFORCED`: 对于所有需要在用户上下文中运行的 SOQL 查询，这应该是你的默认选择。它简洁、明确，能有效防止数据泄露。
DML 操作前使用 `Security.stripInaccessible()`: 在执行 `insert`、`update` 或 `upsert` 之前，使用此方法来清理数据。这可以防止因权限不足导致的 DML 异常，并确保只写入用户有权修改的数据。
精细控制时才使用 Schema Describe: 当你需要根据用户权限动态构建 UI 或执行复杂业务逻辑时（例如，“如果用户能编辑字段 A，则执行 X；否则执行 Y”），Schema Describe 方法是你的最佳工具。
编写考虑安全性的单元测试: 你的测试类应该覆盖不同权限的用户场景。使用 `System.runAs()` 来模拟一个没有特定字段权限的用户，并断言你的代码能够正确处理 FLS 限制（例如，捕获预期的异常或验证字段未被更新）。
与管理员和架构师协作: 开发者应与负责配置安全模型的团队保持沟通，充分理解数据访问策略，确保代码实现与预期的安全设计保持一致。

通过将这些原则和工具融入到你的日常开发实践中，你将能够构建出不仅满足业务需求，而且能够经受住安全考验的强大 Salesforce 应用程序。

Salesforce中文网