--- schema_version: "1" id: 273557f0d58b0d35e155132d57882af7f657938e3c5a7b6491f3fd83bf8d16d7 title: 身份和访问权限管理 - 模式 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/trust-identity-access-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/trust-identity-access-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 9315995ebfdd4369cd1a9e9eef429daf42e03b5b44e3af4b37115c0bb111e267 products: - 架构良好的框架 - Architect Site Content Repo --- # 身份和访问权限管理 - 模式
了解有关 Well-Architected [Trust](/docs/architect/zh-cn/well-architected/guide/trust.html) → [身份和访问管理](/docs/architect/zh-cn/well-architected/guide/trust.html#identity-and-access-management)的更多信息 ## 身份为主要周边 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 架构 | ✅ 访问控制在每个请求上明确验证身份，与网络位置或设备无关 | | 平台 \| 架构 | ✅ 基于身份的安全控制取代了基于网络的Trust假设 | | 平台 \| 组织 | ✅ 访问决策考虑谁在请求访问（身份验证）、他们被授权做什么（授权）以及上下文（设备、位置） | | 平台 \| 文档 | ✅ 安全架构将身份记录为主要 Trust 边界，而不是网络周边 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 架构 | ⚏ 假设公司网络或 VPN 上的用户是可信的，并仅根据网络位置授予更广泛的访问权限 | | 平台 \| 架构 | 访问控制依赖于网络周边，而不是身份验证 | | 平台 \| 组织 | 访问决策不考虑上下文信号（设备、位置、时间、行为模式） | | 平台 \| 文档 | 安全架构将网络位置视为主要 Trust 边界 | ## Salesforce 四层访问模型 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 组织 | ✅ 解决方案利用所有四个 Salesforce 访问层：组织（许可证、功能）、对象 (CRUD)、字段 (FLS)、记录（共享） | | 平台 \| 组织 | ✅ 自上而下设计访问模型（组织 → 对象 → 字段 → 记录），并自下而上验证 | | 平台 \| 组织 | ✅ 对于包含敏感数据的对象，组织范围的默认值 (OWD) 设置为专用 | | 平台 \| 组织 | ✅ 设置为“公用只读”的 OWD 仅限于参考对象（产品、价格手册），在这些对象中，广泛的可见性支持业务而不暴露风险 | | 平台 \| 组织 | ✅ 组织级约束（许可证、IP 范围、登录时间、功能权限）定义了用户群的基线功能 | | 平台 \| 组织 | ✅ 对象权限（通过简档和权限集）控制对用户细分的每个对象的创建、读取、编辑和删除访问权限 | | 平台 \| 组织 | ✅ 字段级安全性保护敏感字段，即使授予对象访问权限 | | 平台 \| 组织 | ✅ 记录级共享使用基于记录业务需求的角色层次结构和共享规则 | | 平台 \| 组织 | ✅ 访问权限在限制性基准的基础上有意扩展，在允许默认设置后不受限制 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 组织 | 访问模型没有利用所有四个层（组织、对象、字段、记录） | | 平台 \| 组织 | ⚠ ⸏ OWD 设置为公用读/写，以便在开发期间不受限制地计划 | | 平台 \| 组织 | 随着数据量的增长和业务流程的结晶，提前设置的过度宽松的 OWD 变得越来越难以限制 | | 平台 \| 组织 | 未配置字段级安全性，仅依赖对象或记录级访问控制 | ## 身份验证架构 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 组织 | ✅ 对访问生产环境的所有用户强制实施多重身份验证 (MFA)（UI 访问权限强制实施） | | 平台 \| 组织 | ✅ MFA 扩展到特权操作，包括批量数据导出、权限更改和管理配置 | | 平台 \| 组织 | ✅ 单点登录 (SSO) 使用 SAML 2.0 或 OpenID Connect 协议 | | 平台 \| 组织 | ✅ 会话超时配置正确：标准用户为 2 小时，管理员和访问受限数据的用户为 15-30 分钟 | | 平台 \| 组织 | ✅ 对管理简档和集成用户强制实施 IP 限制 | | 平台 \| 组织 | ✅ 登录时间将服务帐户限制为预期操作窗口 | | 平台 \| 组织 | ✅ 本地设备激活会验证从无法识别的设备登录；MFA 和 IP 限制增加了对高权限帐户的保护 | | 平台 \| 组织 | ✅ 如果启用了 SSO，批准的管理员用户具有直接登录访问权限（打破常规程序） | | 平台 \| 组织 | ✅ 登录 Salesforce 的用户和实体之间的关系是 1:1（没有共享用户帐户） | | 平台 \| 组织 | ✅ API 访问控制阻止用户通过未经授权的连接的应用程序进行身份验证 | | 平台 \| 命名凭据 | ✅ 命名凭据和外部凭据通过轮换功能集中管理身份验证 | | 平台 \| 命名凭据 | ✅ 命名凭据从代码中抽象身份验证详细信息，无需更改代码即可实现凭据更新 | | 平台 \| 命名凭据 | ✅ 凭据从不嵌入代码、配置文件或版本控制 | | 平台 \| Apex | ✅ 执行身份验证的方法使用命名凭据来处理用户名/密码流 | | 平台 \| Apex | ✅ 没有用户名或密码以可读的格式显示在代码中（没有硬编码的值或字符串） | | 平台 \| Aura | ✅ 执行身份验证的方法使用命名凭据来处理用户名/密码流 | | 平台 \| Aura | ✅ 没有用户名或密码以可读的格式显示在代码中 | | 平台 \| Lightning Web 组件 (LWC) | ✅ 使用命名凭据执行身份验证的方法 | | 平台 \| Lightning Web 组件 (LWC) | ✅ 代码中不显示用户名或密码 | | 集成 \| API | ✅ OAuth 2.0 JWT 不记名流用于可信环境中的服务器到服务器集成（生产集成的首选） | | 集成 \| API | ✅ OAuth 2.0 Web 服务器流用于需要用户上下文的服务器到服务器集成 | | 集成 \| API | ✅ OAuth 2.0 设备流用于无头设备;CLI 和 CI/CD 工具使用 Web 服务器流(`sf org login web`)或 JWT 不记名流(`sf org login jwt`)——自 2025 年 8 月 28 日起,默认 Salesforce CLI 连接的应用程序的设备流被阻止 | | 集成 \| API | ✅ 不使用用户名-密码 OAuth 流；依赖它的现有集成迁移到 JWT 不记名或客户端凭据流 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 组织 | ⚏ 未对生产环境访问权限强制执行 MFA | | 平台 \| 组织 | 登录配置不符合 Salesforce MFA 要求 | | 平台 \| 组织 | ⚏ MFA 未扩展到特权操作（批量导出、权限更改、管理配置） | | 平台 \| 组织 | 会话超时未配置或权限过大（>24 小时） | | 平台 \| 组织 | 会话策略不区分标准用户和访问受限数据的管理员/用户 | | 平台 \| 组织 | 未对管理简档和集成用户强制执行 IP 限制 | | 平台 \| 组织 | ⚏ 服务帐户的登录时间限制在预期的操作窗口 | | 平台 \| 组织 | ⚠ 高权限帐户仅依赖于设备激活 — 未添加 MFA 或 IP 限制 | | 平台 \| 组织 | ⚠ ⸏ 如果启用了 SSO，则任何批准的管理员用户都没有直接登录访问权限（没有破解程序） | | 平台 \| 组织 | 用户和实体之间的关系不是 1:1（存在共享用户帐户） | | 平台 \| 组织 | 未启用 API 访问控制 | | 平台 \| 命名凭据 | 凭据直接嵌入代码、配置文件或版本控制 | | 平台 \| Apex | 用户名和密码以可读的格式显示在代码中 | | 平台 \| Apex | 身份验证是临时处理，没有一致的实施 | | 平台 \| Aura | 身份验证是临时处理的，没有命名凭据 | | 平台 \| Aura | 用户名和密码显示在代码中 | | 平台 \| Lightning Web 组件 (LWC) | 身份验证是临时处理的，没有命名凭据 | | 平台 \| Lightning Web 组件 (LWC) | 用户名和密码显示在代码中 | | 平台 \| 业务 | 用户配置和取消配置 SLA 和要求不存在 | | 集成 \| API | 当更安全的 OAuth 流可用时，使用用户名-密码 OAuth 流 | | 集成 \| API | OAuth 范围权限过大（在有限范围足够时具有完全访问权限） | | 集成 \| API | ⚠ 客户端凭据（客户端 ID、客户端密码）不安全地存储在代码或配置文件中 | ## 授权和访问控制 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 组织 | ✅ 角色层次结构深度最大为 5-7 级（避免性能开销和故障排除复杂性） | | 平台 \| 组织 | ✅ 权限集和权限集组提供灵活的附加访问权限，不会增加简档 | | 平台 \| 组织 | ✅ 权限集授予对特定工作职能、应用程序或临时提升权限的访问权限 | | 平台 \| 组织 | ✅ 权限集小组将相关权限集与异常禁用功能相结合 | | 平台 \| 组织 | ✅ 所有功能访问权限通过权限集和权限集组（而非简档）授予，随着工作角色的发展提供灵活性 | | 平台 \| 组织 | ✅ 事务安全性策略通过实时上下文评估扩展授权 | | 平台 \| 组织 | ✅ 事务安全性策略检测并阻止异常行为（批量数据下载超过模式、从意外地理区域登录、更改窗口外部的权限更改） | | 平台 \| 组织 | ✅ IP 限制针对高度敏感的操作或数据访问进行配置 | | 平台 \| 组织 | ✅ 为每个集成配置唯一的仅 API 集成用户 | | 平台 \| Apex | ✅ 所有访问数据的代码都使用 WITH USER_MODE、 WITH SYSTEM_MODE 关键字或 Security.stripInaccessible() 方法强制执行 CRUD 和 FLS | | 平台 \| Apex | ✅ SOQL 查询根据业务需求明确使用 WITH USER_MODE 或 WITH SYSTEM_MODE 关键字 | | 平台 \| Apex | ✅ DML 操作在插入/更新/更新插入操作之前使用 Security.stripInaccessible() 进行访问强制 | | 平台 \| Apex | ✅ 数据库 DML 语句明确声明数据操作的用户或系统模式 | | 平台 \| Apex | ✅ 数据库操作使用 stripInaccessible() 方法来筛选查询和子查询结果 | | 平台 \| Apex | ✅ 共享关键字（带共享、不带共享、继承共享）根据业务安全要求适当使用 | | 平台 \| 设计标准 | ✅ 授予提升权限的用例（修改所有数据、查看所有数据）有明确的业务理由文档 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 组织 | ⚏ 角色层次结构比 5-7 级别更深，在共享计算和故障排除复杂性方面会产生性能开销 | | 平台 \| 组织 | 角色层次结构授予广泛的访问权限，无需业务证明 | | 平台 \| 组织 | ⚏ 简档会重复复制，以进行少量权限更改，从而创建几十个区分不清的简档 | | 平台 \| 组织 | 简档包含元数据的访问控制（应使用权限集） | | 平台 \| 组织 | 未实施事务安全性策略来检测异常行为 | | 平台 \| 组织 | ⚏ IP 限制未针对高度敏感的操作或数据访问进行配置 | | 平台 \| 组织 | 仅使用 API 的用户未配置或在多个集成之间共享 | | 平台 \| 组织 | 查看所有数据或修改所有数据权限是在没有书面说明的情况下授予的 | | 平台 \| Apex | ⚏ SOQL/SOSL 查询和 DML 操作在默认系统模式下运行，没有显式的访问权限检查 | | 平台 \| Apex | CRUD 和 FLS 实施不一致或缺失 | | 平台 \| Apex | SOQL 依赖于 WITH SECURITY_ENFORCED，它已被删除，现在会导致编译错误（用 USER_MODE 替换） | | 平台 \| Apex | 共享关键字的使用不一致或根本不使用 | | 平台 \| 设计标准 | 授予提升权限的用例没有明确记录 | ## 基于属性的访问控制 (ABAC) 和 Data 360 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| Data 360 | ✅ RBAC（角色、简档、权限集）控制平台访问权限（谁可以使用 Data 360），ABAC 控制数据访问权限（他们根据属性看到什么数据） | | 平台 \| Data 360 | ✅ AI 客服人员在请求用户的上下文中执行（代表），因此客服人员生成的查询受该用户访问权限的约束，而不是以系统级访问权限运行 | | 平台 \| 文档 | ✅ 数据分类分类包含属性定义、实施规则和业务理由 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| Data 360 | ⚏ 必须遵循数据分类的访问权限是通过角色层次结构和共享来强制的，角色层次结构和共享不能表达数据分类，而不是达到基于属性的访问控制 | | 平台 \| Data 360 | FLS 绕过：没有字段级访问权限的用户通过不强制实施 FLS 的 API 或 SOQL 查询检索数据 | | 平台 \| Data 360 | AI 客服人员查询数据，而不在请求用户的上下文中执行；客服人员生成的查询绕过对象、字段和记录级别的访问控制 | | 平台 \| Data 360 | 客服人员执行上下文不包括用户代表属性；客服人员使用系统级访问权限操作 | | 平台 \| 文档 | 数据分类分类没有记录；属性定义因团队而异，导致实施不一致 | ## 关键影响客户 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 组织 | ✅ 在资产库存中识别和跟踪关键影响客户（系统管理员、集成用户、自动化流程客户） | | 平台 \| 组织 | ✅ 重要影响客户代表高价值目标，因为提升的权限提供了广泛的平台访问权限 | | 平台 \| 组织 | ✅ MFA 需要硬件安全密钥或身份验证应用程序（非短信，这容易受到 SIM 交换的影响） | | 平台 \| 组织 | ✅ 登录 IP 范围仅限于已知管理位置 | | 平台 \| 组织 | ✅ 启用登录提醒和权限更改通知 | | 平台 \| 组织 | ✅ 每季度使用记录证明进行访问审查 | | 平台 \| 组织 | ✅ 存在使用后审计的紧急访问的打破玻璃程序 | | 集成 \| 服务客户 | ✅ OAuth 流用于集成和服务帐户（不要使用用户名-密码） | | 集成 \| 服务客户 | ✅ 对集成用户强制实施 IP 限制 | | 集成 \| 服务客户 | ✅ 实施凭据轮换计划（每季度或每份保单） | | 集成 \| 服务客户 | ✅ 通过 Event Monitoring 监控异常 API 使用模式 | | 集成 \| 服务客户 | ✅ 每个集成都有一个具有最低所需权限的专用服务帐户（不是具有广泛访问权限的共享“集成用户”） | | 集成 \| 服务客户 | ✅ 服务帐户应用的权限最低，因为它们在无人参与的情况下操作 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 组织 | 重要影响客户（管理员、集成、自动化）未被识别、跟踪或清点 | | 平台 \| 组织 | 系统管理员使用基于 SMS 的 MFA，而不是硬件安全密钥或身份验证应用程序 | | 平台 \| 组织 | 重要影响客户没有登录时间或 IP 限制 | | 平台 \| 组织 | 没有为特权帐户的登录或权限更改配置警报 | | 平台 \| 组织 | 重要影响客户访问权限从不定期审核或审核（非每季度） | | 平台 \| 组织 | ⚠ 没有用于紧急访问的破碎玻璃程序 | | 集成 \| 服务客户 | ⚠ 单个“API 用户”帐户在多个集成中共享，并具有修改所有数据权限 | | 集成 \| 服务客户 | ⚠ 服务帐户在 OAuth 可用时使用用户名-密码身份验证 | | 集成 \| 服务客户 | ⚠ 服务帐户凭据使用多年不变的静态密码（无轮换） | | 集成 \| 服务客户 | ⚠ 服务帐户的权限超出集成要求 | | 集成 \| 服务客户 | 不监控服务客户的异常 API 使用模式 | ## 身份生命周期管理 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 进程 | ✅ 身份生命周期包括：配置（使用基准访问权限创建）、访问权限调整（在角色更改时授予/撤销）、定期重新认证（每季度验证）、取消配置（立即撤销） | | 平台 \| 组织 | ✅ 实施 SCIM（跨域身份管理系统），用于身份提供商的自动配置 | | 平台 \| 进程 | ✅ 配置创建具有匹配作业功能的基准访问权限的客户，由 HR 系统事件触发 | | 平台 \| 进程 | ✅ 访问权限调整会在角色扩展时授予额外权限，并在角色更改时撤销权限 | | 平台 \| 进程 | ✅ 每季度定期进行重新认证，经理可为其团队审核和验证访问权限 | | 平台 \| 进程 | ✅ 取消配置会在雇用结束或角色不再需要 Salesforce 时立即撤销访问权限 | | 平台 \| 组织 | ✅ 自动检测识别 90 天内未登录的用户，并触发访问审查工作流 | | 平台 \| 组织 | ✅ 即时 (JIT) 配置在适当时自动从 SSO 创建用户 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 组织 | 尽管有身份提供商集成，但 SCIM 配置没有实施 | | 平台 \| 进程 | ⚏ 无需标准入职程序即可手动创建新用户 | | 平台 \| 进程 | 初始用户访问权限不一致或基于复制现有用户 | | 平台 \| 进程 | ⚏ 角色更改或转移的访问权限更改延迟或未完成 | | 平台 \| 进程 | 离职被延迟；前员工在终止后保留访问权限（非当天停用） | | 平台 \| 组织 | 用户配置没有自动化（仅限手动用户创建） | | 平台 \| 进程 | 不存在访问权限重新认证市场活动（没有季度或年度审核） | | 平台 \| 进程 | 不会删除在重新认证期间发现的不必要访问权限 | | 平台 \| 进程 | ⚏ 对特权帐户、跨组织访问权限、外部用户的访问权限重新认证不严格 | | 平台 \| 组织 | ⚏ 休眠帐户（90 多天内未登录）累积，无需审核或停用 |