---
schema_version: "1"
id: a21bbe8da4377d4c55c7525441c02bce22ffb61ce27d247477e185c12af582e6
title: Trust - 监管合规和审计模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/trust-compliance-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/trust-compliance-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 661424175b83acf6f78f351ce8f2788e9a55c0c2c687f723444645888c6a6a0b
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# Trust - 监管合规和审计模式

<br>

了解更多关于 Well-Architected [Trust](/docs/architect/zh-cn/well-architected/guide/trust.html) → [Compliance and regulatory Compliance](/docs/architect/zh-cn/well-architected/guide/trust.html#compliance-and-regulatory-adherence)

## 共享责任模型

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 基础设施合规性  | ✅ 利用 Trust.salesforce.com 和 compliance.salesforce.com 提供的 Salesforce 平台认证(SOC 2 Type II、ISO 27001、FedRAMP for Government Cloud 产品、HIPAA、PCI DSS)作为基础设施和共享服务的合规证据。 |
| 自定义解决方案合规性 | ✅ 设计自定义对象、Apex 代码、集成和配置，以保持平台认证提供的合规性。 |
| 自定义解决方案合规性 | ✅ 文档架构合规性控制。 |
| 责任边界  | ✅ 文档清晰划分：Salesforce 提供合规基础设施（物理、网络、平台安全性、多租户隔离）；架构师设计合规解决方案（数据分类、访问控制、加密配置、安全编码、数据处理合规）。 |
| 合规文档 | ✅ 维护架构文档，显示自定义实施如何满足监管要求，映射到平台认证。 |
| 合规文档 | ✅ 创建合规矩阵链接法规→平台控制→自定义控制。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 基础设施合规性 | 假设平台认证意味着您没有合规责任。 |
| 基础设施合规性 | 未能为自定义解决方案实施适当的访问控制、加密或数据处理合规性。 |
| 基础设施合规性 | ⚏ 平台认证减轻了合规性负担，但不会消除架构责任。 |
| 责任边界 | 不清楚 Salesforce 责任的结束位置和客户责任的开始位置。 |
| 责任边界 | 将自定义实施中的合规差距归咎于平台。 |
| 合规文档 | 监管要求和实施的控制之间没有文档化的映射。 |
| 合规文档 | ⚏ 在审计发现期间扰乱以收集证据。 |

## 特定于行业的监管要求

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 医疗保健 (HIPAA) | ✅ 为包含受保护健康信息 (PHI) 的所有字段启用 Shield Platform Encryption。 |
| 医疗保健 (HIPAA) | ✅ 实施现场审计跟踪，保留期满足 HIPAA 的记录保留要求（根据管理法规确认当前期间）。 |
| 医疗保健 (HIPAA) | ✅ PHI 仅在执行的业务关联协议 (BAA) 涵盖的 Salesforce 服务上存储和处理；解决方案设计和 PHI 数据流根据 BAA 的范围进行验证。 |
| 医疗保健 (HIPAA) | ✅ 配置 Event Monitoring，以检测未经授权的 PHI 访问模式。 |
| 医疗保健 (HIPAA) | ✅ 实施技术保障:访问控制、审计日志、传输安全性(TLS 1.2+、PHI 集成的基于证书的相互身份验证)。 |
| 金融服务（SOX、DORA、PCI DSS） | ✅ 通过权限集设计实施职责分离，防止单个用户同时创建和批准财务交易。 |
| 金融服务（SOX、DORA、PCI DSS） | ✅ 通过设置审计跟踪和自定义变更日志维护变更审计跟踪。 |
| 金融服务（SOX、DORA、PCI DSS） | ✅ 避免在 Salesforce 中存储完整的主要客户编号 (PAN) - 通过付款处理器对持卡人数据进行令牌化，以减少 PCI DSS 范围；如果必须存储 PAN，请使用 PCI DSS 控制下的加密自定义字段。 |
| 金融服务（SOX、DORA、PCI DSS） | ✅ 设计欺诈检测模式的交易监控。 |
| 金融服务（SOX、DORA、PCI DSS） | ✅ DORA 需要运营弹性，包括事件响应和第三方风险管理。 |
| 隐私条例（GDPR、CCPA、LGPD） | ✅ 对于 GDPR 和 LGPD，设计同意管理捕获粒度特定于目的的选择加入同意（市场营销、分析、个性化）；对于 CCPA/CPRA，提供个人信息销售或共享的选择退出机制。 |
| 隐私条例（GDPR、CCPA、LGPD） | ✅ 构建数据主体权利工作流（访问、更正、擦除、可移植性），在响应窗口中完成部署的管理法规集。 |
| 隐私条例（GDPR、CCPA、LGPD） | ✅ 实施数据保留自动化，在同意到期或法律依据结束时清除数据。 |
| 隐私条例（GDPR、CCPA、LGPD） | ✅ 每个数据处理活动的文件法律依据。 |
| 隐私条例（GDPR、CCPA、LGPD） | ✅ GDPR 需要书面说明理由、数据流映射、隐私影响评估。 |
| 政府 (FedRAMP) | ✅ 将 Salesforce Government Cloud 用于监管的政府工作负载。 |
| 政府 (FedRAMP) | ✅ 实施映射到 Salesforce 配置的 NIST 800-53 控制。 |
| 政府 (FedRAMP) | ✅ 通过路由到政府 SIEM 基础设施的事件监控，启用连续监控。 |
| 政府 (FedRAMP) | ✅ FedRAMP 需要通过持续监控进行持续授权，而不仅仅是初始认证。 |
| 多辖区 | ✅ 将数据驻留要求映射到 Hyperforce 区域部署。 |
| 多辖区 | ✅ 执行国际数据传输的标准合同条款或具有约束力的公司规则。 |
| 多辖区 | ✅ 记录数据流图，显示出发地、中转地和居住地。 |
| 多辖区 | ✅ 当单个组织内无法满足相互冲突的驻留要求时，考虑多组织架构。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 医疗保健 (HIPAA) | 依赖策略将 PHI 存储在标准加密字段中，以防止未经授权的访问。 |
| 医疗保健 (HIPAA) | 没有字段审计跟踪或审计保留计划。 |
| 医疗保健 (HIPAA) | 在没有适当访问控制的情况下，在报表、列表视图或 Experience Cloud 中公开 PHI。 |
| 医疗保健 (HIPAA) | 允许基于短信的 MFA 进行 PHI 访问（易受 SIM 交换的影响）。 |
| 金融服务（SOX、PCI DSS） | 允许单个用户创建和批准财务交易（无职责分离）。 |
| 金融服务（SOX、PCI DSS） | 在没有加密或 PCI DSS 控制的标准 Salesforce 自定义字段中存储完整的主要客户编号 (PAN)。 |
| 金融服务（SOX、PCI DSS） | 没有用于欺诈检测的交易监控。 |
| 金融服务（SOX、PCI DSS） | 没有记录财务系统修改的变更审计跟踪。 |
| 隐私条例（GDPR、CCPA） | 将同意视为二进制的“是/否”，而不是粒度化的目的跟踪。 |
| 隐私条例（GDPR、CCPA） | ⚏ 通过法律团队手动处理数据主题请求需要几个月时间，并错过了部署的管理法规集的响应窗口。 |
| 隐私条例（GDPR、CCPA） | 数据处理活动没有成文的法律依据。 |
| 隐私条例（GDPR、CCPA） | 收集数据“以防万一”，没有记录的目的限制。 |
| 政府 (FedRAMP) | 对于需要 FedRAMP 合规的政府工作负载，使用标准 Salesforce 组织。 |
| 政府 (FedRAMP) | 没有连续的监控或 NIST 800-53 控制映射。 |
| 多辖区 | 没有数据流映射来显示数据的传输和驻留位置。 |
| 多辖区 | 假设单个全球组织满足所有区域数据驻留要求。 |
| 多辖区 | 没有国际数据传输的法律依据文档。 |

## 持续合规监控

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 安全健康检查 | ✅ 运行季度评估，将组织配置与 Salesforce 安全基准进行比较。 |
| 安全健康检查 | ✅ 保持 80% 或更高的分数（非常好或非常好）。 |
| 安全健康检查 | ✅ 记录异常，包括业务理由和低于基准的设置的补偿控制。 |
| 安全健康检查 | ✅ 运行状况检查识别安全最佳实践的配置偏差。 |
| 事件监控 | ✅ 启用 Event Monitoring，以捕获用户活动、API 调用、身份验证事件、数据访问模式的详细日志。 |
| 事件监控 | ✅ 将事件日志文件路由到外部 SIEM，以进行超过本机保留限制的长期保留。 |
| 事件监控 | ✅ 合规性通常需要多年的日志保留；请确认针对部署的管理法规的最低期限。 |
| 事务安全性 | ✅ 实施事务安全性策略，实时评估事件，并阻止、要求 MFA 升级或通知策略违规。 |
| 事务安全性 | ✅ 用于预防性控制，在发生违规之前停止违规（例如，阻止超出正常模式的批量数据导出，敏感字段访问需要逐步身份验证）。 |
| 自动合规性验证 | ✅ 在 CI/CD 部署漏斗中实施合规性检查，验证部署不会削弱权限模型、禁用审计设置或引入不合规配置。 |
| 自动合规性验证 | ✅ 中断未通过合规验证的部署 — 合规验证应该是部署网关，而不是部署后发现。 |
| 持续审计就绪 | ✅ 设计持续审计准备，而不是时间点审计准备。 |
| 持续审计就绪 | 合规是一种持续运营状态，需要持续的证据生成，而不是年度认证争夺。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 安全健康检查 | 仅在审核员请求时运行运行状况检查。 |
| 安全健康检查 | 允许分数在 80% 以下浮动，无需调查。 |
| 安全健康检查 | 对于低于基准的设置，没有记录的异常。 |
| 安全健康检查 | ⚠ 永远不要补救已识别的风险。 |
| 事件监控 | 在法规要求多年保留时，依赖本地保留限制作为合规证据。 |
| 事件监控 | 没有外部 SIEM 路由。 |
| 事件监控 | 允许本地 Event Monitoring 保留过期，并丢失审计证据。 |
| 事务安全性 | 没有实时的预防性控制。 |
| 事务安全性 | 仅依赖于事件后调查，而不是在发生之前阻止策略违反。 |
| 自动合规性验证 | 部署漏斗中没有合规性检查。 |
| 自动合规性验证 | 部署后发现生产中的违规。 |
| 自动合规性验证 | ⚠ 允许部署削弱安全状况，无需审核。 |
| 持续审计就绪 | 将合规性视为需要几个月的审计准备混乱的年度事件。 |
| 持续审计就绪 | 没有持续的证据生成。 |
| 持续审计就绪 | 在审核期间发现差距，如果补救为时已晚。 |

## 审计跟踪架构

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 设置审计跟踪 | ✅ 通过 180 天的保留期监控管理配置更改（包含在所有版本中）。 |
| 设置审计跟踪 | ✅ 定期审查未经授权的更改。 |
| 设置审计跟踪 | ✅ 用于配置管理控制的合规性证据。 |
| 字段审计跟踪 | ✅ 为需要监管记录保留的受限和机密字段启用。 |
| 字段审计跟踪 | ✅ 配置保留以满足合规性要求（支持无限期保留）；根据部署的管理法规确认所需的期限。 |
| 字段审计跟踪 | ✅ 需要 Shield。 |
| Event Monitoring 长期保留 | ✅ 将 Event Monitoring 日志路由到外部 SIEM，以进行超出本机保留限制的保留。 |
| Event Monitoring 长期保留 | ✅ 在法规要求保留多年日志时，需要合规证据。 |
| Event Monitoring 长期保留 | ✅ 为跨系统调查配置与企业安全遥测的相关性。 |
| 事务安全性 | ✅ 对用户操作实施基于策略的实时评估（无保留、触发事件）。 |
| 事务安全性 | ✅ 用于需要立即响应的预防性控制（例如，阻止禁止的操作，需要逐步身份验证，触发事件响应工作流）。 |
| 事务安全性 | ✅ 需要 Shield 许可证。 |
| 自定义应用程序日志           | ✅ 为平台审计跟踪未捕获的安全相关应用程序事件实施自定义 Apex 日志记录：业务逻辑授权决策、可疑输入模式、速率限制实施、自定义身份验证事件。 |
| 日志完整性 | ✅ 将审计日志路由到攻击者无法修改的不可变外部存储，即使具有 Salesforce 管理访问权限。 |
| 日志完整性 | ✅ 法医证据必须经过篡改,以支持调查和潜在的法律程序。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 设置审计跟踪 | 切勿查看设置审计跟踪，了解未经授权的管理更改。 |
| 设置审计跟踪 | 在证据过期（180 天保留）数月后发现恶意配置更改。 |
| 字段审计跟踪 | 对于受监管记录限制的数据，没有字段审计跟踪。 |
| 字段审计跟踪 | 配置的保留期短于管理法规要求的部署时间。 |
| Event Monitoring 长期保留 | 仅依赖本地 Salesforce 保留窗口作为合规证据。 |
| Event Monitoring 长期保留 | 当日志已经过期时，在审计准备期间发现差距。 |
| Event Monitoring 长期保留 | 与跨系统调查的企业安全遥测没有关联。 |
| 事务安全性 | 没有针对高风险操作的实时策略评估。 |
| 事务安全性 | ⚠ 仅在发生几天或几周后通过手动日志审查发现策略违规。 |
| 自定义应用程序日志 | 没有自定义业务逻辑授权决策或安全相关应用程序事件的日志。 |
| 自定义应用程序日志 | 无法调查授权失败或可疑模式，因为不存在证据。 |
| 日志完整性 | 仅在管理员可以修改或删除的 Salesforce 中存储审计日志。 |
| 日志完整性 | 没有不可变的外部副本进行取证保存。 |
| 日志完整性 | 失去法律程序的监管链。 |

## 数据驻留和主权

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Hyperforce 区域部署 | ✅ 在组织配置期间选择适当的 Hyperforce 区域，以满足数据驻留合规性。 |
| Hyperforce 区域部署 | Hyperforce 提供区域部署选项，使数据驻留符合要求数据保持在特定地理边界内的法规。 |
| 数据流映射 | ✅ 记录数据流图，显示数据的来源、经过（集成中间件、外部服务）和驻留（存储区域）。 |
| 数据流映射 | ✅ GDPR 第 30 条处理活动记录必填。 |
| 国际转移 | ✅ 在 GDPR 和类似法规要求的情况下，实施国际数据传输的标准合同条款或具有约束力的公司规则。 |
| 国际转移 | ✅ 每次跨境转移的文件法律依据。 |
| 适用于冲突需求的多组织 | ✅ 在跨多个司法管辖区运营时，考虑多组织架构，这些司法管辖区的居住要求相互冲突，无法在具有 Hyperforce 区域部署的单个组织中满足。 |
| 适用于冲突需求的多组织 | ✅ 权衡:多组织提供了最强的数据隔离性,但增加了操作复杂性、许可成本、集成要求。 |
| 多组织治理 | ✅ 对于多组织架构，通过共享配置即代码存储库、跨组织监控、统一身份管理，在组织之间保持一致的安全基线。 |
| 多组织治理 | ✅ 多组织提供了最强的隔离性，但增加了治理表面积。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Hyperforce 区域部署 | 为全局组织选择默认美国地区，而不评估数据驻留要求。 |
| Hyperforce 区域部署 | 通过不当的区域选择，违反 GDPR、LGPD 或区域数据主权法律。 |
| 数据流映射 | 没有记录的数据流图。 |
| 数据流映射 | 无法回答审计员关于数据传输或驻留位置的问题。 |
| 数据流映射 | 没有 GDPR 第 30 条处理活动的记录。 |
| 国际转移 | 无需标准合同条款、具有约束力的公司规则或成文的法律依据即可在国际上传输数据。 |
| 国际转移 | 违反 GDPR 转移限制。 |
| 适用于冲突需求的多组织 | 将冲突的数据驻留要求强制纳入导致违反合规性的单个组织。 |
| 适用于冲突需求的多组织 | 或者，当具有 Hyperforce 区域部署的单个组织满足要求时，实施多组织架构（不必要的复杂性）。 |
| 多组织治理 | 跨多组织环境的安全基线不一致。 |
| 多组织治理 | 每个组织实施安全性的方式不同。 |
| 多组织治理 | 无法在整个组织中展示一致的合规状况。 |

## 安全状况管理

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 安全健康检查季度 | ✅ 每季度运行一次健康检查，将组织配置与 Salesforce 安全基准（密码策略、会话设置、网络访问、功能配置）进行比较。 |
| 安全健康检查季度 | ✅ 目标得分为 80% 或更高（非常好或优秀）。 |
| 安全健康检查季度 | ✅ 记录例外情况，说明业务理由，并对低于基准的设置进行补偿控制。 |
| Event Monitoring Analytics | ✅ 设计仪表板，揭示需要调查的行为模式：异常数据访问量、非工作时间管理活动、API 消耗异常。 |
| Event Monitoring Analytics | ✅ 行为分析检测基于签名的检测错过的威胁。 |
| 自动漂移检测 | ✅ 在漏斗中实施自动化合规测试，检测配置偏离批准的基准。 |
| 自动漂移检测 | ✅ 配置偏离安全标准时报警。 |
| 连续态势监控 | ✅ 在没有主动管理的情况下，安全状况会随着配置偏差、权限累积、新漏洞的出现而下降。 |
| 连续态势监控 | ✅ 设计用于持续监控，而非时间点评估。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 安全健康检查季度 | 仅在审核员请求时运行运行状况检查。 |
| 安全健康检查季度 | 允许分数在 80% 以下而不进行补救。 |
| 安全健康检查季度 | 没有随时间跟踪姿势趋势。 |
| Event Monitoring Analytics | 启用 Event Monitoring，但没有仪表板、没有警报、没有异常调查。 |
| Event Monitoring Analytics | 将审计日志视为合规性复选框，而不是安全遥测。 |
| 自动漂移检测 | 没有自动检测配置偏离批准的基准。 |
| 自动漂移检测 | 仅在更改后几个月的手动审计期间发现配置弱化。 |
| 连续态势监控 | ⚠ 将安全性视为时间点认证，而不是连续操作状态。 |
| 连续态势监控 | ⚏ 为年度审计做准备，因为不存在持续监控。 |

## 架构审查委员会安全集成

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 安全审查时间 | ✅ 在重大构建投资之前，在建议书阶段将安全审查集成到架构审查委员会 (ARB) 中。 |
| 安全审查时间 | ✅ 开发结束时的安全审查已经太晚，无法影响根本的设计决策。 |
| 架构决策记录 | ✅ 记录 ADR 中的安全架构决策，包括安全要求、评估的替代方案、接受的权衡、剩余风险、补偿控制、监控方法。 |
| 架构决策记录 | ✅ ADR 提供审计证据，支持 Knowledge 转移，并通过记录决策原因支持架构发展。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 安全审查时间 | 仅在开发完成后执行安全审查。 |
| 安全审查时间 | 在构建基本完成时，发现需要重新架构的基本安全缺陷。 |
| 安全审查时间 | ⚏ 安全在事后变得昂贵。 |
| 架构决策记录 | 没有安全架构决策的文档。 |
| 架构决策记录 | 无法解释为何选择某些控制措施，评估了哪些替代方案，接受了哪些剩余风险。 |
| 架构决策记录 | 缺少审计证据和Knowledge转移。 |

## 供应链和第三方风险

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 采用前安全评估 | ✅ 审查 AppExchange 安全审查状态（范围、上次审查日期 — 安全审查过期）、评估权限要求（软件包是否需要更多访问权限而不是功能证明？）、评估数据处理实践（数据流在哪里、外部保留什么、数据发送到第三方服务？）、审查供应商事件响应功能和通知程序，了解退出程序和数据可移植性。 |
| AppExchange 权限审查 | ✅ 请求修改所有数据、查看所有数据或敏感权限的软件包需要额外检查。 |
| AppExchange 权限审查 | ✅ 记录提升权限的业务理由。 |
| AppExchange 权限审查 | ✅ 评估软件包功能是否真正需要授予范围。 |
| 第三方库存            | ✅ 通过风险评级、记录的风险接受决策、定期审查节奏，维护第三方依赖性（AppExchange 软件包、集成服务、中间件）的清单。 |
| 安全咨询监控 | ✅ 订阅已安装软件包和集成服务的安全建议。 |
| 安全咨询监控 | ✅ 监控新漏洞、需要补丁的版本更新、影响环境的供应商安全事件。 |
| 持续监控 | ✅ 通过 Event Monitoring 监控软件包行为，了解安装后意外的数据访问模式或 API 调用异常。 |
| 持续监控 | ✅ 软件包以提升的权限运行，并需要持续的安全监控。 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 采用前安全评估 | 仅根据功能安装 AppExchange 软件包，而不评估权限范围、数据访问模式、供应商安全实践、退出程序。 |
| 采用前安全评估 | 接受权限过大的软件包，无需仔细检查。 |
| AppExchange 权限审查 | 授予请求修改所有数据或查看所有数据的软件包，而不怀疑功能是否真正需要该范围。 |
| AppExchange 权限审查 | ⚏ 没有提升权限的书面业务理由。 |
| 第三方库存 | 没有第三方依赖性的清单。 |
| 第三方库存 | 无法回答审计员关于第三方数据访问的问题。 |
| 第三方库存 | ⚏ 没有已安装软件包的风险评级或审查计划。 |
| 安全咨询监控 | 不要监控影响已安装软件包或集成服务的安全建议。 |
| 安全咨询监控 | 在披露数月或数年后，仍容易受到已知漏洞的攻击。 |
| 持续监控 | 安装软件包，不要监视它们的行为。 |
| 持续监控 | 无法检测软件包是否被盗用或开始访问超出原始范围的数据。 |
| 持续监控 | 没有适用于软件包 API 活动的 Event Monitoring。 |
