Salesforce Shield 平台加密：企业架构师深度解析

十月 04, 2025

背景与应用场景

在当今数据驱动的世界中，数据不仅是企业最宝贵的资产，也是最大的责任之一。随着全球数据隐私法规日益严格，如欧盟的 General Data Protection Regulation (GDPR)、美国的California Consumer Privacy Act (CCPA) 以及医疗行业的 Health Insurance Portability and Accountability Act (HIPAA)，企业必须采取强有力的措施来保护客户的敏感数据。仅仅依赖于应用层面的权限控制（如配置文件和权限集）已经不足以应对来自内部和外部的复杂安全威胁。

Salesforce 作为全球领先的 CRM 平台，承载了大量企业的核心客户数据，包括个人身份信息 (Personally Identifiable Information, PII)、财务记录、健康信息等。虽然 Salesforce 平台本身提供了强大的多租户安全架构，但对于那些需要满足最高级别合规性要求的企业来说，还需要一层额外的、深度的数据保护。Salesforce Shield Platform Encryption 便是为此而生的解决方案。

从架构师的角度来看，Shield Platform Encryption 并非简单的“字段加密”工具，而是一个全面的数据静态加密 (Data-at-Rest Encryption) 框架。它旨在保护存储在 Salesforce 数据库中的数据，即使在极少数情况下发生底层数据库泄露，数据本身仍然是不可读的密文。其主要应用场景包括：

合规性遵从： 满足金融、医疗、政府等受严格监管行业的数据保护法规要求。

内部威胁防护：

增强客户信任：

合同义务：

与 Salesforce 提供的标准“传统加密”（Classic Encryption）相比，Shield Platform Encryption 提供了更广泛的加密覆盖范围（包括标准字段、自定义字段、文件和附件等），并引入了更强大的密钥管理生命周期，包括自带密钥 (Bring Your Own Key, BYOK) 的能力。这为企业架构师在设计安全和合规解决方案时提供了更大的灵活性和控制力。

原理说明

要深入理解 Shield Platform Encryption，架构师必须掌握其核心工作原理，即多层次的密钥架构 (Key Hierarchy) 和两种不同的加密方案 (Encryption Schemes)。

密钥架构 (Key Hierarchy)

Shield Platform Encryption 并未使用单一密钥来加密所有数据，而是采用了一种分层的密钥派生机制，这极大地增强了安全性。如果一个密钥被泄露，也只会影响到一小部分数据，并且可以快速轮换。

主密钥 (Master Secret)： 位于密钥层次结构的顶端。这是一个由 Salesforce 严格管理的密钥，每个 Salesforce 版本（Release）都会生成一个新的主密钥。它被存储在高度安全的硬件安全模块 (Hardware Security Module, HSM) 中，客户无法直接访问。
租户密钥 (Tenant Secret)： 这是由每个 Salesforce 组织（Org）自己生成和管理的密钥。组织管理员可以通过“设置”菜单生成或上传自己的租户密钥（BYOK）。这个密钥是加密和解密数据的关键所在，组织对它拥有完全的控制权。丢失租户密钥意味着永久丢失对应的加密数据！
数据加密密钥 (Data Encryption Key, DEK)： 实际用于加密和解密数据的密钥。当您为某个字段启用加密时，系统会使用您的租户密钥和主密钥派生出一个唯一的 DEK。这个 DEK 随后用于对该字段的数据进行加密。这种设计避免了将高价值的租户密钥直接用于大量的数据加密操作，降低了密钥暴露的风险。

当用户访问加密数据时，应用程序会透明地执行解密过程：系统使用 DEK 解密数据，而 DEK 的有效性则由租户密钥和主密钥共同保证。对于拥有“查看加密数据”(View Encrypted Data) 权限的用户来说，整个过程是无缝的。

加密方案 (Encryption Schemes)

在启用字段加密时，架构师必须做出一个关键决策：选择哪种加密方案。这个选择将直接影响到数据的功能性和安全性。

概率加密 (Probabilistic Encryption)： 这是默认且更安全的方案。使用概率加密时，相同的明文每次加密后都会生成不同的密文。这是通过在加密过程中引入一个随机的初始化向量 (Initialization Vector, IV) 实现的。优点： 安全性极高，无法通过比较密文来猜测原始值。缺点： 由于密文不具备唯一性，因此无法对加密字段进行筛选、排序或分组。这意味着在 SOQL 查询的 WHERE 子句、报表筛选器或列表视图中，您不能使用“等于”操作符。
确定性加密 (Deterministic Encryption)： 在这种方案下，相同的明文（在相同的字段和 Org 中）将始终生成相同的密文。这是通过使用一个固定的、基于数据和密钥的 IV 实现的。优点： 支持在 SOQL 的 WHERE 子句、报表和列表视图中进行精确匹配（等于或不等于）筛选。缺点： 安全性相对较低。如果攻击者能够观察到足够多的密文，他们可能会推断出哪些记录具有相同的原始值（频率分析攻击）。确定性加密分为两种：区分大小写 (Case-Sensitive) 和 不区分大小写 (Case-Insensitive)，后者在筛选时更加灵活。

作为架构师，必须在业务需求（如报表筛选能力）和安全需求之间做出权衡。最佳实践是，仅对必须进行筛选的字段使用确定性加密，对其他所有敏感字段均使用概率加密。

示例代码

Shield Platform Encryption 的主要配置是通过声明式界面完成的，但在开发和集成中，最常遇到其影响的地方是 Salesforce Object Query Language (SOQL) 查询。以下代码示例展示了如何查询一个被确定性加密的字段。

假设我们在客户 (Account) 对象上有一个名为 Social_Security_Number__c 的自定义字段，并已为其启用了不区分大小写的确定性加密 (Case-Insensitive Deterministic Encryption)。

// 此 Apex 代码在匿名执行窗口或 Apex 类中运行
// 它演示了如何查询一个使用确定性加密的字段

// 准备要查询的明文值
String ssnToQuery = '123-456-7890';

// 执行 SOQL 查询
// 因为 Social_Security_Number__c 字段使用了确定性加密，
// Salesforce 平台可以在数据库层面直接对加密后的值进行比较。
// 这使得在 WHERE 子句中使用等号操作符 (=) 成为可能。
// 如果该字段使用的是概率加密，这样的查询将会抛出 "field cannot be filtered" 的异常。
List<Account> matchingAccounts = [
    SELECT Id, Name, Social_Security_Number__c 
    FROM Account 
    WHERE Social_Security_Number__c = :ssnToQuery
];

// 检查查询结果
if (!matchingAccounts.isEmpty()) {
    // 遍历结果。对于拥有 "View Encrypted Data" 权限的当前用户，
    // Social_Security_Number__c 字段的值将自动解密并以明文形式显示。
    // 如果用户没有该权限，字段将显示为掩码（例如 "******"）。
    for (Account acc : matchingAccounts) {
        System.debug('找到客户: ' + acc.Name + ', SSN: ' + acc.Social_Security_Number__c);
    }
} else {
    System.debug('未找到 SSN 为 ' + ssnToQuery + ' 的客户。');
}

重要注释： 上述代码的成功执行完全依赖于 Social_Security_Number__c 字段的加密方案。这是一个典型的架构决策点：如果业务要求必须能够根据 SSN 精确查找客户，那么确定性加密是唯一选择。如果不需要此功能，则应优先选择更安全的概率加密。

注意事项

作为架构师，在设计和实施 Shield Platform Encryption 方案时，必须充分考虑其局限性和潜在影响，这对于项目的成功至关重要。

功能限制： 加密并非没有代价。许多标准 Salesforce 功能在处理加密字段时会受到限制。
- 查询与搜索： 加密字段不支持 LIKE、STARTS WITH、CONTAINS 等模糊匹配操作符。ORDER BY (排序) 也不支持。
- 公式字段： 不能在公式字段中直接引用使用概率加密的字段。
- 报表与仪表盘： 不能对加密字段进行分组或排序。
- 其他限制： 诸如潜在客户转换、活动管理、筛选条件等都可能受到影响。在实施前，必须进行详尽的业务流程回归测试。
性能影响： 加密和解密操作会增加服务器处理的开销。虽然 Salesforce 已经对此进行了优化，但在处理大量数据或复杂查询时，仍可能观察到轻微的性能下降。
密钥管理责任： 这是最关键的运营责任。企业必须制定严格的密钥管理策略，包括：
- 密钥轮换 (Key Rotation)： 定期生成新的租户密钥，以降低旧密钥泄露的风险。
API 与集成： 通过 API 访问加密数据的外部系统，其使用的集成用户必须被授予“查看加密数据”权限，才能获取解密后的数据。否则，API 将返回 null 或掩码值。这需要在集成设计阶段就进行规划。
Sandbox 环境： 当刷新 Sandbox 时，生产环境的加密数据会以加密形式复制过来。但是，Sandbox 会生成自己的租户密钥。为了在 Sandbox 中查看这些数据，您需要从生产环境导出数据，在本地解密，然后再导入 Sandbox，或者使用 Data Mask 产品。

总结与最佳实践

Salesforce Shield Platform Encryption 是一个强大而必要的工具，适用于需要满足高级别数据安全和合规性要求的企业。然而，它绝不是一个可以“一劳永逸”地开启的功能。作为架构师，成功实施 Shield 的关键在于深入的规划、对业务影响的全面评估以及严格的治理。

最佳实践：

最小化加密范围： 遵循“非必要不加密”原则。只对真正敏感且法规要求加密的数据字段启用加密。过度加密会不必要地限制功能、影响性能并增加管理复杂性。
进行数据分类： 在项目开始前，与业务、法务和合规团队合作，对所有数据进行分类，明确哪些属于 PII、PHI 或其他敏感类别，并确定哪些必须加密。
明智选择加密方案： 优先使用安全性更高的概率加密。仅在业务流程（如数据查询或报表筛选）绝对需要时，才谨慎地为特定字段选择确定性加密。
建立强大的密钥管理治理模型： 这是整个安全策略的基石。明确定义密钥生命周期管理的流程、角色和责任，并定期演练备份和恢复程序。
全面测试： 在将加密部署到生产环境之前，在全功能 Sandbox 中对所有受影响的业务流程、报表、集成和自定义代码进行端到端的测试。

最终，Shield Platform Encryption 的价值不仅仅在于技术本身，更在于它促使企业重新审视其数据治理和安全策略。通过周密的设计和实施，它可以成为企业保护其最关键资产、赢得客户信任的坚实盾牌。

Salesforce中文网