共享责任模型 - 模式
了解更多关于 Well-Architected Trust → The Shared Responsibility Model
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 安全性 | ✅ 架构设计假设物理数据中心安全、监控和环境保护措施由 Salesforce(或适用于 Hyperforce 的 AWS)处理 |
| 平台 | 安全性 | ✅ 网络安全设计利用平台提供的 DDoS 缓解和入侵检测系统,无需重复投资 |
| 平台 | 安全性 | ✅ 所有传输中 (TLS 1.2+) 和静态 (AES-256) 的流量加密均由平台基础设施提供 |
| 平台 | 安全性 | ✅ 平台强化、漏洞管理和补丁部署是 Salesforce 的责任;架构师围绕计划的维护时段进行规划 |
| 平台 | 安全性 | ✅ 确保数据分离的多租户安全性和租户隔离架构是平台提供的保证 |
| 平台 | 合规性 | ✅ 平台合规性认证(SOC 1/2/3、ISO 27001/27017/27018、FedRAMP for Government Cloud 产品、HIPAA、PCI DSS、GDPR)可在 Trust.salesforce.com 和 compliance.salesforce.com 获得 |
| 平台 | 安全性 | ✅ 平台加密服务和备份基础架构是架构师利用的平台管理功能,无需实施责任 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 安全性 | 架构设计包括自定义物理安全控制、网络周边防御或操作系统级加固,复制平台提供的功能 |
| 平台 | 安全性 | 安全审查静态平台加密或网络安全问题,无需咨询 Trust。现有控制的salesforce.com 文档 |
| 平台 | 合规性 | 合规性评估重新审核平台基础设施安全控制,而不是利用现有的 SOC 2/ISO 认证 |
| 平台 | 安全性 | 架构负责修补平台基础设施或管理多租户隔离 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 身份 | ✅ 身份和访问权限管理(角色、简档、权限集、MFA、SSO、最低权限)由架构师设计和配置 |
| 平台 | 身份 | ✅ 用户生命周期管理和访问权限重新认证流程通过记录的季度审查实施 |
| 平台 | 数据 | ✅ 数据治理包括分类、屏蔽、对象/字段/记录级安全性、CRUD 权限和共享规则是架构师的责任 |
| 平台 | 集成 | ✅ 集成安全性(OAuth 2.0、JWT 身份验证、命名凭据、安全端点、外部系统验证)由架构师设计和维护 |
| 平台 | 安全性 | ✅ 监控和响应功能(事件监控、审计跟踪、SIEM 集成、事件响应程序)由架构师实施 |
| 平台 | 开发 | ✅ 应用程序安全性,包括安全自定义代码(Apex、Lightning)、输入验证、注入防护和安全开发实践,是架构师和开发人员的责任 |
| 平台 | 合规性 | ✅ 解决方案通过隐私/同意管理、数据保留策略和符合监管要求的合规配置来保持合规状态 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 身份 | 身份和访问权限管理被视为“平台安全性”,无需设计角色、简档、权限集或 MFA 要求 |
| 平台 | 数据 | ⚠ 假设数据治理是平台提供的;未配置数据分类、共享规则或字段级安全性 |
| 平台 | 集成 | 集成安全性依赖于网络级控制,无需实施 OAuth、凭据管理或端点验证 |
| 平台 | 安全性 | 监控和事件响应被视为 Salesforce 的职责;不存在 Event Monitoring、SIEM 集成或响应程序 |
| 平台 | 开发 | 自定义代码安全性未验证;注入漏洞、缺少 CRUD/FLS 实施和不安全模式累积 |
| 平台 | 合规性 | 合规配置从未实施;解决方案违反了监管要求,尽管通过了平台认证 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 合规性 | ✅ 合规文档中引用的平台认证(SOC 2 Type II、ISO 27001、FedRAMP for Government Cloud 产品、HIPAA、PCI DSS、GDPR)涵盖了基础设施的责任 |
| 平台 | 合规性 | ✅ 审计准备利用 trust.salesforce.com 和 compliance.salesforce.com 文档进行平台基础设施控制 |
| 平台 | 合规性 | ✅ 合规性文档清楚地描述了平台提供的认证与架构师实施的自定义解决方案的控制 |
| 平台 | 架构 | ✅ 自定义对象、Apex 代码、集成和配置旨在保持平台提供的合规性 |
| 平台 | 合规性 | ✅ 架构文档明确映射自定义解决方案如何在利用平台认证的同时满足监管要求 |
| 平台 | 合规性 | ✅ 区域认证和合规要求推动了组织配置期间的 Hyperforce 区域选择 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 合规性 | 假设平台认证涵盖了所有合规义务;未实施自定义解决方案控制 |
| 平台 | 合规性 | 审计准备尝试重新审计平台基础设施控制,而不是引用现有认证 |
| 平台 | 架构 | 自定义代码、配置和集成违反了合规性要求,尽管平台拥有适当的认证 |
| 平台 | 合规性 | 合规文档未将平台认证与架构师实施的控制明确分开 |
| 平台 | 合规性 | 架构缺少文档映射,无法说明自定义解决方案如何在利用平台认证的同时保持合规性 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 安全性 | ✅ 事件响应程序文档协作:Salesforce 提供平台检测和响应;架构师提供解决方案级检测和响应 |
| 平台 | 安全性 | ✅ 漏洞管理责任已明确记录:Salesforce 补丁平台;架构师修补自定义代码和已安装软件包 |
| 平台 | 安全性 | ✅ 安全监控将平台生成的事件 (Event Monitoring) 与架构师配置的分析、警报和响应工作流相结合 |
| 平台 | 架构 | ✅ Trust 支柱中的每个设计原则、主题部分和核对清单项目都被视为共享责任模型中的架构师责任 |
| 平台 | 安全性 | ✅ 设计决策明确引用分担责任模型边界,区分平台提供的控制和架构师配置的控制 |
| 平台 | 架构 | ✅ 架构决策记录记录了安全控制、合规性要求和事件响应的责任边界 |
| 平台 | 安全性 | ✅ 安全审查验证架构师的责任(配置、访问控制、自定义代码)是否在平台提供的基础上适当实施 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 安全性 | 事件响应程序假设 Salesforce 处理所有方面;不存在解决方案级别的检测、响应或恢复功能 |
| 平台 | 安全性 | 漏洞管理不解决自定义代码;仅考虑平台补丁 |
| 平台 | 安全性 | 安全监控完全依赖于平台本地工具,无需架构师配置的分析或响应工作流 |
| 平台 | 架构 | 设计决策未引用共享责任模型;对于谁负责确保 |
| 平台 | 架构 | 架构决策记录忽略责任边界;安全假设是隐式而非显式的 |
| 平台 | 安全性 | 安全审查假设平台认证消除了架构师的安全责任 |
模式
| 何处查看 | 好样的 |
|---|---|
| 医疗保健 | HIPAA | ✅ 为包含受保护健康信息 (PHI) 的所有字段启用 Shield Platform Encryption |
| 医疗保健 | HIPAA | ✅ 字段审计跟踪配置为保留,满足 HIPAA 对 PHI 访问跟踪的记录保留要求(根据管理法规确认当前期间) |
| 医疗保健 | HIPAA | ✅ 事件监控被配置为通过路由到安全团队的警报来检测未经授权的 PHI 访问模式 |
| 医疗保健 | HIPAA | ✅ HIPAA 安全规则要求的技术保障(访问控制、审计日志、传输安全性)通过架构师配置实施 |
| 财务 | SOX/PCI | ✅ 通过权限集设计实现职责分离,防止单个用户创建和批准财务交易 |
| 财务 | PCI DSS | ✅ 尽可能将完整的主要客户编号 (PAN) 排除在 Salesforce 之外,并通过付款处理器进行令牌化,以减少范围;在必须存储 PAN 的地方,它使用 PCI DSS 控制下的加密自定义字段 |
| 隐私 | GDPR/CCPA | ✅ 同意管理通过精细的按用途的同意跟踪和撤销工作流实施 |
| 隐私 | GDPR/CCPA | ✅ 数据主体权利工作流(访问、更正、擦除、可移植性)在响应窗口中完成部署的管理法规集 |
| 隐私 | GDPR/CCPA | ✅ 数据保留自动化会在同意到期或保留期结束时清除数据 |
| 政府 | FedRAMP | ✅ Salesforce Government Cloud 用于需要 FedRAMP 合规的受监管政府工作负载 |
| 政府 | FedRAMP | ✅ NIST 800-53 控件映射到 Salesforce 配置,并为每个适用控件提供了文档化实施 |
| 政府 | FedRAMP | ✅ 使用 Event Monitoring 进行连续监控会路由到政府 SIEM 基础设施,以进行实时威胁检测 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 医疗保健 | HIPAA | PHI 存储在没有 Shield Platform Encryption 或字段审计跟踪的标准加密字段中 |
| 医疗保健 | HIPAA | 事件监控未配置为检测未经授权的 PHI 访问;违规发生时未检测到 |
| 财务 | SOX/PCI | 单个用户可以创建和批准财务交易;不强制职责分离 |
| 财务 | PCI DSS | ⚠ 完整的主要客户编号 (PAN) 存储在标准 Salesforce 字段中,无需加密,而是使用付款处理器令牌化或兼容 PCI DSS 的加密存储 |
| 隐私 | GDPR/CCPA | ⚏ 未实施同意管理;数据处理没有精细的同意或撤回功能 |
| 隐私 | GDPR/CCPA | ⚏ 数据主体权利请求通过法律团队手动处理,而不是根据法规的响应窗口调整自动化 |
| 隐私 | GDPR/CCPA | ⚠ 数据保留是手动的;尽管同意书或保留期已过,数据仍会无限累积 |
| 政府 | FedRAMP | 受监管的政府工作负载在商业 Salesforce 实例上运行,而不是 Government Cloud |
| 政府 | FedRAMP | NIST 800-53 控件缺少与 Salesforce 配置的文档映射;存在合规性差距 |
| 政府 | FedRAMP | 事件监控未路由到政府 SIEM;未满足连续监控要求 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 安全性 | ✅ 具有关键系统权限(查看所有数据、修改所有数据、管理用户)的用户作为提升权限的资产进行清点和跟踪 |
| 平台 | Shield Event Monitoring | ✅ Event Monitoring 捕获事件日志,涵盖登录、报表和数据导出、权限更改和 API 调用,以进行安全分析 |
| 平台 | Shield Event Monitoring | ✅ Event Monitoring 日志被路由到外部 SIEM 平台,以便与非 Salesforce 安全事件相关联 |
| 集成 | SIEM | ✅ SIEM 关联规则检测权限升级,例如批准更改窗口之外的权限更改和超过基准的 API 量异常 |
| 集成 | SIEM | ✅ SIEM 仪表板提供了安全资产变化的可见性,例如特权用户授予和数据导出 |
| 平台 | 文档 | ✅ 安全资产清单记录有资产类别(用户、数据、集成、软件包、配置)、所有者和审查节奏 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 安全性 | ⚏ 安全资产库存在创建后立即过时的电子表格中手动维护 |
| 平台 | 安全性 | ⚠ 通过部落 Knowledge 跟踪安全资产,无需在事件期间访问可记录、可查询的库存 |
| 平台 | 安全性 | 安全审计仅在年度合规性审查期间进行,两次审计之间没有持续监控 |
| 平台 | 安全性 | ⚏ 安全资产库存已收集,但从未审核;休眠客户、孤立集成和过度权限会无限期存在 |
| 平台 | 安全性 | 官方集成用户被跟踪,但业务部门绕过安全审查和凭据轮换策略创建临时连接的应用程序 |
| 平台 | Shield Event Monitoring | 事件监控已启用,但事件不会路由到 SIEM;安全事件在 Salesforce 中保持孤立,没有相关性 |
| 平台 | 集成 | 影子 IT 集成绕过库存跟踪;未经授权的 API 活动会产生数据泄露风险 |