--- schema_version: "1" id: f6572df9de65f090accf4ced42eaea1fd94469c47ee713d23bdbca27268e5f45 title: 事件响应模式 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/trust-incident-response-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/trust-incident-response-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 07107d3c4a6342f241f68913e299dc1e2eee5bdc972d2212bb518a0d8ccab8f9 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#security-incident-response)的更多信息 尽管采取了预防措施,安全事件仍会发生。Trust 架构需要设计可检测性、快速响应、取证调查和优雅恢复。此页面整合了 Trust 支柱事件响应部分中的事件响应模式，涵盖了检测架构、响应程序、取证功能和事件后学习。 ## 检测和监控架构 **模式** | 何处查看 | 好样的 | | --- | --- | | 事件监控 | ✅ 启用 Event Monitoring 捕获登录模式、批量数据导出、权限更改和 API 活动，并路由到 SIEM 平台，以进行超过本机保留限制的保留 | | 事务安全性策略 | ✅ 配置实时评估事件的策略，以阻止可疑操作，要求逐步身份验证，或根据行为基准触发通知 | | 设置审计跟踪 | ✅ 监控管理配置更改，启用 180 天保留期检测未经授权的修改 | | 自定义应用程序记录 | ✅ 在 Apex 中实施安全相关事件日志记录，捕获身份验证失败、授权拒绝和可疑输入模式 | | 健康检查监控 | ✅ 配置自动检测配置偏离安全基线的情况，这可能表示未经授权的更改 | | SIEM 集成 | ✅ 将 Event Monitoring 日志路由到企业 SIEM 平台，与企业安全遥测和行为分析进行关联 | | 提醒规则 | ✅ 设计检测可疑模式的提醒规则（工作时间以外的批量访问、从新地理区域登录、快速权限升级），并带有行为基线，以最大限度地减少误报 | | 行为 Analytics | ✅ 建立行为基线，支持异常数据访问量、非工作时间管理活动和 API 消耗模式的异常检测 | | 多渠道检测 | ✅ 通过 Event Monitoring、事务安全性、设置审计跟踪、自定义日志记录和运行状况检查实施检测，提供多种独立的检测信号 | | 不可变日志存储 | ✅ 将日志路由到攻击者无法修改的不可变外部存储，即使具有 Salesforce 管理访问权限，也能确保取证证据的完整性 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 仅限本地日志保留 | 仅依赖本地 Salesforce 审计跟踪保留窗口（Event Monitoring 本地限制，180 天设置审计跟踪），无需外部归档，在调查需要历史分析时发现过期日志 | | 无行为基准 | 没有异常检测的行为基准，生成过多的误报警报，训练安全团队忽略通知 | | 无 SIEM 集成 | 缺少企业 SIEM 集成，缺少与其他系统的安全遥测的相关性机会，从而暴露出更广泛的妥协模式 | | 手动日志审查 | ⚠ 取决于定期的手动日志审查，而不是自动警报，在损害范围很广时，可在事件发生几周或几个月后发现事件 | | 无事务安全性策略 | ⚠ 没有实时事务安全性策略，缺乏在损害发生之前阻止可疑操作的能力 | | 不完整的覆盖范围 | ⚠ 仅监控与安全相关的事件子集（登录但不访问数据，配置更改但不修改权限），从而产生盲点 | | 警报疲劳 | ⚠ ⸏ 在不调整的情况下生成过多的误报警报，训练团队忽略通知，包括合法的安全事件 | ## 隔离和遏制功能 **模式** | 何处查看 | 好样的 | | --- | --- | | 隔离边界 | ✅ 设计架构，以便可以通过权限集撤销、IP 限制更改或会话终止来隔离受威胁的组件，而不会中断关键业务功能 | | 会话管理 | ✅ 为受威胁的客户实施快速会话终止功能，包括在所有活动会话中强制注销和会话无效 | | 权限撤销 | ✅ 通过权限集而不是基线简档授予权限，以便快速撤销：删除权限集分配会在没有简档或其他分配独立授予相同权限时撤销访问权限 | | IP 限制 | ✅ 为特权帐户配置简档级登录 IP 范围，以便直接拒绝从其他地址登录，从而支持与已知管理位置的快速网络级隔离 | | 用户帐户冻结 | ✅ 实施帐户冻结程序，防止身份验证，同时保留数据以供调查，而不删除被盗用的帐户 | | API 访问控制 | ✅ 设计具有令牌撤销功能的 API 身份验证，支持快速隔离被盗用的集成帐户 | | 多组织隔离 | ✅ 对于高价值资产，评估多组织架构是否以增加操作复杂性为代价为关键组件提供最强隔离性 | | 紧急玻璃破碎程序 | ✅ 使用后审计和验证，维护用于紧急管理访问的文档化破玻璃访问程序 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 无隔离边界 | ⚠ 缺少架构隔离边界，需要完全关闭系统才能包含任何威胁，从而中断所有业务功能 | | 访问权限过大 | 授予广泛的“修改所有数据”权限，防止精细的权限撤销，而不会中断多个业务流程 | | 共享服务帐户 | 在多个系统中使用单个共享的“API 用户”或“集成用户”帐户，防止隔离特定的受损集成，而不会破坏所有集成 | | 无 IP 限制 | ⚠ 没有特权客户的 IP 允许列表，在客户被盗时缺乏网络级遏制功能 | | 无会话管理 | ⚠ 缺少会话终止功能，需要密码重置作为强制注销的唯一方式，从而在关键响应时段引入延迟 | | 无紧急程序 | ⚠ 没有记录在案的破碎玻璃或紧急访问程序，在有效事件期间在压力下临时做出关键决策 | ## 法证调查架构 **模式** | 何处查看 | 好样的 | | --- | --- | | Event Monitoring 日志 | ✅ 捕获详细的活动日志，包括用户操作、API 调用、身份验证事件和数据访问模式，并有足够的详细信息进行取证分析 | | 字段审计跟踪 | ✅ 启用字段审计跟踪，为保留匹配监管要求的受限和机密字段保留数据更改历史记录（支持无限期保留；根据监管条例确认所需期限） | | 不可变存储 | ✅ 将日志路由到攻击者无法修改的外部不可变存储，确保整个调查期间的取证证据完整性 | | 设置审计跟踪 | ✅ 保留管理配置更改历史，允许调查 180 天的保留期内未经授权的系统修改 | | 范围评估 | ✅ 设计权限模型和数据访问控制，基于受威胁的客户权限快速评估数据暴露范围 | | 更改相关性 | ✅ 保持设置审计跟踪配置更改和事件监控活动模式之间的相关性，以便调查攻击者的技术 | | 数据访问记录 | ✅ 记录对受限和机密数据的所有访问权限，以便调查在妥协期间暴露的数据 | | 集成审计跟踪 | ✅ 捕获集成系统的 API 身份验证、授权和数据交换模式，支持跨系统泄露调查 | | 证据保全 | ✅ 将日志和审计跟踪连续路由到不可变的外部存储，以便在调查事件时保留并可用取证证据 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 可变日志存储 | 仅在 Salesforce 中存储日志，具有管理访问权限的攻击者可以删除或修改取证证据 | | 日志详细信息不足 | ⚠ 捕获高级事件，但没有足够的详细信息进行调查（记录登录，但未记录 IP 地址，记录数据访问，但未记录特定记录） | | 无数据访问记录 | ⚠ 缺少对受限和机密数据访问的详细日志记录，无法在违规通知期间评估数据泄露范围 | | 缺少字段审计跟踪 | 未对敏感字段启用字段审计跟踪，无法确定在妥协期间暴露哪些数据值 | | 无更改相关性 | 设置审计跟踪配置更改与后续 Event Monitoring 活动模式之间没有关联功能 | | 已删除的审计历史 | 允许审计历史在部署的管理法规集的法规保留最小值之前过期，从而产生违反法规的行为 | ## 恢复和还原程序 **模式** | 何处查看 | 好样的 | | --- | --- | | 恢复时间目标 | ✅ 为安全事件场景定义和测试恢复时间目标 (RTO) 和恢复点目标 (RPO)，而不仅仅是灾难恢复场景 | | 测试的恢复程序 | ✅ 通过季度测试，针对受威胁帐户、批量数据泄露、未经授权的部署、权限升级和软件包妥协的文档恢复流程 | | 备份验证 | ✅ 定期验证备份完整性，确保在安全事件期间恢复功能正常，而不仅仅是操作失败 | | 回滚功能 | ✅ 使用经过测试的回滚程序设计部署漏斗，防止未经授权的代码部署或恶意配置更改 | | 凭据轮换 | ✅ 为受威胁的集成帐户、API 用户和命名凭据实施快速凭据轮换程序 | | 权限恢复 | ✅ 记录事件响应期间过度广泛的隔离操作后恢复适当访问权限的程序 | | 数据还原 | ✅ 设计数据恢复功能，解决安全事件导致的数据损坏或删除，与灾难恢复不同 | | 服务连续性 | ✅ 架构解决方案，以便安全事件响应程序在调查和补救期间保持关键业务功能的连续性 | | 恢复验证 | ✅ 每季度测试恢复程序，验证恢复的系统是否正常运行，并且通过恢复是否持续存在危害 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 未测试的程序 | ⚠ 记录从未通过练习测试的恢复程序，在实际事件中发现程序不完整或不正确 | | 没有 RTO/RPO 来保证安全 | 仅为灾难恢复定义恢复时间目标，而不考虑需要不同恢复程序的安全事件场景 | | 无回滚功能 | 对于未经授权的代码部署，缺少部署回滚程序，需要完全重新开发，以删除恶意更改 | | 未验证的备份 | 从不测试备份还原，在事件期间发现备份损坏或不完整 | | 无凭据轮换程序 | ⚠ 对于被盗用的集成客户，没有快速的凭据更迭程序，在调查期间保持被盗用的凭据处于活动状态 | | 手动恢复流程 | ⚠ 完全取决于事件期间的手动恢复程序，在速度关键时引入错误和延迟 | | 无还原测试 | ⚠ 始终无法验证恢复的系统在恢复后是否正常运行，从而可能重新引入威胁或数据损坏 | ## 特定于事件的响应程序 **模式** | 何处查看 | 好样的 | | --- | --- | | 受影响的用户帐户响应 | ✅ 文档程序：冻结用户，强制凭据重置，查看设置审计跟踪和数据访问日志以了解妥协期，评估数据泄露范围，如果访问受限数据，则执行违规通知 | | 批量数据泄露响应 | ✅ 文档程序：立即撤销会话，限制权限，识别受影响的记录和分类级别，在为您的部署设置的管理法规的时间范围内执行违反法规通知 | | 未经授权的代码部署响应 | ✅ 文档程序：立即回滚部署，审核来自已泄露凭据的所有更改，审查漏斗安全性以绕过授权，扫描已部署代码以寻找持久后门 | | 权限升级响应 | ✅ 文档程序：立即撤销升级的权限，审核使用升级的访问权限执行的活动，调查升级如何绕过批准控制，实施补偿控制 | | AppExchange 软件包妥协响应 | ✅ 文档程序：隔离软件包权限，评估软件包访问的数据，评估软件包替换选项，为软件包评估条件记录经验教训 | | 检测信号 | ✅ 配置检测每个场景的监控：受威胁帐户的登录异常、用于泄露的报表导出量、未授权代码的部署监控、用于升级的权限更改监控 | | 桌面练习 | ✅ 进行桌面演习，测试特定于平台的方案的响应程序，验证团队的准备程度和程序完整性 | | 回复自动化 | ✅ 实时事务安全性策略自动阻止可疑操作，要求逐步身份验证，或通知响应者高置信度检测信号，提供自动化遏制，减少响应时间 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 仅限通用响应计划 | ⚠ 仅具有通用事件响应程序，没有特定于 Salesforce 的指导，在活动事件期间临时采取特定于平台的操作 | | 无检测配置 | ⚠ 没有配置任何监控来检测特定于平台的场景（批量导出、权限升级、未经授权的部署），通过用户报表或审计发现事件 | | 无桌面练习 | ⚠ 从不执行桌面练习来验证团队对特定于平台的响应程序的熟悉程度，在实际事件中发现 Knowledge 差距 | | 无自动化 | ⚠ 完全手动响应所有事件，没有用于自动遏制的实时事务安全策略，在立即阻止可以减少损害时引入延迟 | | 缺少回复行动手册 | ⚠ 缺少常见场景的文档响应行动手册（泄露的用户帐户、数据泄露、未经授权的代码部署） | | 无违约通知程序 | ⚠ 没有监管违规通知要求的程序，在时间紧迫的实际事件期间忙于了解义务 | ## 沟通和协调 **模式** | 何处查看 | 好样的 | | --- | --- | | 带外通信 | ✅ 建立不依赖于潜在受损系统的通信渠道（电话树、外部消息传递平台），以协调响应 | | 升级程序 | ✅ 包含联系信息和升级条件的文档升级路径，从初始检测到执行通知 | | 通知模板 | ✅ 维护常见事件类型的预起草通知模板，以便与利益相关者、客户和监管机构快速沟通 | | 利益相关者身份 | ✅ 确定需要通知不同事件类型的利益相关者，包括高管、法律、合规、受影响用户和监管机构 | | 监管通知时间表 | ✅ 记录每个司法管辖区的法规通知要求，并根据部署的相关法规进行确认，同时制定确保及时合规的程序 | | 内部协调 | ✅ 设计事件协调程序，规定角色和职责（事件指挥官、技术主管、通信主管、法律联络员） | | 外部协调 | ✅ 建立与 Salesforce 支持、外部法医调查员、法律顾问和执法机构协调的程序 | | 状态通信 | ✅ 在有效事件期间实施定期状态沟通节奏，在不压垮调查团队的情况下让利益相关者了解情况 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 无带外通信 | ⚠ 完全依赖于潜在被盗的电子邮件或内部消息传递进行事件协调，当主要渠道被盗时失去通信能力 | | 不明确的升级路径 | ⚠ 没有记录的升级程序，导致延迟，并混淆了通知对象和时间 | | 无通知模板 | ⚠ 在时间紧迫的活动事件期间临时制作事件通知，导致通信不完整或不正确 | | 缺少利益相关者列表 | ⚠ 没有预先确定的利益相关者列表，在事件期间发现关键各方（法律、合规、高管）没有获得通知 | | 无监管时间线意识 | ⚠ 不了解适用于事件响应期间部署的法规通知时间表，错过截止日期并产生额外的合规违规 | | 不明确的角色 | 事件响应角色和职责不明确，导致对谁有权做出遏制决定的困惑 | | 无外部协调程序 | 没有既定的关系或程序在需要时与 Salesforce 支持、法证调查员或执法机构联系 | ## 事件后审查和学习 **模式** | 何处查看 | 好样的 | | --- | --- | | 无怨文化 | ✅ 将事件后审查的重点放在系统改进上，而不是个人指责上，使组织学习不用担心后果 | | 事件时间线文档 | ✅ 记录完整的事件时间线，包括初始妥协、检测、响应操作和带有精确时间戳的解决方案 | | 控制失败分析 | ✅ 确定哪些预防性和检测性控制措施未能防止或检测事件，为架构改进提供信息 | | 架构弱点文档 | ✅ 在捕获安全更改的架构决策记录 (ADR) 中记录事件揭示的架构弱点 | | 补救优先级 | ✅ 根据风险降低潜力确定补救措施的优先级，解决根本原因而不是症状 | | 课程共享 | ✅ 在团队和业务部门之间分享经验教训，防止组织其他部门发生类似事件 | | 检测规则更新 | ✅ 根据调查期间观察到的攻击技术更新检测规则和行为基线 | | 回复程序优化 | ✅ 根据实际事件响应期间哪些有效，哪些无效，更新事件响应程序 | | 度量跟踪 | ✅ 跟踪平均检测时间 (MTTD)、平均响应时间 (MTTR) 和影响范围，确定需要架构投资的趋势 | | 审查节奏 | ✅ 在细节保持新鲜且存在改进势头时，及时进行事件后审查 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 跳过审查 | 跳过事件后审查，直接转到下一个事件，无需获取经验教训或架构改进 | | 指责文化 | 将事件后审查集中在个人责任上，而不是系统改进上，导致事件隐瞒并阻止组织学习 | | 无架构文档 | 无法在架构决策记录 (ADR) 中记录由事件学习引起的安全架构更改 | | 症状治疗 | ⚠ 仅解决事件症状（泄露的密码），而不修复根本原因（缺乏 MFA），允许类似的攻击得逞 | | 无课程共享 | 将事件学习保留在响应团队中，而不是在组织之间共享，允许其他业务部门发生类似的事件 | | 无检测更新 | ⚠ 无法根据观察到的攻击技术更新检测规则或行为基准，仍然容易受到类似的攻击 | | 无度量跟踪 | 不跟踪平均检测时间 (MTTD)、平均响应时间 (MTTR) 或范围趋势、缺少发现系统弱点的机会 | | 延迟审查 | ⚠ 在事件解决数月后，在忘记详细信息并失去改进动力时进行事件后审查 | | 无补救跟进 | ⚠ 在事件后审查期间发现改进，但未实施，允许类似事件重复发生 |