Trust

在 Salesforce 中，Trust 是我们的第一价值观。这是平台上每个架构决策的基础。对于架构师来说，Trust 是通过独特的合作伙伴关系实现的：Salesforce 提供了一个安全、合规的平台（基础设施、元数据和工具，使其成为您自己的平台），而您设计的安全解决方案正是基于该基础。

这种伙伴关系通过分担责任模式运作,这是一个明确划分安全责任的框架:

• Salesforce 负责平台的安全性，包括基础设施、补丁和合规认证。
• 您负责平台上的安全性，包括配置、访问控制、自定义代码和数据治理。

这种划分至关重要，因为它定义了架构问责制。Salesforce 运行多租户架构，数千个组织在其中共享基础设施。该平台在基础设施级别提供强大的安全保护。您的架构决策决定了您的特定解决方案能否赢得利益相关者的信任。

共享责任模型让您负责设计安全的解决方案，同时为您处理物理安全、网络保护、平台修补和基础设施加密。这可让您专注于设计以此为基础构建的安全解决方案（例如，身份和访问权限管理、数据保护、集成安全性、安全开发实践、合规性和法规遵从性以及事件响应功能）。

在设计期间忽视 Trust 会加重技术债务。当法规发生变化时，缺失的加密策略将成为代价高昂的改造。当凭据被泄露时，不受控制的集成就会成为漏洞。从一开始就建立Trust总是比稍后重新构建信任更便宜。

Trust 跨越 4 个架构维度，它们紧密协作：

• 安全控制保护系统和数据
• 身份管理控制访问权限
• 隐私实践尊重用户代理
• 合规框架满足监管义务

设计所有四个维度的架构师创建的解决方案通过透明度、控制和弹性赢得并保持 Trust。

在客服人员时代，Trust 扩展到客服人员操作的受信任上下文。可信上下文意味着客服人员访问具有明确身份和权限边界的受管、已验证数据，这使得 AI 系统能够代表用户进行推理和采取行动，同时还能保持安全性、可审计性和合规性。设计可信上下文是客服人员企业架构的基础。

此支柱建立每个 Salesforce 解决方案所依赖的平台安全基准。Agentic Trust支柱以该基线为基础,解决自主客服人员特有的风险,包括及时注入、行动治理和客服人员在推理期间可以访问的数据。首先设计基准，然后使用 Agentic Trust 准则分层特定于客服人员的控制非常重要。

这一支柱与其他框架问题有着深刻的联系。

• 可靠性取决于抵御攻击并从破坏中恢复的基础设施。
• 卓越运营需要安全的部署漏斗和事件响应功能。
• 公平性要求以透明、合乎道德的方式处理数据和算法决策。

这些支柱共同构成了一个以解决方案为中心的统一方法，组织可以Trust它最敏感的操作。

在分担责任模式中,Salesforce 和架构师必须履行各自的责任来维持 Trust。让我们仔细看看双方必须保护什么。

Salesforce 负责保护平台及其全球基础设施，包括：

• 数据中心访问控制、监控和环境保障措施
• 对于 Hyperforce，基础云提供商（例如，AWS、Azure 或 Google Cloud，取决于实例）通过委派责任处理物理数据中心安全性。Salesforce 基础设施和子处理器文档标识了每个服务的提供商和子处理器。

• 网络层安全控制，包括 DDoS 保护和威胁检测
• 传输中 (TLS 1.2+) 和静态流量加密（通常是 AES-256）

• 通过 Salesforce 进行漏洞响应和平台补丁部署（有关安全建议的更多信息，请访问 security.salesforce.com）
• 操作系统和基础设施安全管理

• **认证和证明：**Salesforce 维护 SOC 1/2/3、ISO 27001/27017/27018、FedRAMP 授权（范围是 Government Cloud Plus 和 MuleSoft Government Cloud，而不是商业多租户平台）和 PCI DSS 1 级验证。
• **监管支持：**这适用于具有业务关联协议 (BAA) 或 GDPR 合规计划的符合 HIPAA 标准的服务。
• 有关更多信息，请访问 trust.salesforce.com 和 compliance.salesforce.com。

• **租户隔离架构：**共享的元数据驱动的内核按组织 ID 对每个组织的数据和元数据进行分区，因此一个组织无法访问另一个组织的记录，即使它们都在共享基础设施上运行。内核对每个查询强制执行分离，而不是通过您必须维护的配置。
• **静态和备份基础架构的基础架构级加密：**基础平台许可证包括经典加密（AES-128 仅提供自定义文本字段）。Shield Platform Encryption 需要单独的许可证（AES-256 允许您自带密钥，并提供标准和自定义字段、文件和附件）。

这些控制可确保平台保持安全、可靠和合规。

您负责保护数据、配置和运营流程。

• **身份和联盟：**对于单点登录 (SSO) 和多重身份验证 (MFA)，您必须验证用户的身份。
• **访问限制：**从技术上讲，IP 范围和登录时间限制了身份的连接方式和时间。
• **最小特权原则 (PoLP)：**使用 PoLP 仅授予对执行个人工作职责所需的角色、简档和权限集的访问权限。
• 生命周期管理:实践用户生命周期管理和访问重新认证指南。

• 使用数据分类、屏蔽和对象/字段/记录级安全性
• 强制执行 CRUD 权限和共享规则
• 拥有、测试和部署经过验证的策略来恢复贵组织的数据，确保数据丢失或损坏恢复在您的控制范围内。

• 使用 API 身份验证（例如，OAuth 2.0 或 JWT）和命名凭据。
• 启用具有 PoLP 权限集的专用集成用户，以便确定每个集成的访问权限范围，并将其与人工用户分开审计。
• 保护端点和外部系统验证。

• 使用 Event Monitoring、审计跟踪和安全信息和事件管理 (SIEM) 集成。
• 遵循事件响应程序和安全审查。

• 使用安全的自定义代码(例如 Apex 或 Lightning)和输入验证。
• 在用户模式下运行 Apex，以便在代码中强制执行对象、字段和共享权限。
• 遵循注射预防和安全开发实践。

• 保持解决方案合规性。
• 遵循隐私/同意管理和数据保留策略。

一些责任需要协作：

• 安全事件响应:双方参与检测和应对活动。
• 漏洞管理:Salesforce 修补平台，架构师修补自定义代码。
• 安全监控:将平台生成的安全信号与架构师分析相结合。
• 合规认证:Salesforce 对平台进行认证（例如，SOC、ISO 和 FedRAMP for Government Cloud）；架构师拥有在认证状态下构建的内容（自定义对象、代码、集成和配置），以便为审计提供合规性证据。
• 身份联盟:Salesforce 信任架构师身份提供商提出的声明；架构师维护提供商以及提供商和 Salesforce 之间的 Trust 关系。
• 密钥管理:使用自带密钥加密，Salesforce 运行加密服务，而架构师生成、轮换和撤销保护数据的密钥材料。

本文档中的每个设计原则、主题部分和核对清单项目都代表您作为架构师的责任。共享责任模型构建了您必须设计和配置的内容，以在 Salesforce 平台上实现 Trust。

边界延伸到监管义务。Salesforce 维护平台的认证和证明，并保护基础设施免受违反。架构师负责附加到数据和管辖权的义务（例如：哪些法律适用，数据如何分类，数据的保留和同意规则如何管理，以及您如何检测和报告受您控制的数据违规）。根据部署的管理法规，架构师必须确定这些义务背后的具体数字（例如，保留期和通知截止日期），而不是根据部署的管理法规，因为它们可能因司法管辖区而异，并随着时间的推移而变化。

使用这些原则来指导您在平台上的安全架构决策。

• **在所有图层应用 Zero Trust。**请勿根据网络位置、用户熟悉程度或系统来源假设 Trust。通过数据、应用程序、集成和基础设施层的身份验证、授权和加密，明确验证每个访问请求。多租户架构意味着您与数千个组织共享基础设施，因此您的解决方案运行的网络不是您可以视为信任的周边。根据每个请求本身的优点（身份、授权和上下文）进行验证，而不是信任它的来源。
• **默认授予最小权限。**授予每个用户所需的最低访问权限级别、集成和自动化流程，以实现其目的。从最严格的设置（专用组织范围默认设置 (OWD) 和最小权限）开始，并根据记录的业务要求有意扩展。使用四层访问模型（组织 → 对象 → 字段 → 记录），以便每层进一步限制上面的层。
• **深入实施防御。**分层多个安全控制，以便一个控制的失败不会危及整个系统。组合预防性控制（例如，阻止操作的 CRUD/FLS 实施和事务安全性策略）、检测控制（例如，事件监控）和响应控制（例如，事务安全性逐步身份验证和通知）。将每个图层设计为相邻图层可能会失败。请记住，字段级安全性可以保护数据，即使共享规则过于宽松。
• **通过设计集成安全性。**将威胁建模、安全要求和控制验证集成到从初始概念到不断发展的每个架构阶段。在构建开始前，执行欺骗、篡改、拒绝、信息披露、拒绝服务和权限提升 (STRIDE) 威胁建模。安全性决定了技术选择和设计决策。
• **在自动化中嵌入安全性。**将安全控制构建到自动漏斗、配置模板和平台默认设置中。CI/CD 中的 Salesforce Code Analytics 会在部署前发现漏洞。按代码配置会强制执行安全基准。嵌入式安全性确保了一致性，并使安全性能够随着解决方案的复杂性而扩展。
• **专为隐私设计。**从初始架构阶段开始，引入隐私原则。设计用于数据最小化（仅收集必要的数据）、目的限制（按工作职能限制访问）、同意管理（强制执行特定于目的的精细同意）和数据主体权利（使访问、更正、擦除和可移植工作流能够在监管时限内完成）。
• **设计可追溯性。**在依赖于检测异常之前，使每个结果操作在事后具有可归因性和可重构性。确保审计跟踪、字段历史和事件日志中记录了对数据、权限和配置的更改，并将这些记录保存在防篡改存储中。可追溯性是检测、取证和问责制的先决条件。请记住 — 您无法调查从未记录的内容。
• **设计用于事件响应。**通过 Event Monitoring 设计可检测性，并通过事务安全性策略设计实时干预。通过记录的过程和隔离边界实现快速响应。通过备份功能和取证保留支持恢复。通过桌面练习和漏洞模拟测试响应。

架构师负责在 Salesforce 提供的平台上保护解决方案。

与 Salesforce 交互的工作负载越来越多地在核心平台之外运行 — 集成服务、自定义应用程序和无头客户端经常代表用户调用 Salesforce API。为了加速这种模式，Salesforce 将平台的功能公开为 API、工具和命令（例如，Salesforce 无头 360）。无论谁操作这些应用程序，架构师都拥有他们与 Salesforce 会面的 Trust 边界，以确定他们如何进行身份验证、他们携带什么身份和权限、他们持有什么密码以及什么数据跨越边界。

以下原则适用于任何容器化集成平台（例如 MuleSoft CloudHub）。

当外部客户端作为命名用户进行身份验证时，Salesforce 的平台安全模型会自动应用 — 对象权限、字段级安全性和共享规则会完全按照它们在浏览器中的方式强制执行。每个用户身份验证将每次调用的范围限定为该个人的权限，并保留审计跟踪，这意味着撤销用户的令牌会立即使客户端失去代表他们行事的能力。无论为特定用户做什么工作，都要优先使用它，而不是共享服务帐户。

防御性地设计边界，因为为许多用户持有令牌的客户端会集中 Trust 并成为攻击者的高价值代理：一个被盗的 OAuth 令牌可以访问客户端服务的每个用户的数据。这不是假设。在 2025 年 Salesloft Drift 事件中，攻击者盗取了 OAuth 令牌，并使用它们来访问数百个组织的 Salesforce 数据。

• **传播用户身份，请勿共享。**使用每个用户身份验证或 OAuth 2.0 令牌交换来跨服务跳传输用户的身份（请参见客服人员身份和身份验证），这样妥协的范围就限定在一个用户的上下文中，而不是在所有上下文中。
• **将 OAuth 客户端凭据和刷新令牌视为主要目标。**将它们存储在受管密码存储中，经常轮换它们，并维护立即撤销的设计。监控 API 使用情况，了解向代理攻击者发出信号的异常模式。
• **最小化两侧的范围。**将外部客户端应用程序 (ECA) 的 OAuth 范围和集成用户的 Salesforce 权限限制为功能所需的最低权限，以便受影响的客户端无法转向无关的数据。
• **通过外部客户端应用程序管理边界。**ECA 定义了外部应用程序如何进行身份验证，允许哪些流，以及应用什么范围 — 针对它们设计新的集成（请参见身份验证架构）。

在客户端以客服人员用户或集成用户身份运行时，请谨慎小心：这些身份可在提升的上下文中操作（通常针对不尊重 Salesforce 访问控制的外部系统），因此，使用以上概述的权限和监控纪律是保持该权限不变的原因。

当集成在容器化平台中运行时，容器级隔离本身被视为一种安全控制：每个应用程序在专用容器中运行，应用程序之间没有共享的运行时或内存。

这种隔离提供了：

• **租户边界实施：**被盗用的应用程序无法访问来自共享相同环境的相邻应用程序的数据或资源。每个容器都有一个隔离的文件系统和进程空间。通过防火墙和 TLS 配置强制实施网络隔离，并明确限制出站流量，而不是依赖允许的默认值。
• **深入防御：**容器隔离增加了应用程序级控制之外的安全层。即使应用程序代码存在漏洞，容器边界也会限制爆炸半径。
• **合规性细分：**监管的工作负载（例如，PCI 和 HIPAA）可以隔离在专用容器中，防止与不合规的工作负载混合。

设计多应用程序环境的架构师必须依赖容器隔离来强制实施职责和安全域的分离。处理持卡人数据的金融服务集成必须在与市场营销集成分开的容器中运行，即使在相同的环境中。

容器间流量应加密，当监管框架要求双方进行身份验证时，应应用相互 TLS (mTLS)：

工作方式：

• 配置 TLS 上下文，以便在需要时为入站连接启用可选的相互 TLS (mTLS)。
• 使用具有客户端证书身份验证的平台级 SSL，以保护平台服务和副本之间的通信。
• 配置 TLS 上下文，以在监管框架需要时启用 mTLS。
• 通过平台的证书存储管理证书，以便生命周期和撤销保持集中。
• 强制执行网络隔离边界，防止容器之间的未授权流量。

在平台层加密流量为传输中的数据提供深度防御。即使应用程序层 HTTPS 配置错误，容器流量也会保持加密状态。

通过 VPN 连接到本地系统的容器必须针对传输中的数据保护进行架构：

• **隧道加密：**通过加密 VPN 隧道路由容器和内部系统之间的所有流量。无论应用程序层 TLS 如何，这都适用。深度防御可确保敏感数据的双重加密。
• **网络细分实施：**VPN 隧道策略限制本地网络容器可以访问哪些网络。被盗用的容器不能转移到 VPN 允许的网络之外的未经授权的内部系统。
• **合规性证据：**VPN 加密是公认的保护往返于云环境的数据的机制之一。审核 HIPAA、PCI-DSS 或 SOX 控制的审计师预计，混合集成过程中会有文档加密。

架构师必须设计强制实施最低特权网络访问的 VPN 策略。市场营销集成容器不应路由到内部财务系统，即使两者都可以通过 VPN 访问。

虚域（例如，集成 API 的自定义 URL）要求架构师将 TLS 证书作为 Trust 锚进行管理：

虚域（例如，集成 API 的自定义 URL）要求架构师将 TLS 证书作为 Trust 锚进行管理。

• **证书生命周期自动化：**实施自动证书续订和部署。过期证书会破坏集成 Trust；客户端会拒绝带有证书验证错误的连接。
• **证书撤销计划：**为安全事件设计证书轮换程序。泄露的私钥需要在所有地区快速重新颁发证书和部署。
• **密码套件配置：**较旧的 TLS 配置（TLS 1.0/1.1 和弱加密）无法通过合规性审计。强制执行 TLS 1.2+（最低要求），并将证书和客户端配置与组织安全策略保持一致。
• **证书透明度日志记录：**现代 TLS 证书由证书颁发机构 (CA) 提交到公共证书透明度 (CT) 日志。每个 CT 日志返回一个签名证书时间戳 (SCT)，这是一个日志的加密证明，CA 通过 X.509v3 扩展将其嵌入证书。架构师应使用 crt.sh 或自动提醒等服务，针对域监控 CT 日志是否存在未经授权的证书颁发。

证书管理不善直接影响 Trust 状况：

• **过期证书：**导致身份验证失败，显示为中断。监控必须包括在到期前 30 多天内发送警报，以允许续订工作流开始。
• **自签名证书：**断开外部客户端的 Trust 链。生产集成需要由受信证书颁发机构 (CA) 签名的证书。
• **通配符证书蔓延：**指通配符证书过于宽泛（例如 *.company.com），如果它们被盗用，就会产生很大的爆炸半径。每个集成域优先使用窄范围证书。

容器部署区域必须符合数据驻留和合规要求。

• **GDPR 数据驻留：**GDPR 要求对离开欧洲联盟 (EU) 的个人数据进行充分保护，但欧盟部署不会要求这样做。在欧盟地区部署集成会将容器计算和数据处理保持在监管范围内，这是满足此要求的最直接方式。根据适当性决定、标准合同条款 (SCC) 或具有约束力的公司规则 (BCR)，在欧盟以外进行的转移仍被允许。
• **数据本地化法律：**具有数据本地化要求的国家/地区包括：俄罗斯（联邦法律 152-FZ 和强制存储）和中国（PIPL/CSL for CIIO），这可能需要在国内部署集装箱。印度的 DPDP Act of 2023 使用黑名单方法，不强制实施一般的国内存储要求。除非政府通知有特别限制，否则允许向任何国家/地区传输数据。架构师必须了解特定于司法管辖区的法规。
• **跨境数据传输机制：**当需要多区域部署，但数据必须跨越边界时，架构师必须实施 SCC、BCR 或其他法律转移机制。
• **合规性认证一致性：**容器部署区域必须与 Salesforce 合规认证相匹配。FedRAMP 授权的工作负载需要美国地区部署。对于 hitrust 认证的集成，您必须验证部署区域是否在有效的 hitrust 证明范围内。

区域部署决策是架构师的责任，直接影响监管合规。财务团队可能会要求为 SOX 控制的集成部署仅限美国。医疗保健团队可能需要 hitrust 认证的区域来处理个人健康信息 (PHI)。

容器需要访问凭据、API 密钥和加密密钥。架构师必须设计防止泄露的秘密管理流程：

• **无硬编码密码：**请勿在部署到容器的应用程序代码或配置文件中嵌入凭据。使用平台受管密码存储。
• **平台受管密码注入：**在运行时解析来自平台受管存储的密码（而不是将它们持久化到文件系统中），并将持有凭据的配置值标记为受保护，这样它们就不会在日志或控制台中暴露。
• **秘密轮换：**设计集成，以优雅地处理轮换密码。Oauth 令牌刷新模式、API 密钥轮换工作流和数据库密码更改不得要求容器重新部署。
• **最低权限密码访问权限：**仅授予容器对其功能所需的密码的访问权限。市场营销集成不应访问财务系统凭据，即使它们共享相同的环境。

公开的秘密是常见的集成安全事件。架构师必须设计密码处理流程，这些流程可以在代码审查、日志、错误消息和监控仪表板的情况下生存，而不会泄露凭据。

Salesforce 边界处的应用程序生成满足合规日志记录要求的审计事件：

• **请求/响应日志记录：**记录 API 请求、响应和路由决策。合规团队使用这些日志进行访问审计，以确定谁在何时访问哪些数据。
• **错误和异常日志记录：**在容器的日志中捕获安全事件（例如，身份验证失败、授权拒绝和无效证书）。SIEM 集成可实现实时安全监控。
• **日志保留策略：**架构师必须配置满足监管要求的保留期。这些最小值由法规设置，因框架而异，并随着时间的推移而变化，因此它们必须来自维护良好的合规来源，该来源根据监管法规而不是硬编码值来验证每个数字。
• **日志加密和访问控制：**审计日志可能包含敏感元数据。日志必须静态加密，并且仅对授权的安全/合规人员进行访问控制。日志记录不足会阻止事件调查，并使合规审计失败。架构师必须平衡日志记录繁琐性（例如，性能影响和存储成本）与合规性和安全调查需求。

威胁建模必须是设计解决方案的一部分，而不是在此之前或之后发生的单独步骤。只要您有候选设计需要论证，就需要对其潜在威胁进行建模，并随着设计的发展重新访问模型，因此安全性塑造了架构，而不是对其进行改造。虽然 Salesforce 管理基础设施安全性（例如，网络保护、操作系统强化和漏洞管理），但您必须识别配置、集成和自定义代码中的应用程序层风险。将 STRIDE 框架（欺骗、篡改、拒绝、信息披露、拒绝服务、权限提升）应用于下面列出的特定于 Salesforce 的威胁向量。确定数据跨越系统、网络或权限级别的 Trust 边界。

将 STRIDE 框架应用于这些特定于 Salesforce 的威胁建模注意事项：

• 多组织数据流建立额外的 Trust 边界,需要在每次穿越时进行明确的身份验证和授权。
• 外部集成使用 API 和中间件，可能会引入绕过平台安全控制的攻击向量。
• Custom Apex 和 Lightning 组件需要安全编码分析来实施注入、XSS 和访问控制。
• Experience Cloud 站点将攻击范围扩展到未经身份验证或轻度身份验证的用户。
• 第三方和 ISV 代码(例如,受管软件包、AgentExchange 列表、连接的应用程序、第三方连接器、客户端 JavaScript 库和客服人员调用的外部 AI 服务)是在安装时或运行时跨越您的 Trust 边界的供应链向量。

第三方和ISV代码是Trust边界的一部分。

受管软件包或 AgentExchange 列表以您授予的权限在贵组织中运行，因此当您安装时，它们的安全状况将成为您的安全状况。Salesforce 安全审查会在每个列出的软件包到达 AppExchange 或 AgentExchange 之前对其进行检查；您拥有该网关之后的一切：

• 根据您自己的数据分类和风险状况评估软件包
• 授予其文档功能所需的最少权限
• 与发布者的版本保持同步
• 通过您应用到您自己的代码的相同 Event Monitoring 和审计控制来监控其活动。

在解决方案堆栈的每一层应用安全控制。请记住，一个层的折衷决不能暴露整个系统。

设计每个图层，好像上面和下面的图层可能会失败。请谨记，多个独立控件会创建弹性。

Zero Trust 会根据网络位置或之前的身份验证状态消除隐式 Trust。每个请求必须独立进行身份验证和授权。

将 Zero Trust 应用于：

• 通过使用 MFA、会话策略和基于上下文的条件访问（例如，IP、设备、时间和行为）的持续验证进行用户访问
• 通过每次呼叫上的 OAuth 令牌验证、基于证书的相互 TLS 和 IP 允许列表进行集成连接
• 通过显式身份验证进行系统间通信，这也适用于受信内部系统
• 通过每个查询和操作的 CRUD 和 FLS 强制执行进行数据访问，无论调用上下文如何

安全资产清单是安全设计输入：您只能对首次列举的攻击表面进行威胁建模、应用最小权限和监控，因此跟踪与安全相关的资产属于依赖它的设计决策。这与 Operations Excellence 涵盖的操作配置管理不同（例如，版本化组织设置和检测配置偏差以实现操作稳定性）。换句话说，这里的关注范围更窄：哪些资产有安全风险，以及为什么？

维护所有安全相关资产的当前清单，包括存储敏感数据的自定义对象、外部系统集成、面向公众的 API、特权帐户、生产访问权限授予和具有提升权限的已安装软件包。

您的安全资产清单应包括：

• 包含机密或限制数据的自定义对象和字段
• 集成端点和身份验证机制
• 具有提升权限的用户（例如，修改所有数据、查看所有数据和管理用户）
• 仅 API 集成用户及其权限范围
• 外部客户端应用程序 (ECA) 及其 OAuth 范围，以及组织中仍然存在的任何原有连接的应用程序
• 已安装 AgentExchange 软件包及其权限授予
• Experience Cloud 站点及其身份验证和外部共享模型
• 具有提升共享模式的自定义 Apex 类
• 特别注意原有类：在 API 版本 66.0 或早期版本编译的代码，忽略共享声明默认设置为“不共享”（例如，系统模式，绕过运行用户的记录访问权限）。请记住，从 API 版本 67.0 (Summer ‘26) 开始，省略的声明会默认设置为“共享”，数据库操作会在用户模式下运行。但现有类会保留旧行为，直到它们在 v67.0（或更高版本）中重新编译，因此从早期版本继承的未声明类会静默提升。

您有责任设计和配置强制实施最低权限的身份控制。

让我们仔细看看如何使用 PoLP 正确设计和配置控件。

Salesforce 通过 4 个不同的层实施访问控制：组织、对象、字段和记录。您必须设计有意利用所有 4 层的解决方案。核心访问控制是基于授予的，这意味着访问权限是可添加的，用户需要在每一层授予访问权限才能访问记录。核心平台中没有通用的“拒绝覆盖允许”规则，因此您不能锁定目标拒绝来撤销对已经授予的广泛授予的访问权限。

权限较高的层不会降低您的限制能力，但会增加工作量：尽早扩大组织范围的默认设置或对象权限意味着依赖字段级安全性和共享配置来收回本不应授予的访问权限。

限制规则和禁用权限是两个减少访问权限的内置例外，但每个例外的范围都比较窄（对记录级筛选的限制规则和对权限集组内授予的权限的禁用），而不是通用拒绝层。

对于包含敏感数据的对象，将 OWD 设置为专用。将 OWD 设置为公用只读 — 更不用说公用读/写 — 会广泛暴露记录，并削弱您稍后限制访问的能力，而不会进行潜在的重大重组。成熟组织中最常见的 Trust 债务来自初始实施期间设置的宽松 OWD。

记录层遵循“先授予后限制”模型，通常被描绘成共享棱锥图：OWD 设置限制性基准，角色层次结构、共享规则和手动共享从此处向上开放访问权限。两个控件会转换该流，以取消而不是授予访问权限，这两个控件都值得仔细设计。

• 限制规则会筛选用户可在已拥有访问权限的记录中看到的内容，因此拥有宽对象访问权限的用户仍只能看到规则允许的子集。
• 禁用权限会减去权限集小组中的特定权限，因此您可以从可重用小组中汇总访问权限，然后移除给定人群不应拥有的内容。
• 当仅基于授予的层会迫使您过度配置或将访问权限分割成许多狭窄的权限集时，联系这些规则。

对于通过用户界面登录生产环境的所有用户，强制执行 MFA（多重身份验证），Salesforce 将其作为平台要求强制实施。此要求不会扩展到仅 API 访问：使用 JWT 不记名或客户端凭据流的集成除外，因此您需要使用证书管理和 IP 限制来保护这些集成。将 MFA 要求扩展到特权操作。

对于 SSO（单点登录），首选 SAML 2.0 或 OpenID Connect 协议。配置会话策略以平衡安全性和可用性：

• 会话超时:配置适合用户权限级别的会话超时（高权限帐户的更短超时降低了无人参与会话的风险）。
• IP 限制:对管理简档和集成用户实施限制。
• 登录时间:将服务客户限制为预期的操作窗口。
• **设备激活：**依赖 Salesforce 的本地设备激活（对从无法识别的设备登录进行身份验证），并为高权限帐户添加 MFA 和 IP 限制。本地设备 Trust 状况通过外部身份提供商强制执行。
• 会话 IP 锁定:将会话锁定到发起会话的 IP 地址，以便无法从另一个网络位置重放被盗会话 ID。这加强了安全性，但增加了移动用户的摩擦，可能会破坏自动集成 — 如果锁定不可行，请在简档级别强制执行严格的登录 IP 范围，并以“对每个请求强制执行登录 IP 范围”作为补偿控制。
• 高保证会话:对于敏感操作（例如访问报表或管理 IP 范围），通过会话安全级别策略和访问策略，需要高保证会话安全级别，以便常规登录本身无法达到高影响操作。在 Lightning Experience 中，不支持通过重新提示 MFA 将标准会话逐步提升到高保证，因此请确定此策略的范围，因为标准会话用户被阻止进行门控操作，而不是被提示提升。
• 会话 Cookie 保护:需要 HttpOnly 属性，以便脚本无法读取会话 ID Cookie，并将会话锁定到首次使用的域，从而阻止会话劫持。
• 集成用户的仅 API 访问权限:使用仅 API 用户权限将集成和服务帐户限制为仅 API 身份验证，以便它们不能通过用户界面登录。对于新生成，将最低访问权限 - 仅限 API 集成简档与 Salesforce 集成用户许可证进行分配；旧的 Salesforce API 仅限系统集成简档在 Spring ‘24 版本以后配置的组织中不可用，因此根据当前简档而不是弃用的简档设计新的集成。

对于 API 身份验证，选择适合集成模式的 OAuth 2.0 流：

• **JWT 不记名流：**将其用于以集成用户身份运行的服务器到服务器集成（基于证书，受信环境的首选）。
• Web 服务器流（授权代码，带 PKCE）:将其用于需要用户授权的 Web 应用程序，以及需要维护特定用户上下文的服务器到服务器集成（在服务器端存储刷新令牌，以避免重复浏览器提示）。
• **使授权-代码流重放-安全：**强制实施 PKCE，以便除请求授权的客户端外，任何人都无法兑换拦截的授权代码，并轮换刷新令牌（每次使用都会发出新的令牌，并使先前的令牌无效），因此被盗刷新令牌的有效性窗口很窄。重复使用停用的令牌意味着妥协。
• **无头身份验证代码和凭据流（带 PKCE）：**将其用于必须在特定用户的上下文中运行的真正无头、无浏览器客户端 — 基于重定向的 Web 服务器流假设这些客户端没有浏览器。
• **设备流（适用于无头设备）：**请注意,自 2025 年 8 月 28 日起,Salesforce 已永久阻止默认 Salesforce CLI 连接的应用程序的 OAuth 2.0 设备流。将 Web 服务器流（sf 组织登录 web）或 JWT 不记名流（sf 组织登录 jwt）用于 CLI 和 CI/CD 工具。

请勿使用用户名和密码流。Salesforce 默认阻止在 Summer ‘23 或更高版本中创建的组织使用它，并已为此流发布停用计划。仍然依赖于用户名和密码流的现有集成现在应该迁移到 JWT 不记名流或客户端凭据流，而不是将迁移视为延迟的技术债务。

这些流在代表您的集成的应用程序注册上配置。从 Spring ‘26 开始，Salesforce 正在将注册从连接的应用程序转移到外部客户端应用程序 (ECA)：创建新连接的应用程序默认禁用，ECA 是设计新集成的架构。现有连接的应用程序仍保持安装状态；但是，一旦迁移组织，它们将不再处理身份验证，因此在审计集成如何进行身份验证时考虑迁移，而不是将连接的应用程序视为永久模型。

除了选择身份验证流之外，还要创建应用程序可以连接的不同治理：

• **每个集成一个注册：**为每个新集成注册专用的外部客户端应用程序，为每个现有集成注册不同的连接的应用程序。专用注册仅涵盖每个集成所需的 OAuth 范围，而不是在多个集成之间共享一个宽泛的注册，它保持每个集成的访问权限可独立审计和撤销。
• **明确预授权访问权限（推荐）：**将外部客户端应用程序的允许用户策略设置为“管理员批准的用户已预授权”，以便管理员通过简档和权限集授予访问权限，而不是让用户自行授权。管理员直接在“设置”中配置，这是 Salesforce 建议的控制，用于确定谁可以连接。
• **API 访问控制（更严格，基于允许列表）：**为进行更严格的控制，API 访问控制会将管理员批准的用户限制为仅列入允许列表的连接的应用程序。启用它需要向 Salesforce 客户支持提出请求，因此在围绕它进行设计时要计划该步骤，而不是将其作为自助设置来处理。

请勿在代码、配置文件或版本控制中嵌入凭据。使用命名凭据和外部凭据，通过轮换功能集中管理身份验证。

与传统用户身份验证不同，客服人员需要不同的身份模型，正确的模型取决于客服人员是为员工还是为外部用户提供服务。正确设计身份是客服人员安全性的基础：它决定了客服人员可以访问哪些数据以及客服人员可以访问的操作。

让我们仔细看看内部和外部客服人员。

• **员工客服人员（内部）：**在登录用户的上下文中执行任务。他们继承该用户的许可证、权限集、字段级安全性和共享规则，因此没有配置单独的客服人员身份，现有的安全框架控制客服人员可以做什么。
• **客户客服人员（外部）：**通过公共渠道进行交互，并以专用客服人员用户、专用集成用户（而非公共站点来宾用户）的身份运行。以专用集成用户身份运行，可让客服人员执行后端操作并访问数据（未经身份验证的来宾简档无法访问），同时仍受显式最低权限的约束。在创建客户客服人员时，请为新客服人员用户配置最低访问权限，并仅授予操作所需的特定权限。

如果客服人员的工作跨越多个服务，请在每个服务跳中传播用户的身份，而不是返回到共享或来宾身份。Salesforce OAuth 2.0 令牌交换流支持：

客户端显示用户的现有身份提供商令牌，Apex 令牌交换处理器将其映射到 Salesforce 用户并发布 Salesforce 访问令牌，因此原始用户的上下文跟随请求，而不是折叠到服务帐户。通过 Event Monitoring 监控客服人员活动，使用客服人员的用户身份检测异常行为。

选择合适的模型取决于谁发起连接以及工作必须在谁的上下文中运行。

常见连接场景映射到推荐的方法，如下所示：

围绕数据访问需求（用户需要访问其他人拥有的记录）设计角色层次结构，而不是管理报表图表。让角色层次结构深度遵循真正的数据访问关系，而不是添加不授予额外访问权限的级别，因为每个级别都会增加共享计算开销 — 在具有专用 OWD 设置和大数据量的组织中，这种考虑会加重权重。

通过提供灵活的附加访问权限，权限集和权限集组减少了简档扩散的需求。通过权限集和权限集组而不是简档授予功能访问权限，这将保持访问权限的可添加性和可审计性。简档仍有必要：除了登录时间和 IP 限制外，它们还控制页面布局分配、记录类型默认设置和应用程序可见性。将简档视为访问模型的持久部分，而不是要消除的结构。

事务安全性策略不是基准的一部分，而是补充核心授权模型的附加功能：上述身份、角色、简档、权限集和共享控制已经自行建立了安全的授权态势，事务安全性增加了实时上下文评估。配置策略，以检测并阻止异常行为，包括超过正常模式的批量数据下载、从意外地理区域登录以及更改窗口外部的权限更改。

安全控制需要权衡可用性，这是架构的责任。过于宽泛的 IP 限制可能会在网络更改期间锁定合法用户，而过于激进地调整事务安全性策略可能会阻止有效的业务活动，因此将这些控制限定在真正的风险范围内，在实施之前将它们置于仅监控模式中，并为控制失败时设计一条突破路径。

**您的责任：**设计角色层次结构，创建权限集，配置事务安全性策略。

传统的基于角色的访问控制）根据用户的角色授予权限。ABAC（基于属性的访问控制）根据数据、用户和上下文的属性做出授权决策。

对于大多数要求，核心共享模式表示完全访问权限。当访问必须遵循每个记录共享无法表达的数据分类时，联系专用 ABAC：Data 360 ABAC 通过标记和注释提供这一点。

Data 360 ABAC 通过以下方式操作：

• 基于标记的策略，根据应用于数据对象的标记（例如，个人身份信息 (PII)、财务、医疗保健和机密标记）定义访问规则。
• 注释应用于数据对象，以支持基于策略的授权决策。
• 必须明确删除的新组织和现有组织的默认“允许所有”策略，以启用精细治理策略。

其主要架构用途是强制执行数据分类 — 有关分类层如何推动 ABAC 强制执行，请参见数据保护和隐私下的数据分类。

这种粒度级别会带来运营成本。核心共享回答了“谁可以查看此记录，以及为什么？”这个问题，它来自一组小的、可检查的规则（OWD、角色层次结构和共享规则），而 ABAC 在评估时从数据标记、用户属性和上下文的组合中得出答案，因此随着策略和标记的累积，有效访问权限变得越来越难以推理和审计。

将可审计性作为设计要求来强制执行：一致地应用标记，保持策略集较小，并为其强制执行的分类命名，并保留重构用户到达给定记录的原因的能力。为分类驱动的个案保留 ABAC，这些个案是每个记录共享真正无法表达的，而不是将其视为基于所有权的模式的一般替代。

识别并保护具有提升权限的客户，包括系统管理员、集成用户和自动化流程客户。这些客户是攻击者的高价值目标。

对重要影响客户应用增强控制。

• 需要防网络钓鱼 MFA
• 将登录 IP 范围限制为已知管理位置
• 启用登录提醒和权限更改通知
• 对高权限客户进行定期访问审查，其中频率由组织风险容忍和合规要求决定
• 维护紧急访问和使用后审计的打破常规程序

对于集成和服务客户：

• 应用 OAuth 流；从不应用用户名-密码流
• 强制执行 IP 限制
• 实施凭据轮换计划
• 通过 Event Monitoring 监控异常 API 使用模式

**您的责任：**确定重要客户，应用增强控制，进行季度审查。

设计自动化流程，为用户提供适当的初始访问权限，随着角色的发展调整权限，并在不再需要访问权限时立即取消配置。

实施跨域身份管理系统 (SCIM)，以从身份提供商进行自动配置。SAML 或 OpenID Connect 即时配置是在首次登录时创建用户的备选方法，但不会取消配置用户。换句话说，SCIM 是生命周期的支柱，而不是针对生命周期的选择。

身份生命周期包括：

• 配置:创建具有匹配作业功能的基线访问权限的客户，该功能由人力资源系统事件触发。
• 访问权限调整:在角色扩展时授予其他权限，并在角色更改时撤销权限。
• 定期重新认证:每季度查看并验证访问权限。
• 取消配置:在雇用结束或角色不再需要 Salesforce 访问权限时，立即撤销访问权限。

在经理定期审查和验证团队权限时，实施访问权限重新认证流程。审查频率取决于风险和合规要求。

**您的责任：**实施 SCIM，设计配置工作流，每季度进行重新认证。

将数据分为多个组织有时被视为纯粹的成本或驻留决策。从架构上讲，这是一个安全权衡，治理后果属于您的访问权限设计。

隔离是关键的好处。单独的组织提供了数据集之间尽可能强的边界。没有集体共享模式，也没有跨租户权限流失，但对于需要集体共享模式的管辖区，有明确的监管路线。相同的边界会分散治理。您只需要在一个组织中维护一次的每个访问控制（例如，权限集设计、角色层次结构、重要影响客户强化、健康检查基线、事件监控和 SIEM 相关性）现在对每个组织都成倍增长，这意味着它必须保持所有组织的一致性。组织之间的飘移会创建自己的攻击表面，因为在一个组织中收紧而在另一个组织中丢失的权限会创建攻击者可以找到并利用的不一致。跨组织集成增加了以前不存在的经过身份验证的Trust边界。每个跨组织集成都是您需要保护和监控的连接。

因此，在拆分组织之前，权衡隔离的好处与治理乘数非常重要。对于硬本地化要求或客户的合同隔离要求确实无法在单个组织中满足的情况，保留多组织。当您采用它时，您需要设计访问模型、监控和配置基线，以便从一开始就在每个组织中完全强制执行。

**您的责任：**将多组织决策视为安全权衡，而不仅仅是成本权衡。在需要多组织时，在每个组织中一致地强制执行访问控制、监控和健康检查基准，并将每个跨组织集成作为 Trust 边界。

您有责任分类数据、配置加密、设计隐私控制。

让我们仔细看看如何正确保护数据和隐私。

要正确分类数据，您需要了解数据。首要的架构任务是了解您的业务域，并维护一个数据字典，对您保存的数据、它的含义以及敏感数据的生存位置进行编目。您只能对您首先识别的数据进行分类或保护。

建立数据分类方案，推动适当的保护控制。分类标签本身并不保护任何内容。它是对您应用的控件的输入，因此您分配的每个分类都必须映射到具体的加密、访问、保留或监控决策。数据建模期间做出的分类决策直接影响加密要求、访问控制、保留策略和合规义务。

在 Salesforce，我们使用四层方案，该方案提供了一个框架，您可以适应贵组织的法规要求和业务需求。许多企业使用符合行业标准的类似模型（例如 ISO 27001 和 NIST）。您的具体实施应反映您的合规义务（例如，HIPAA、PCI DSS、GDPR 和行业法规）和业务上下文。

在字段级别应用分类。单个客户记录可以包含公用字段（例如公司名称）、机密字段（例如公司收入）和受限字段（例如社会保险编号）。字段级安全性必须反映这些区别。

分类通过基于属性的访问控制强制执行，访问控制读取您分配的标签并应用访问规则。这是一个元数据驱动的层，是对 OWD 和共享规则的补充。

将 ABAC 与您的分类方案保持一致，可以让平台：

• 从分类本身，而不是从每个对象维护的共享规则，限制对标记为**“受限**”或“**机密”**的数据的访问。
• 当记录的分类随时间变化时，调整访问权限。新标记为“**受管”**的记录继承更严格的访问权限，无需手动更改规则。
• 在单个授权决策中，将数据属性（例如分类和灵敏性）与用户属性（例如部门和许可）和上下文（例如时间和位置）结合起来。

设计 ABAC 策略以与此方案保持一致，从而将字段分类为受限是推动其访问控制并使强制与分类保持一致的行为，而不是单独维护共享规则。

**您的责任：**定义分类方案，训练数据建模人员，在设计期间对字段进行分类，配置控制，并将 ABAC 策略与分类层保持一致，以便标记推动实施。

Start从平台已经为每个组织提供的信息开始。静态数据默认加密。Hyperforce 应用卷级加密，通过 Salesforce 拥有和管理的单个密钥保护整个存储卷。此基准始终对您的解决方案开放并透明，但它在容量级别（而不是每个字段）运行，因此选择密钥生命周期内的加密和控制内容取决于平台，而不是您。

当该基准无法满足合规、合同或数据分类义务时，请使用 Shield Platform Encryption。特别是，当您需要卷级加密无法提供的三种功能之一时：

• 控制密钥生命周期，以便您可以自行生成、轮换和撤销密钥材料
• 标准字段、自定义字段、文件和附件静态加密的选择性
• 呈现 Salesforce 无法访问的数据的能力。

受限数据和受明确监管密钥控制要求的数据（例如，HIPAA、PCI DSS 和 GDPR）是通常的触发器。基准已经涵盖了所有其他内容的基础架构级保护。

Shield Platform Encryption 在字段级加密，它提供了两种以安全性换取可查询性的方案。

概率加密是一种强大的默认方案，但使用它加密的字段不能用于筛选条件、排序或聚合函数（例如，MAX()、MIN() 和 COUNT_DISTINCT() 函数）。

确定性加密在报表、列表视图和 SOQL WHERE 子句中启用精确匹配筛选 — 区分大小写或不区分大小写 — 降低了强度，因为相同的明文总是产生相同的密文。

我们建议默认使用概率方案加密，并为您必须筛选或排序的特定字段保留确定性加密。在数据建模设计期间评估这些权衡，包括对公式字段引用、报表聚合和 SOQL 操作的影响。

客户控制的密钥有两种不同的形式：

• 自带密钥 (BYOK) 允许您使用自己的加密库、企业密钥管理系统或硬件安全模块在 Salesforce 之外生成密钥材料，并将其提供给平台。
• 仅缓存密钥服务将数据加密密钥保存在您控制的密钥服务中。Salesforce 按需获取，而不是存储。

这两种表单都允许您根据自己的计划轮换和销毁密钥材料。销毁密钥材料会使它保护的数据不可恢复，这是一种强大的、有意的控制，而不是例行公事。记录密钥轮换和撤销程序也很重要。

所有集成必须使用 TLS 1.2 或更高版本（Salesforce 平台强制实施），但您需要为处理受限数据的集成实施基于证书的相互身份验证（使用您自己的配置）。

**您的责任：**决定平台的数量级基准在何处足够，合规、合同或分类义务在何处保证 Shield Platform Encryption，然后选择加密方案，选择并操作客户控制的密钥策略，并为敏感集成实施基于证书的身份验证。

使用防止受限数据进入 Sandbox 的策略，保护非生产环境中的敏感数据。

• 部分 Sandbox 复制会将受限数据从 Sandbox 刷新中排除。
• 数据屏蔽规则通过使用保留数据特征的模式来混淆 Sandbox 中的敏感字段值。
• 合成数据生成适用于不需要生产数据的开发环境。
• Sandbox 模板定义了要包含在每种 Sandbox 类型中的对象和字段。

设计合规性测试是一项架构责任。根据具有现实特征的合成数据构建开发和测试周期，以便团队可以根据类似生产的条件进行验证，同时监管数据保持在生产边界内。

**您的责任：**设计 Sandbox 策略，配置 Data Mask 规则，生成合成测试数据。

通过架构决策设计尊重用户隐私的解决方案。

• **数据最小化：**仅收集声明业务目的所需的数据。通过询问“什么架构决策需要这些数据？”来挑战每个字段添加。请记住，最安全的数据是您从未收集的数据。
• **目的限制：**设计在技术上强制执行目的限制的数据访问模式。使用权限集和共享规则，以根据作业功能的目的限制对数据的访问权限。例如，市场营销用户不应访问支持个案详细信息，除非他们的工作需要。
• **同意管理：**在个人层面实施同意跟踪，以进行市场营销、分析和可选数据处理。设计在集成系统中传播的同意撤销工作流。换句话说，同意是精细的，并且特定于目的。
• **数据主体权利：**为访问请求（例如，提供数据副本）、更正（例如，更正不准确之处）、删除（例如，在法律允许的情况下删除数据）和可移植性（例如，导出为机器可读的格式）构建工作流。设计这些工作流，以便在每个管理框架规定的响应期限内完成。这些截止日期因司法管辖区而异，并且会定期修改，因此重要的是从维护的合规来源参数化工作流的 SLA，并根据管理法规确认每个窗口（而不是硬编码单个值）。

**您的责任：**通过最小化设计数据模型，按目的配置访问权限，实施同意工作流，构建数据主体权利自动化。

数据驻留是您在配置前做出的架构决策选择，而不是您随后切换的设置。Hyperforce 提供区域部署 — 但仅存在 Salesforce 操作的区域 — 组织的驻留位置在配置时固定。您的责任是确定每个数据类别必须驻留的位置，确认合适的区域是否可用，并设计合法跨境的数据传输机制。

重要的是，在开始之前对您的驻留义务进行分类，而不是默认设置为国内存储。

• **强制本地化。**少数司法管辖区要求某些数据在国家边界内（有时，这仅适用于受监管的部门）。当 Salesforce 不在国内区域运行时，本地存储无法单独满足任务，因此您需要数据驻留叠加或该数据的单独组织。由于此列表可能会发生变化，因此根据监管条例确认特定任务非常重要。
• **基于问责制的框架。**大多数制度不会强制实施本地化要求。他们对具有适当跨境转移机制的区域中心感到满意。在这些情况下，决策取决于哪个区域最大限度地减少了延迟并简化了合规性。

当数据跨越边界时，重点是配置前的认识。换句话说，您需要知道哪些转移发生以及基于什么法律依据，然后设计访问权限，以便端到端地控制数据。在存在适当性决策的地方，适当性决策的摩擦最小。具有约束力的公司规则 (BCR) 和标准合同条款 (SCC) 涵盖了大多数剩余的转移。仅将明确同意用作最后手段。

将转移机制与限制性记录访问权限配对（例如，专用 OWD 和专用范围的共享），以便允许的转移不会变得过于宽泛。文档数据流映射，以显示每个数据类别的起源、传输和驻留位置。当法规或区域可用性发生变化时，重新访问它们。

**您的责任：**按数据类别分类居住义务，在配置前确认区域可用性，为跨境流选择转移机制（充足性、BCR/SCC），并记录数据流图。

您有责任设计解决方案来保持平台提供的合规状况。

此指导是定向的。监管要求因司法管辖区而异，并随着时间的推移而变化。您必须始终根据部署的管理法规（例如，适用的法规、监管机构或 Salesforce 合规文档）来验证特定的义务。

Salesforce 维护广泛的合规认证（可在 trust.salesforce.com 和 compliance.salesforce.com 获得）：SOC 2 Type II、ISO 27001、FedRAMP（适用于 Government Cloud 产品）、HIPAA、PCI DSS 和区域认证。这些认证涵盖了 Salesforce 对平台基础设施和共享服务的责任。

平台认证减轻了您的合规负担，但它们不会免除您的架构责任。您的自定义对象、Apex 代码、集成和配置必须保持平台提供的合规状况。

**您的责任：**设计保持合规性的解决方案，记录架构如何满足监管要求。

• 对包含受保护健康信息的所有字段启用 Shield Platform Encryption (PHI)。
• 对于 HIPAA 合规性，通过保留策略启用字段审计跟踪，以满足 HIPAA 的记录保留要求。根据管理条例确认当前期间。
• 配置事件监控，以检测未经授权的 PHI 访问模式。
• 实施 HIPAA 安全规则要求的所有技术保护措施，包括访问控制、审计日志记录和传输安全性。

• 通过权限集设计实施职责分离 (SoD)，以防止单个用户创建和批准财务交易。
• 对于 PCI 环境，避免在 Salesforce 中存储完整的主要客户编号 (PAN)，以最小化 PCI DSS 合规范围。
• 在可能时，使用付款网关令牌化。

• 对于 GDPR 和 LGPD，设计同意管理，捕获特定于目的的精细选择加入同意。
• CCPA/CPRA 遵循选择退出模式。提供明确机制，以选择退出出售或共享个人信息，而不是基于目的的同意。
• 构建在每个框架的响应截止日期内完成的数据主体权利工作流，并根据管理法规进行确认。
• 实施数据保留自动化，在同意到期时清除数据。

• 将 Salesforce Government Cloud 用于监管的政府工作负载。
• 实施映射到 Salesforce 配置的 NIST 800-53 控制。
• 通过路由到政府 SIEM 基础设施的事件监控启用连续监控。

**您的责任：**根据监管要求配置 Shield、字段审计跟踪、职责分离、同意管理、数据保留。

数据保护和隐私法规在不同司法管辖区差异很大，具体义务变化很快，因此这一级别需要决策，而不是按国家/地区列表。

两个架构杠杆是驻留和跨境转移，它们包含在数据保护和隐私中。

要遵守这些条例，您必须：

• 分类每个数据类别必须驻留的位置
• 在配置前，请确认存在适当的区域
• 为跨境数据设计合法的传输机制。

有关更多信息，请查看数据驻留和主权，了解有关决策框架的更多详细信息。

除此之外的所有内容都被视为一个时间点数字（例如，辖区使用哪个同意模型、数据主体请求的截止日期、违反后通知监管机构或受影响个人的窗口，以及审计记录的最小保留期）。这些数字由法规设定，因框架而异，并根据监管机构的时间表进行修正。

请勿在此处硬编码。您需要根据部署的管理法规确定后续步骤（或引用一个法规的维护合规源），并将设计调整到操作足迹最紧的时段。

以下是设计中包含的持久架构后果。

• 临时手动流程无法满足以个位数天衡量的数据主体请求截止日期，因此，当您在任何截止日期较短的司法辖区内操作时，您需要自动履行 DSR。将 Experience Cloud 用于接收，将 Service Cloud 用于个案跟踪，将隐私中心用于发现，并将流用于履行。
• 违反通知窗口太紧，无法随机应变，因此您需要提前构建违反响应工作流。确定 Event Monitoring 异常规则、预分配的角色、预起草的监管者和数据主体通知，以及假设占用空间最紧的截止日期的升级路径。单个通知通常由高风险确定触发，因此您需要在工作流中包含风险评估。
• 一些司法管辖区要求或建议在国内保留审计日志（最少保留几年），因此您需要将 SIEM 保留的大小调整到足迹内最长的最小保留，并确认日志是否离开司法管辖区。

**您的责任：**根据数据保护和隐私设计驻留和转移，将 DSR 和违约响应工作流自动化到占用空间最紧的最后期限，并根据管理法规确认每个特定于司法管辖区的数字，而不是写入本指南的值。

设计用于持续合规性验证，而不是时间点审计准备。

• 安全健康检查根据 Salesforce 安全基准评估配置，并提供风险分数。定期运行检查，以监控遵守 Salesforce 安全基准建议的情况。保持 80% 或更高的分数（非常好或非常好）。
• Event Monitoring 会捕获用户活动、API 调用、身份验证事件和数据访问模式的详细日志。将事件日志文件路由到外部 SIEM，以进行超过本机保留限制的长期保留。
• 事务安全性根据策略实时评估事件，它可以阻止事件、要求增加 MFA 或通知您违反策略。

在部署漏斗中自动化合规检查非常重要，以验证部署不会削弱权限模型、禁用审计设置或引入不合规配置。

**您的责任：**每季度运行一次健康检查，将 Event Monitoring 路由到 SIEM，配置事务安全性策略，并在 CI/CD 中自动进行合规性验证。

根据合规要求、调查需求和保留义务，设计审计跟踪策略。

对于受监管的环境，通过外部 SIEM 集成实施 Event Monitoring，以实现长期日志保留和跨系统关联。设计字段审计跟踪策略，涵盖受监管记录保留要求约束的所有受限和机密字段。

**您的责任：**为敏感字段启用字段审计跟踪，将 Event Monitoring 路由到 SIEM，配置事务安全性策略。

您有责任在整个开发过程中集成安全性，而不是事后考虑。

在尽可能早的开发阶段集成安全实践。架构阶段的威胁建模可以防止设计级别的漏洞。与功能要求一起捕获的安全要求可防止您将安全性视为事后的想法。

当在生产中而不是在设计或开发阶段发现安全缺陷时，修复它们的成本要高得多。架构审查期间发现的设计级安全缺陷可能只需要一次对话就可以修复。但在生产中发现相同缺陷时，需要重新架构、数据迁移、合规性补救和潜在违规通知。

这就是为什么我们实践左移安全性，它侧重于：

• 在设计完成之前进行威胁建模
• 用户数据趋势图中的安全要求
• 为开发人员提供安全的编码培训
• 集成到 IDE 中的静态分析
• 注重安全的代码审查
• CI/CD 中的自动安全测试
• 生产部署前的安全验证

**您的责任：**进行威胁建模，培训开发人员，在 CI/CD 中集成代码分析器，需要安全意识的代码审查。

在 Salesforce 上下文中设计常见漏洞的防御措施非常重要。让我们仔细看看我们如何映射到 Salesforce 的 2025 OWASP 前 10 名。

• **A01:2025 - 访问控制中断：**在所有 Apex 数据访问中，以编程方式强制执行 CRUD 和字段级安全性 (FLS)。
  • 在 API 版本 67.0 或更高版本中，Apex 默认在用户上下文中运行，这意味着当前用户的权限和 FLS 会在代码执行期间强制执行。
    • WITH SECURITYENFORCED 已删除，这将导致编译错误。使用 USER_MODE 替换任何现有使用。该平台在标准 UI 中强制执行访问权限。
  • 在 API 版本 66.0 或早期版本中，系统模式是默认设置。在 SOQL 查询中使用 WITH USERMODE，或在 DML 操作中使用 Security.stripInaccessible()。
• **A01:2025 - 客户端数据 API：**Lightning 数据服务和 UI API 会自动强制执行运行用户的 FLS、CRUD 和共享，因此，基于它们的组件默认继承的权限最少。
  • 当组件调用自定义 Apex 时，此保护将丢失。强制 Apex 仅在用户模式下运行时强制执行访问权限，因此，未共享声明的类充当了静默绕过模型的转义掩码。
  • 使用 Lightning 数据服务和 UI API 进行数据访问。
  • 对于组件中的每个必要 Apex 调用，您必须重新声明 CRUD、FLS 和共享。
• **A02:2025 - 安全配置错误：**使用运行状况检查，监控配置偏离安全基线的情况。
  • 禁用来宾用户对 Experience Cloud 站点的访问权限（除非文档化业务理由明确要求）。
• **A05:2025 - 注射：**2025 注入类别涵盖了 SOQL/SOSL 注入和跨站点脚本 (XSS)。
  • 对于查询注入，请对所有动态查询使用绑定变量。切勿将用户输入直接连接到查询字符串中。平台的参数化查询机制在正确使用时消除了注入风险。
  • SOQL 或 SOSL 注入的范围是披露调用者不应通过扩大查询条件而到达的记录或字段的读取。由于这些语言读取数据，而写入通过单独的 DML 操作运行，这就造成了访问控制和机密性风险，因为在查询上没有强制实施对象和字段权限时，这就加剧了风险。
  • 对于 XSS，Lightning Web 组件通过 LWC 渲染引擎提供自动保护。
  • 对于 Aura 组件和 Visualforce，您需要在呈现动态内容时应用平台编码函数（例如 HTMLENCODE、JSENCODE 和 URLENCODE）。

**您的责任：**在自定义代码中强制执行 CRUD/FLS，应用编码函数，使用绑定变量，监控配置偏差。

在每个阶段设计带有安全门的 CI/CD 漏斗。安全性必须自动化，以随着开发速度扩展。

让我们仔细看看漏斗安全阶段。

• 源控制使用具有所需代码审查的分支保护规则。没有直接提交到主要分支或签名提交。
• 静态分析使用 Salesforce 代码分析器，它结合了 PMD、ESLint 和 RetireJS 来检测注入、XSS 和不安全模式。
• 安全扫描使用 SAST 工具和密码检测来防止凭据提交和依赖漏洞扫描。
• 权限验证使用自动比较技术根据安全基准检查权限更改，这将发送有关权限扩展的警报。
• 对于需要安全团队批准权限扩展更改的关键安全发现，部署网关会中断部署。
• 部署后监控对部署后的异常行为使用 Event Monitoring 警报。

**您的责任：**在 CI/CD 中集成代码分析器，配置分支保护，实施部署网关，自动验证权限。

综合安全测试包括解决不同漏洞类别的多种技术。让我们仔细看看每个策略。

• 静态分析在开发人员 IDE 中运行 Salesforce 代码分析器以获取即时反馈，并在 CI/CD 漏斗中作为自动网关运行。静态分析在不执行应用程序的情况下识别源代码中的漏洞。
• 渗透测试对不可信用户公开的自定义应用程序进行渗透测试，特别是 Experience Cloud 站点和面向公众的 API。
  • 对于 AppExchange 和 AgentExchange 安全审查，始终需要静态分析报告。
  • 当解决方案集成第三方 Web 应用程序或服务时，需要动态扫描报表（渗透测试）。
  • 渗透测试模拟对实时应用程序的攻击者技术。
• 注重安全的单元测试编写 Apex 测试,通过以具有不同权限简档的用户身份运行来验证访问控制的实施。验证 CRUD/FLS 强制阻止未经授权的访问非常重要。
• 依赖扫描会监控 AgentExchange 软件包和 JavaScript 库是否存在已知漏洞。订阅已安装软件包的安全建议非常重要。

**您的责任：**运行代码分析器，执行渗透测试，编写安全单元测试，扫描依赖性。

在 Salesforce，安全和数据事件响应侧重于检测、遏制并从泄露、未经授权的访问和恶意数据破坏中恢复。事件响应团队与两个承担相邻责任的相邻支柱一起工作：

• 卓越运营涵盖了事件管理的操作机制（例如，严重级别、随叫随到的轮换、上报和事件后审查）
• 可靠性涵盖了针对 RTO 和 RPO 目标的可用性恢复，包括备份和灾难恢复策略。

作为架构师，您有责任设计安全事件的可检测性、响应和恢复。

可检测性是您必须明确设计的架构质量。如果没有全面的监控，安全事件可能会长时间得不到发现。

通过多个渠道实施检测非常重要。

• Event Monitoring 会捕获涵盖登录、报表和数据导出、权限更改和 API 调用的原始事件日志。您需要识别哪些事件异常，这需要事务安全性策略或 SIEM 相关性在您配置的日志之上来确定检测逻辑。
• 事务安全策略实时评估事件，并阻止可疑操作。您需要配置这些策略。
• 设置审计跟踪会跟踪平台提供的管理更改，但您需要对其进行监控。
• 自定义应用程序日志记录捕获您需要实施的 Apex 中与安全相关的事件。

将 Event Monitoring 日志路由到 SIEM 平台，以与企业安全遥测进行关联。设计检测可疑模式的警报规则，同时通过行为基线最大限度地减少误报。

**您的责任：**将 Event Monitoring 路由到 SIEM，配置事务安全性策略，实施自定义日志记录，建立行为基线。

在事件发生之前记录支持事件响应的架构决策非常重要。

• 隔离边界设计解决方案，隔离受损组件，而不会中断关键业务功能。您需要配置权限集撤销、IP 限制更改和会话终止，以提供快速隔离功能。
• 取证保留使用 Event Monitoring 提供详细的活动日志（平台功能）。字段审计跟踪根据您的配置保留数据更改历史记录。设计路由到不可变存储的日志，以便攻击者无法修改您的架构。
• 恢复程序记录了常见事件类型的测试恢复过程。定期验证备份完整性非常重要。您需要了解安全事件场景的恢复时间目标 (RTO) 和恢复点目标 (RPO)。
• 通信工作流设计在事件期间发挥作用的通知机制(例如,不依赖于潜在受损系统的带外通信渠道、预起草模板和升级程序 ) 。
• 漏洞披露渠道适用于面向公众的 Experience Cloud 站点。它通过 RFC 9116 security.txt 标准中发布的披露策略，为外部研究人员提供了一种有文档记录的、受监控的方式来向您报告安全问题。外部报表通常是事件的第一个信号，因此重要的是将此接收路径建立为您负责的架构的一部分。

**您的责任：**记录隔离程序，将日志路由到不可变的外部存储，每季度测试恢复程序，建立带外通信，并为面向公众的站点发布漏洞披露渠道。

在 Salesforce，为特定于平台的场景准备响应功能非常重要。

• 通过 Event Monitoring 登录异常（例如，意外的地理位置、异常的时间和新设备），检测到盗用用户帐户。当帐户被盗时，冻结用户，强制重置凭据，查看设置审计跟踪和数据访问日志以确定盗用期。
• 通过 Event Monitoring 报表导出和 API 数据访问量异常，检测批量数据泄漏。当发生数据泄露时，立即撤销会话，限制权限，并识别受影响的记录和分类级别。
• 通过部署监控和设置审计跟踪配置更改，检测到未授权代码部署。在部署未经授权的代码时，立即回滚部署，并审核已泄露部署凭据中的所有更改。
• 通过设置审计跟踪监控，检测批准更改窗口之外的权限更改的权限升级。当权限升级时，立即撤销升级的权限，并审核使用升级的访问权限执行的活动。

**您的责任：**记录特定于平台的场景的响应程序，配置监控以检测每个场景，通过桌面练习测试程序。

在事件发生后，重要的是进行没有判断力的事后审查，重点关注架构改进。您需要记录发生了什么，为什么现有控制无法防止或检测事件，以及需要什么架构更改来降低未来的风险。

事件后审查目标：

• 确定事件时间线和攻击者技术。
• 识别启用事件的控制失败。
• 记录事件揭示的所有架构弱点。
• 优先考虑基于风险降低的补救措施。
• 在团队之间共享经验教训。
• 更新检测规则和响应程序。

随着时间的推移跟踪事件度量以确定平均检测时间 (MTTD)、平均响应时间 (MTTR) 和影响范围非常重要。

**您的责任：**进行及时的事件后审查，记录发展成果评估的改进，跟踪中期发展报告和中期贸易报告的趋势，分享经验教训。

在架构审查期间、生产部署之前，使用此核对清单，并定期进行持续评估。每个项目都代表您作为 Salesforce 架构师的责任。

分担责任

• 记录 Salesforce 保护的一切内容（例如，基础设施、平台和合规认证）。
• 记录您必须保护的一切内容（例如，配置、访问权限、自定义代码和数据治理）。
• 确定分担责任的领域（例如，事件响应、漏洞管理和监控）。
• 尽可能简明扼要地向利益相关者和实施团队传达责任。

安全架构

• 在开始构建之前，使用 STRIDE 方法完成威胁建模。
• 在数据、应用程序、身份和集成层应用深度防御控制。
• 实施零信任原则，这些原则要求对每个访问请求进行明确验证。
• 维护涵盖敏感数据、集成、API 和特权客户的当前安全资产清单。
• 在 ADR 中记录安全架构决策，包括威胁分析和控制理由。
• 通过传播每个用户的身份而不是池令牌，在 Salesforce Trust 边界保护无头和代表客户端。
• 通过外部客户端应用程序存储、轮换和最小权限范围的 OAuth 凭据。
• 对于容器化集成，将容器隔离作为安全边界，使用 mTLS 加密容器间和混合 VPN 流量（当框架需要时），并将部署区域与数据驻留和合规认证保持一致

身份和访问权限管理

• 对于包含敏感数据的对象，将 OWD 设置为专用。
• 对于拥有广泛读取访问权限是文档要求的对象，保留公用只读权限。
• 对所有生产 UI 访问权限强制执行 MFA，并对特权帐户强制执行硬件安全密钥。使用 JWT 不记名或客户端凭据的仅 API 集成除外。
• 使用 SAML 2.0 或具有强 IdP 身份验证的 OpenID Connect 实施 SSO。
• 对于所有 API 身份验证，使用 OAuth 2.0（JWT 不记名首选）。切勿将 OAuth 2.0 用于嵌入凭据。
• 通过基于记录的最低权限要求的权限集授予访问权限。
• 对重要影响客户应用增强控制（例如，IP 限制、登录提醒和定期访问审查）。
• 使用记录证明对高权限客户进行定期访问审查，其中频率由组织风险容忍度和合规要求决定。
• 通过 SCIM 配置和 90 天休眠客户检测，自动化身份生命周期。
• 在登录用户的上下文中运行员工客服人员，并为客户客服人员配置专用的、最低权限的客服人员用户。请勿对公共站点来宾用户执行此操作。
• 使用客服人员实例和机器人定义标识符，为客服人员身份验证实施 JWT。
• 定义与数据分类和一致的元数据标记标准一致的 ABAC 策略。

数据保护和隐私

• 分类所有数据，并应用适合每个分类级别的保护控制。
• 使用记录的密钥管理为受限数据启用 Shield Platform Encryption。
• 对于所有与基于证书的身份验证的集成，对于受限数据，需要 TLS 1.2+。
• 通过屏蔽或排除，防止受限数据进入非生产环境。
• 通过细化的目的跟踪和撤销工作流实施同意管理。
• 构建在每个管理框架的响应截止日期内完成的数据主体权利工作流。这些数据应调整到运营足迹的最紧窗口，并从维护的合规来源对每个辖区进行参数化，其中每个数字都根据监管条例进行确认。
• 记录数据驻留要求，并验证 Hyperforce 区域对齐。

合规性和合规性

• 验证满足行业监管要求的平台认证。
• 通过 SIEM 路由启用 Event Monitoring，以保留超出本机保留限制的内容。
• 配置字段审计跟踪，以涵盖受限字段，确保保留符合最低监管要求。
• 保持安全运行状况检查得分为 80% 或更高（非常好或非常好），并记录任何异常。
• 对于在重大违反期间中断的 CI/CD 漏斗，自动化合规性验证。
• 实施事务安全性策略，以进行实时异常检测和响应。

安全开发生命周期

• 在设计阶段（在大量构建投资之前）进行威胁建模。
• 在所有 Apex 环境中实施 CRUD/FLS。
• 对于 API 版本 67.0 或更高版本，依赖自动用户模式实施，或者对于 API 版本 66.0 或更高版本，使用 WITH USERMODE 或 stripInaccessible()。
• 请勿使用 SECURITYENFORCED，它在 API 版本 67.0 中移除。
• 在重要发现阻止部署时，在 CI/CD 中运行 Salesforce Code Analytics。
• 对于所有生产更改，需要安全意识审查员进行代码审查。
• 对所有面向公众的应用程序和 Experience Cloud 站点进行渗透测试。
• 验证并清理所有阻止跨 SOQL、SOSL 和 HTML 上下文注入的用户输入。

安全事件响应

• 设计 Event Monitoring 警报规则，通过行为基线检测可疑模式。
• 将日志路由到不可变的外部存储，以便进行取证保留。
• 记录并测试特定于平台的场景的事件响应程序。
• 使用 ADR 进行无可指责的事件后审查，以获取架构改进。
• 跟踪 MTTD 和 MTTR 度量，以确定检测和响应差距。

分享您对良好架构框架的反馈。