数据保护模式


了解有关 Well-Architected Trust → 数据保护和隐私的更多信息

模式

何处查看好样的
数据分类方案✅ 分类方案按级别记录（公用、内部、机密、受限）
✅ 为每个分类级别提供的业务示例
✅ 符合监管义务的分类方案（HIPAA、PCI DSS、GDPR）
✅ 数据建模人员经过培训，能够在设计期间一致应用分类
✅ 分类为数据建模过程一部分的新字段，不追溯
字段级分类✅ 在字段级别应用分类，而不仅仅是对象级别
✅ 单个对象中的字段可能有不同的分类
✅ 字段级安全性反映分类差异
✅ 未分类数据默认设置为最高适当保护级别
✅ 分类推动保护控制（加密、访问、保留）
自定义对象和字段✅ 所有自定义对象都有文档化的数据分类
✅ 敏感字段（工资、SSN、PHI、付款数据）分类为机密或受限
✅ 公用字段（公司名称、网站）记录为公用
✅ 字段描述中捕获的分类元数据
✅ 在代码审查和 ARB 期间审查的分类
标准对象✅ 根据分类方案评估的标准对象字段
✅ 为受限标准字段启用 Shield Platform Encryption
✅ 应用于机密标准字段的字段级安全性
✅ 报表和列表视图已筛选，以防止敏感标准字段泄露
集成数据✅ 通过实施前分类的集成流动的数据
✅ 外部系统数据敏感度评估并记录
✅ 使用基于证书的身份验证处理受限数据的集成端点
✅ 跨系统边界保留数据分类
合规性映射✅ HIPAA PHI 字段已识别并标记为受限
✅ 尽可能避免在 Salesforce 中使用 PCI 持卡人数据 — 通过付款网关进行令牌化以减少范围；在必须存储时，使用 PCI DSS 控制下的加密自定义字段
✅ GDPR 个人数据已识别并受隐私控制
✅ SOX 财务数据分类，并须遵守职责分工

反模式

何处查看什么不好的样子
统一保护⚠ 适用于所有字段的相同保护，不论敏感程度如何
低价值数据过度保护（浪费资源），而高价值数据保护不足
上市公司信息与 PHI 或付款卡数据相同
⚠ ⸏ 每个字段加密“只是为了安全”而没有分类依据
追溯分类⚏ 部署到生产后分类的数据
通过合规审计而不是设计审查发现的敏感数据
⚏ 仅在安全事件后分类的数据
⚠ 开发期间的默认设置是“我们稍后会找出分类”
仅对象级分类⚠ 当字段具有不同的灵敏性时，整个对象被统一分类
授予对象级访问权限，但没有敏感字段的字段级安全性
客户或联系人对象上的所有字段假定具有相同的分类
对象权限用作混合敏感对象的唯一访问控制
部落Knowledge分类未记录，仅存在于关键人员的 Knowledge 中
开发人员依赖于“只知道”哪些字段敏感
没有可供所有数据建模人员访问的书面分类方案
⚠ 新团队成员未接受分类培训

模式

何处查看好样的
静态加密✅ 所有数据通过 Hyperforce 在基础设施级别加密
✅ 为受限数据启用 Shield Platform Encryption
✅ 根据查询和唯一性要求选择的加密方案（概率性、确定性、区分大小写确定性）
✅ 在数据模型设计期间评估加密权衡
Shield Platform Encryption策略✅ 大部分受限字段使用概率加密（支持所有查询操作）
✅ 确定性加密用于需要精确匹配 WHERE 子句或唯一性的字段
✅ 区分大小写的确定性用于区分大小写对业务逻辑很重要的情况
✅ 在生产部署前测试的加密字段行为
✅ 对加密字段的公式字段引用已适当处理（如果需要，移到 Apex）
密钥管理✅ 钥匙轮换程序记录并自动化
✅ 灾难恢复演习期间测试的关键销毁场景
✅ 评估客户受管密钥 (BYOK) 的合规性，需要明确的密钥控制
✅ 密钥撤销过程已记录
✅ 根据合规要求管理的加密密钥生命周期
正在加密✅ 所有集成都需要 TLS 1.2 或更高版本
✅ 基于证书的相互身份验证，适用于处理受限数据的集成
✅ 为 Experience Cloud 站点配置的 HSTS 标头可防止协议降级
✅ TLS 证书过期已监控，并配置自动续订
✅ 弱密码和协议被禁用
代码和配置✅ 从未嵌入代码、配置文件或版本控制的凭据
✅ 用于集中管理身份验证的命名凭据和外部凭据
✅ 架构中内置的凭据轮换功能
✅ 命名凭据从代码中抽象身份验证，无需更改代码即可实现更新
AppExchange 软件包✅ 安装前评估软件包安全要求
✅ 加密字段仅在业务合理时可供软件包访问
✅ 通过 Event Monitoring 监控的软件包数据访问模式
✅ 需要访问受限数据的软件包，需要增强审核

反模式

何处查看什么不好的样子
无评估加密在所有字段上启用概率加密，无需测试
生产中发现的关键报表失败，因为加密字段无法聚合
在公式字段源上启用加密，但不了解影响
⚏ SOQL LIKE 查询中使用的字段加密，无需切换到确定性加密
嵌入凭据嵌入代码、自定义设置或版本控制的凭据
在 Apex 类中硬编码的 API 密钥、密码和证书
提交到源控制存储库的凭据
存储在自定义元数据或自定义设置中的凭据，无需加密
弱协议或原有协议接受 TLS 1.0 或 1.1（已弃用和易受攻击）
在 JWT 不记名可用时允许用户名-密码 OAuth 流
生产集成中接受自签名证书
禁用证书验证“以使集成正常工作”
无密钥管理启用 Shield Platform Encryption，无需密钥轮换程序
⚠ 没有记录的密钥销毁场景
⚠ 使用的默认密钥没有评估客户管理的密钥的合规性
⚏ 从未测试过的密钥轮换和撤销程序
过度加密⚏ 公共或内部分类数据加密，增加了成本，但没有好处
在每个字段上启用 Shield Platform Encryption，造成不必要的复杂性
在合规性不需要时使用 BYOK（增加运营开销）
⚠ 在数据分类无法证明的情况下强制加密

模式

何处查看好样的
Sandbox 策略✅ 受限数据永远不会进入开发或测试环境
✅ 部分 Sandbox 复制不包括受限对象和字段
✅ Sandbox 模板定义按环境类型包含哪些对象和字段
✅ Data Mask 为需要类似生产的数据的 Sandbox 配置
Data Mask 规则Data Mask 规则在保留数据特征的同时模糊敏感字段
✅ 模式保持引用完整性（相同的输入产生相同的屏蔽输出）
✅ 电子邮件地址已屏蔽，但仍为有效测试格式
✅ 电话号码已屏蔽，但保持有效格式
✅ 转移的日期一致保持相对关系
✅ 在现实范围内随机化的数字字段
合成数据✅ 开发环境使用合成数据生成
✅ 合成数据具有现实特征，可实现有效测试
✅ 开发不需要生产数据
✅ 开发漏斗中的测试数据自动生成
非生产环境✅ 生产数据从未复制到个人开发人员组织
✅ 使用屏蔽或合成数据的屏幕捕获和演示
✅ 培训环境使用合成数据或严重屏蔽的生产数据
✅ 承包商和供应商对非生产数据的访问权限仅限于仅供业务使用分类

反模式

何处查看什么不好的样子
Sandbox 中的生产数据使用未屏蔽的生产数据刷新的完整 Sandbox，用于开发
⚏ 为方便起见，将受限数据复制到 Developer Sandbox
开发人员被授予对生产数据 Sandbox 的广泛访问权限
使用敏感数据刷新的 Sandbox“因为使用真实数据测试更容易”
无合成数据所有测试仅依赖生产数据
无需为开发环境生成合成数据
假设“我们需要真实数据”，而没有评估合成替代方案
⚠ 自动生成时创建的手动测试数据

模式

何处查看好样的
数据最小化✅ 仅收集声明业务目的所需的数据
✅ 每个字段添加都面临着“什么架构决策需要这些数据？”的挑战
✅ 数据不再用于收集目的
✅ 可选字段标记清楚，无需业务证明即可使用
✅ 历史数据保留符合法律依据，而不是“永远保留一切”
目的限制✅ 权限集根据作业功能目的限制数据访问
✅ 市场营销用户无法访问没有文档证明的支持个案详细信息
✅ 销售用户无法访问客户服务历史记录，除非作业需要
✅ 跨职能数据访问需要明确批准和监控
✅ 权限集描述中记录的数据访问目的
同意管理✅ 在个人级别捕获的同意，用于市场营销、分析、可选处理
同意是粒度的（特定于目的），而不是二元一揽子同意
✅ 同意撤销工作流在集成系统中传播
✅ 使用时间戳、版本和机制跟踪同意决策
✅ 同意 UI 清楚地解释了用户同意的内容
数据主体权利✅ 访问请求工作流在为您的部署设置的管理法规的期限内提供数据副本
✅ 纠正工作流通过审计跟踪纠正不准确之处
✅ 擦除工作流会在法律允许的情况下删除数据（考虑保留义务）
✅ 可移植性工作流以机器可读的格式导出数据
✅ 定期测试数据主体权利工作流，以验证时间线
✅ 工作流自动化可确保始终满足监管时间表
隐私控制✅ 隐私控制在技术上强制执行，而不仅仅是通过策略
✅ 共享规则实施目的限制
✅ 字段级安全性保护敏感属性
✅ 审计跟踪捕获隐私相关事件
✅ 隐私控制在 CI/CD 漏斗中验证

反模式

何处查看什么不好的样子
收集所有内容⚠ ⸏ “收集所有可能的数据，我们有一天可能需要它”方法
添加的字段没有记录的业务目的
⚏ 数据无限期保留，没有保留理由
通过使字段成为必填字段收集的可选数据
完全同意⚠ ⸏ 出于所有目的的单一“同意条款”同意
⚏ 市场营销同意与单个复选框中的服务交付相结合
⚠ 在目的可分时同意“全有或全无”
同意书以 20 页的条款和条件嵌入
没有强制执行的策略隐私政策描述了技术上未强制执行的理想实践
依赖用户培训来防止不适当的数据访问
无需实施技术控制即可记录隐私原则
⚠ 假设没有监控和验证的策略合规性
手动数据主题请求通过手动 IT 票证处理的 GDPR/CCPA 请求需要几个月时间
⚠ 没有关于访问、纠正、擦除、可移植性的文件化程序
错过了部署管理法规集的请求完成窗口
请求在审计期间发现的工作流不存在
数据共享过多⚠ 授予跨部门的广泛数据访问权限，无需任何正当理由
市场营销允许访问支持个案详细信息
⚏ 销售允许访问客户服务历史，无需记录需求
用于包含个人数据对象的公共读/写 OWD

模式

何处查看好样的
Hyperforce 区域部署✅ 在 Hyperforce 区域中配置的组织满足数据驻留要求
✅ 数据存储和处理发生在所需的地理边界内
✅ 在配置前记录并验证区域要求
✅ 必要时通过多组织架构满足多区域要求
数据流映射✅ 数据流映射数据来源、传输和驻留位置的文档
✅ 根据法规确定和评估跨境数据传输
✅ 国际转让的标准合同条款或具有约束力的公司规则
✅ 评估驻留合规性的数据传输路径，而不仅仅是存储位置
数据驻留范围✅ 数据存储位置（Hyperforce 区域）
✅数据处理位置（计算区域）
✅ 备份存储位置
✅ 记录和审计跟踪存储位置
✅ 评估跨境数据移动的集成传输路径
多组织架构✅ 在单个组织内无法满足监管要求时使用的多组织架构
✅ 每个组织在其数据的适当区域中配置
✅ 集成模式遵守数据驻留约束
✅ ADR 记录了运营复杂性权衡
合规性验证✅ 按管辖区记录的数据驻留要求
✅ Hyperforce 区域选择在配置前根据要求进行验证
✅ 定期审计确认数据保持在要求的边界内
✅ 对居住条例的更改会触发架构审查

反模式

何处查看什么不好的样子
驻地监督合规审计期间发现的数据驻留违规
⚠ 配置的组织未评估区域要求
假设“云是云”，而不考虑数据位置法规
⚠ 添加的司法辖区未审查居住义务
忽略居住地的中转仅考虑存储位置，忽略传输路径
⚏ 通过合规边界之外的区域路由的数据
⚏ 在不兼容区域使用的集成中间件
⚏ 存储在与主数据不同区域的备份
不必要的多组织在具有 Hyperforce 区域的单个组织足够时，使用多组织架构
⚏ 操作复杂性、许可成本和集成开销成倍增加，无需监管
⚠ 多组织实施的“只是为了安全”而没有特定的合规要求
在数据分类和访问控制足够时，默认使用多组织