Salesforce 架构师指南：深入解析 Shield Platform Encryption 的数据安全与合规性

背景与应用场景

作为一名 Salesforce 架构师，我日常工作的核心之一就是确保我们构建的解决方案不仅功能强大、可扩展，而且必须绝对安全。在当今数据驱动的世界里，数据泄露的风险和合规性要求（如 GDPR、HIPAA、CCPA）日益严苛，企业对敏感数据的保护需求也达到了前所未有的高度。Salesforce 作为一个承载着企业核心客户、销售和服务的平台，其数据安全策略是任何架构设计的基石。

在这种背景下，Shield Platform Encryption（中文解释：Shield 平台加密）应运而生。它不是一个简单的字段加密工具，而是一个全面的、深植于 Salesforce 平台底层的静态数据加密（Encryption at Rest）解决方案。与 Salesforce 提供的标准加密（Classic Encryption）不同，后者仅能加密特定类型的自定义文本字段，并且密钥由 Salesforce 管理，Shield Platform Encryption 提供了更广泛的覆盖范围和更强的控制力。

从架构师的视角来看，引入 Shield Platform Encryption 的主要驱动力通常来自以下几个方面：

合规性要求： 许多行业（如金融、医疗保健、政府部门）的法律法规强制要求对特定的个人身份信息（PII - Personally Identifiable Information）或受保护的健康信息（PHI - Protected Health Information）进行静态加密。
合同义务： 企业的客户或合作伙伴可能会在合同中要求对存储在其系统中的数据提供最高级别的安全保障。
内部数据治理策略： 企业为降低数据泄露带来的声誉和财务风险，主动采取“纵深防御”策略，将静态数据加密作为关键的一环。
增强的密钥管理： 企业希望对加密密钥的生命周期拥有更多控制权，包括自行生成、轮换和销毁密钥，即实现自带密钥（BYOK - Bring Your Own Key）的能力。

因此，当我们设计的系统需要处理社会安全号码、信用卡号（部分）、病历信息、敏感的财务数据或其他任何被归类为高度敏感的信息时，Shield Platform Encryption 便成为了架构选型中不可或缺的一部分。

原理说明

要正确地设计和实施 Shield Platform Encryption，架构师必须深刻理解其工作原理。它的加密机制并非简单的“一键加密”，而是一个分层的密钥架构，旨在实现安全性和可用性之间的平衡。

分层密钥架构 (Key Hierarchy)

Shield 的核心是一个分层的密钥派生过程，确保了职责分离和高强度加密：

Master Secret： 这是一个由 Salesforce 在每个发布周期更新的主密钥。它由硬件安全模块（HSM - Hardware Security Module）安全地存储和管理，客户无法直接访问。
Tenant Secret： 这是由客户（即您）生成和管理的密钥。您可以选择在 Salesforce 内部生成，也可以上传您自己生成的密钥（BYOK）。这个密钥是您掌控数据加密的关键。它的生命周期管理（创建、轮换、备份、销毁）是架构师必须制定的核心策略。
Data Encryption Key (DEK)： 最终用于加密和解密数据的密钥。这个 DEK 并非直接存储，而是通过一个密钥派生函数（KDF - Key Derivation Function），结合 Master Secret 和您的 Tenant Secret 动态派生出来的。这意味着，即使 Salesforce 的 Master Secret 或您的 Tenant Secret 单独泄露，数据也无法被解密。只有当两者结合时，才能生成正确的 DEK。

这个架构的精妙之处在于，它将数据加密的控制权部分交还给了客户。一旦您销毁了您的 Tenant Secret，相关的 DEK 将无法再被派生，数据将变得永久不可访问，这对于处理“被遗忘权”等合规场景至关重要。

加密方案 (Encryption Schemes)

在为字段启用加密时，架构师必须做出一个关键决策：选择哪种加密方案。Shield 提供了两种主要的方案，它们在安全性与功能性之间有着截然不同的权衡。

1. Probabilistic Encryption (概率加密)

这是默认且最安全的加密方案。它使用一个初始化向量（IV - Initialization Vector），确保相同的明文数据在每次加密后都会产生不同的密文。这种方式可以有效抵御基于密文频率分析的攻击。

优点： 安全性最高。
缺点： 由于相同的输入产生不同的输出，加密后的字段无法用于筛选查询（如 SOQL 的 `WHERE` 子句）、排序（`ORDER BY`）、分组（`GROUP BY`），也无法用于报表或列表视图的筛选。它完全破坏了数据库的查询能力。

2. Deterministic Encryption (确定性加密)

这种方案不使用初始化向量，因此相同的明文数据在加密后总会产生相同的密文。这使得数据库可以在不解密数据的情况下对密文进行精确匹配。

优点： 允许对加密字段进行筛选。您可以在 SOQL 的 `WHERE` 子句、报表筛选、列表视图筛选中使用“等于”或“不等于”的操作。
缺点： 安全性相对较低。攻击者可以通过分析密文的分布来推断原始数据的一些模式。因此，它只应在业务上绝对需要筛选该字段时才使用，并且应仅用于低基数（low-cardinality）的数据。

确定性加密还分为大小写敏感（Case-Sensitive）和大小写不敏感（Case-Insensitive）两种。大小写不敏感的方案在筛选时更灵活，但安全性也更低，因为它暴露了更多关于原始数据的信息。

作为架构师，我们的职责是仔细评估每个需要加密的字段，并根据业务需求和安全风险，为其选择最合适的加密方案。滥用确定性加密会削弱整个加密策略的强度。

示例代码

Shield Platform Encryption 主要通过声明式配置启用，但它对代码，尤其是 SOQL 查询，有直接而深远的影响。以下代码示例展示了如何与使用确定性加密的字段进行交互。

假设我们在 `Account` 对象上有一个名为 `Social_Security_Number__c` 的自定义字段，用于存储社会安全号码，并且我们已为其启用了大小写敏感的确定性加密。

在 SOQL 查询中筛选确定性加密字段

当字段使用确定性加密时，您可以在 `WHERE` 子句中对其进行精确匹配查询。Salesforce 会在数据库层面对密文进行比较。

// 此 Apex 代码查询 Social_Security_Number__c 字段
// 该字段必须预先通过 Shield Platform Encryption 设置为“确定性加密”

String ssnToFind = '123-456-7890';

// SOQL 查询可以直接在 WHERE 子句中使用该字段进行筛选
// Salesforce 平台会自动处理加密和匹配逻辑
// 只有当用户拥有“查看加密数据”权限时，查询结果中的字段值才会以明文形式返回
List<Account> accounts = [
    SELECT Id, Name, Social_Security_Number__c 
    FROM Account 
    WHERE Social_Security_Number__c = :ssnToFind
];

for (Account acc : accounts) {
    // 如果执行此代码的用户有“查看加密数据”权限，
    // 则 acc.Social_Security_Number__c 将是解密后的明文 '123-456-7890'
    // 否则，该字段将显示为屏蔽后的值
    System.debug('Found Account: ' + acc.Name + ', SSN: ' + acc.Social_Security_Number__c);
}

重要注释：

上述查询之所以能成功，唯一的原因是 `Social_Security_Number__c` 字段被配置为确定性加密。如果它被配置为概率性加密，执行此查询将立即抛出 `QueryException` 异常，提示该字段不可被筛选。
确定性加密仅支持等于 (`=`) 和不等于 (`!=`, `<>`) 操作符，以及 `IN` 子句。不支持 `LIKE`、`STARTS WITH`、`>`、`<` 等操作。

注意事项

在架构设计中引入 Shield Platform Encryption 是一项重大决策，必须充分考虑其带来的影响和限制。

1. 性能影响

加密和解密操作会消耗额外的 CPU 资源。虽然 Salesforce 平台对此进行了优化，但在处理大量数据时，性能开销仍然是不可避免的。这可能会影响报表和列表视图的加载时间、SOQL 查询的执行速度以及 API 调用的响应时间。在实施前，必须在沙箱环境中对关键业务流程进行充分的性能基准测试。

2. 功能限制

这是架构师需要向业务方和开发团队明确传达的最重要的一点。启用加密后，许多标准功能会受到限制：

查询和排序： 如前所述，概率性加密字段无法筛选，确定性加密字段也无法用于 `ORDER BY`, `GROUP BY`, `LIKE` 等子句。
公式字段和验证规则： 您可以在公式字段和验证规则中引用加密字段，但平台会在运行时解密它们，这会带来性能开销。
标准字段的限制： 并非所有标准字段都支持加密。例如，您不能加密 `Account.Name` 或 `Case.Subject` 等关键查询字段。在规划阶段，必须参考官方文档，确认哪些字段可以被加密。
报表和仪表盘： 仪表盘筛选器和跨对象筛选器不支持加密字段。报表图表的分组（Grouping）功能也受限。
搜索： 全局搜索和 SOQL 搜索对加密字段的支持非常有限。

3. 密钥管理 (Key Management)

密钥管理是整个安全策略的核心，也是风险最高的地方。作为架构师，必须制定严格的密钥管理流程：

备份 Tenant Secret： 这是最重要的一步。 如果您丢失了 Tenant Secret 并且没有备份，所有被该密钥加密的数据将永久丢失，无法恢复。必须将导出的 Tenant Secret 存储在安全的离线位置（如物理保险箱或安全的密钥保管库）。
密钥轮换 (Key Rotation)： 定期轮换 Tenant Secret 是安全最佳实践。这可以限制密钥一旦泄露可能造成的损害范围。您需要定义一个合理的轮换周期（例如，每年一次），并确保在轮换后，旧密钥被安全存档，以备数据恢复之需。
权限控制： 必须严格控制“管理加密密钥”和“查看加密数据”这两个关键权限。只有极少数经过授权的管理员（如首席安全官或指定的系统管理员）才应拥有管理密钥的权限。

4. API 与集成

对于通过 API 与 Salesforce 集成的外部系统，Shield 的影响也必须被考虑。当一个拥有“查看加密数据”权限的集成用户通过 API 读取数据时，数据会在传输前被 Salesforce 自动解密。这意味着，传输通道（TLS）和接收端系统的安全性变得至关重要。架构师必须确保整个数据流的端到端安全。

总结与最佳实践

Shield Platform Encryption 是一个功能强大的工具，它为 Salesforce 平台提供了企业级的静态数据加密能力，是满足高级别安全和合规性需求的利器。然而，它并非“银弹”，不当的使用会带来性能问题和功能限制。

作为 Salesforce 架构师，我提出以下最佳实践：

进行数据分类，按需加密： 在启用加密之前，务必进行全面的数据分类评估。识别出哪些数据是真正敏感且有合规性要求的，只对这些数据进行加密。避免“为了加密而加密”的做法，因为过度加密会不必要地牺牲平台的功能和性能。
优先选择概率性加密： 默认应始终使用安全性最高的概率性加密。只有在业务流程强依赖于对某个字段进行筛选，并且经过了严格的安全风险评估后，才谨慎地选择确定性加密。
制定并演练密钥管理灾备计划： 密钥管理的失败是灾难性的。必须制定详细的密钥备份、恢复和轮换计划，并定期进行演练，确保在紧急情况下团队能够正确、迅速地响应。
在方案设计早期即考虑加密影响： 不要等到项目后期才考虑加密。在解决方案设计的最初阶段，就应该评估加密对数据模型、业务逻辑、用户体验和集成的全面影响，并将其纳入整体架构蓝图。
全面测试： 在将加密部署到生产环境之前，在全量沙箱（Full Sandbox）中进行彻底的功能、性能和集成测试。确保所有涉众——从最终用户到集成系统——都理解并接受加密带来的变化。

总而言之，成功实施 Shield Platform Encryption 的关键在于深入的规划、周密的架构设计以及对功能与安全之间权衡的深刻理解。它不仅仅是一个技术开关，更是一个需要融入企业整体数据治理和安全策略的战略性决策。

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

九月 15, 2025

阅读全文

Salesforce中文网