精通 Salesforce 字段级安全：管理员综合指南

十月 30, 2025

背景与应用场景

作为一名 Salesforce 管理员，我工作的核心职责之一就是确保公司数据的完整性、保密性和可用性。在 Salesforce 庞大而灵活的安全模型中，Field-Level Security (字段级安全)，简称 FLS，是我们手中最常用、也最强大的精细化访问控制工具之一。它的核心价值在于，允许我们控制用户在记录级别上对特定字段的可见性和可编辑性。

想象一个常见的业务场景：在我们的“商机 (Opportunity)”对象上，有一个“折扣百分比 (Discount Percentage)”字段和一个“预计利润 (Estimated Profit)”字段。

销售代表 (Sales Rep) 需要查看并编辑“折扣百分比”来与客户协商，但他们不应该看到敏感的“预计利润”信息。
销售经理 (Sales Manager) 不仅需要查看和编辑“折扣百分比”，还需要查看“预计利润”来评估交易的健康度。
财务团队 (Finance Team) 可能只需要查看（只读）这两个字段，用于财务报告，但不能修改它们。
市场营销团队 (Marketing Team) 在查看商机时，可能完全不需要看到这两个与财务直接相关的字段。

如果没有 Field-Level Security，我们就只能在对象级别上授予或拒绝访问权限，这意味着所有能看到商机记录的人都能看到所有字段。这显然会造成严重的数据泄露风险和混乱。FLS 正是解决这一问题的关键，它让我们能够像用手术刀一样，精确地为不同角色的用户群体“裁剪”出他们需要的数据视图，从而实现最小权限原则 (Principle of Least Privilege)，确保用户只能访问其履行工作职责所必需的信息。

原理说明

要理解 FLS，首先需要了解它在 Salesforce 整个数据安全模型中所处的位置。Salesforce 的安全模型是一个层次化的结构，从最广泛的组织级别访问到最精细的字段级别访问，层层递进：

组织级安全 (Organization-Level Security): 控制用户可以访问您的组织的时间和地点（例如，IP 限制、登录时间）。
对象级安全 (Object-Level Security): 控制用户可以查看、创建、编辑和删除哪些对象的记录（例如，某用户可以访问“客户”对象，但不能访问“案例”对象）。
记录级安全 (Record-Level Security): 控制用户可以查看和编辑哪些特定记录（例如，通过组织范围默认设置、角色层次结构、共享规则和手动共享）。
字段级安全 (Field-Level Security): 这是最精细的一层，控制用户在他们有权访问的记录中，可以看到和编辑哪些字段。

一个重要的原则是：最严格的设置优先。例如，即使用户通过对象级安全拥有对“商机”对象的编辑权限，并且通过记录级共享规则可以看到某条特定的商机记录，但如果 FLS 设置隐藏了“预计利润”字段，那么该用户无论如何都无法看到或编辑这个字段。FLS 是数据访问的最后一道防线。

如何配置 FLS？

作为管理员，我们主要通过两个工具来配置 FLS：Profile (简档) 和 Permission Set (权限集)。

1. Profile (简档):

每个用户在 Salesforce 中都必须被分配一个简档。简档定义了用户的基础权限，包括他们可以访问哪些应用程序、选项卡、对象权限以及字段级安全。在简档中，我们可以为特定对象的每个字段设置两种访问级别：

Read Access (读取权限): 用户可以看到该字段的值。
Edit Access (编辑权限): 用户可以查看并修改该字段的值。（此权限隐含了读取权限）

如果两个复选框都未选中，则该字段对分配了此简档的用户完全隐藏。他们将无法在页面布局、列表视图、报表、搜索结果或通过 API 看到该字段。

2. Permission Set (权限集):

虽然简档是基础，但现代 Salesforce 管理的最佳实践是使用权限集来扩展用户的访问权限。权限集是一组设置和权限的集合，可以授予用户额外的访问权限，而无需更改他们的简档。这种方法更加灵活和可扩展。例如，我们可以创建一个名为“财务数据查看者”的权限集，其中包含对“预计利润”字段的只读访问权限，然后将此权限集分配给所有需要查看该字段的销售经理和财务团队成员，无论他们拥有哪个基础简档。

使用权限集的好处是巨大的。它避免了所谓的“简档激增 (Profile proliferation)”问题，即为了满足各种细微的权限差异而创建数十个甚至上百个相似的简档，这会使权限管理变得异常复杂和难以维护。

示例代码（管理员视角：FLS 如何影响代码）

虽然作为管理员，我们主要通过点击式界面来配置 FLS，但理解这些配置如何影响开发者编写的 Apex 代码至关重要。这有助于我们更好地与开发团队协作，构建安全可靠的应用程序。当开发者编写代码来查询或更新数据时，他们必须在代码中显式地检查 FLS，否则代码可能会在没有相应权限的用户上下文中运行时失败，或者更糟糕的是，绕过安全设置。

Salesforce 官方文档提供了标准的 Apex 模式来检查字段的可访问性。以下代码片段展示了开发者在更新联系人记录之前，如何检查当前用户是否对 `FirstName` 和 `Department` 字段具有更新权限。

// Get thedescribe result for the Contact sObject
Schema.DescribeSObjectResult d = Contact.sObjectType.getDescribe();

// Get the map of fields for the Contact sObject
Map<String, Schema.SObjectField> M = d.fields.getMap();

// Check if the user has update access on the FirstName and Department fields
if (M.get('FirstName').getDescribe().isUpdateable() &&
    M.get('Department').getDescribe().isUpdateable()) {

    // If the user has update access, create a new Contact record and
    // add values for the two fields
    Contact c = new Contact(
        FirstName = 'John',
        LastName = 'Doe',
        Department = 'Finance'
    );

    // Update the contact record
    try {
        update c;
    } catch (DmlException e) {
        // Handle DML exception
        System.debug('An unexpected error has occurred: ' + e.getMessage());
    }
} else {
    // Let the user know they don't have the necessary permissions
    // This could be by showing a message on a Visualforce page or Lightning component
    System.debug('You do not have the necessary permissions to update these Contact fields.');
}

代码注释：

第 2 行: `Contact.sObjectType.getDescribe()` 获取关于 Contact 对象的元数据信息，这是一个描述对象结构（包括其所有字段）的“蓝图”。
第 5 行: `d.fields.getMap()` 返回一个映射，其中键是字段的 API 名称（例如 'FirstName'），值是代表该字段的对象 (`Schema.SObjectField`)。
第 8-9 行: 这是 FLS 检查的核心。`M.get('FirstName').getDescribe().isUpdateable()` 会返回一个布尔值（true 或 false）。如果我们在简档或权限集中未授予当前用户对 `FirstName` 字段的“编辑”权限，则此方法将返回 `false`。代码同时检查 `FirstName` 和 `Department` 字段。
第 12-17 行: 只有在 FLS 检查通过后，代码才会尝试执行 DML (Data Manipulation Language) 操作，即更新记录。
第 24-27 行: 如果 FLS 检查失败，代码将跳过更新操作，并可以向用户提供友好的提示信息。

这个例子清晰地表明，我们在界面上所做的 FLS 配置，会直接被 `isUpdateable()`、`isAccessible()` (检查读取权限) 和 `isCreateable()` (检查创建权限) 等 Apex 方法所遵循。它确保了 Salesforce 的安全模型在命令式代码中也能得到严格执行。

注意事项

1. FLS 与页面布局 (Page Layouts) 的关系

这是一个常见的混淆点。页面布局控制的是用户界面的观感，而 FLS 控制的是真正的数据访问权限。

你可以从页面布局中移除一个字段，但如果用户通过 FLS 仍然拥有该字段的访问权限，他们依然可以在报表、列表视图、搜索和 API 调用中看到该字段。
反之，你可以将一个字段放在页面布局上，但如果用户因为 FLS 的限制而没有访问权限，那么该字段在页面上对他们来说仍然是不可见的。

结论：FLS 是更底层的、更强制性的安全控制。页面布局仅仅是 UI 层的便利工具。

2. 必填字段 (Required Fields)

如果一个字段在对象级别被设置为“始终必需 (Universally Required)”，那么你必须在所有授予该对象“编辑”权限的简档中，同时授予该字段的 FLS 编辑权限。否则，用户在尝试保存记录时会遇到错误，因为他们无法填充一个他们看不见但又必须填写的字段。

3. API 与集成的强制性

FLS 不仅仅作用于 Salesforce 的标准用户界面。它在整个平台范围内都是强制执行的，包括所有 API（REST, SOAP, Bulk, etc.）。这意味着，当外部系统通过 API 与 Salesforce 集成时，用于集成的用户账户同样受到 FLS 的严格限制。这是确保端到端数据安全的关键。

4. 系统和审计字段 (System and Audit Fields)

像 `Id`, `CreatedDate`, `LastModifiedById` 这样的系统审计字段的 FLS 是不能被修改的。它们对于数据完整性至关重要，由系统自动管理。

总结与最佳实践

Field-Level Security 是 Salesforce 管理员工具箱中不可或缺的一部分。它提供了保护数据、满足合规性要求和优化用户体验所需的精细控制能力。正确地实施 FLS 不仅是一项技术任务，更是一项关键的业务治理活动。

作为管理员，我们应遵循以下最佳实践：

拥抱最小权限原则: 始终从最严格的权限设置开始（默认隐藏所有非必要字段），然后根据明确的业务需求，逐步为特定用户组开放权限。
优先使用权限集: 采用“最小访问权限简档 + 权限集”的模型。为所有用户创建一个或几个非常基础的简档，这些简档只包含最少的通用权限。然后，通过权限集和权限集组 (Permission Set Groups) 来授予特定的 FLS 和其他权限。这种方法极大地简化了用户权限管理，使其更具扩展性和可维护性。
定期审计权限: 业务需求是不断变化的。定期审查 FLS 设置，特别是针对包含敏感数据的对象（如客户、联系人、商机），以确保权限配置仍然符合当前的安全策略。可以利用 Salesforce Optimizer 或 AppExchange 上的一些工具来辅助审计。
清晰的文档记录: 记录下为什么某个权限集被创建，它授予了哪些关键的 FLS 权限，以及它被分配给了哪些业务角色。当组织结构或人员发生变动时，这份文档将是无价之宝。
与开发团队紧密协作: 确保开发人员理解并遵循在 Apex 和其他自定义代码中检查 FLS 的最佳实践。安全是一个团队的共同责任，管理员的配置和开发者的代码必须协同工作，才能构建一个真正安全的系统。

通过深思熟虑地规划和实施字段级安全策略，我们可以自信地确保，在我们的 Salesforce 组织中，正确的数据在正确的时间，只呈现给正确的用户。

Salesforce中文网