灾难恢复、业务连续性与事件响应
ProcessMind 灾难恢复、业务连续性与事件响应
生效日期：2026 年 9 月 14 日
本文档概述 ProcessMind B.V. 针对其云服务制定的灾难恢复（“DR”）、业务连续性（“BCP”）和安全事件响应程序。本文件是对安全措施、SaaS 托管政策、服务级别协议和数据处理附录的补充。
本文档说明我们目前采用的方法，但不会在适用协议、DPA 或 SLA 明确规定的内容之外，另行设定合同恢复时间目标、恢复点目标、数据持久性保证、通知期限、服务级别或责任标准。
1. 目标和适用范围
ProcessMind 制定并维护这些程序，以便：
- 在发生中断事件期间保护客户数据的机密性、完整性和可用性
- 在 ProcessMind 控制的系统发生故障后恢复关键生产服务组件
- 在服务中断期间继续进行事件管理、客户沟通和运营决策
- 使用有文档记录的程序和受源代码控制的基础设施定义，从基础设施、部署、应用程序或数据层故障中恢复
- 识别和评估安全事件、遏制威胁、消除根本原因、恢复受影响的系统、按要求进行沟通并总结经验教训
这些程序适用于 ProcessMind 生产云服务，以及涉及分处理方或云服务的安全事件，但仅限于此类事件影响服务且在 ProcessMind 合理调查和管理能力范围内的情况。开发和测试环境相互隔离，不作为面向客户的生产承诺的恢复目标。
2. 弹性策略
**2.1 区域设计。**生产服务托管于 AWS EU（德国法兰克福，eu-central-1）。该架构依赖该区域内由 AWS 管理的服务，而 AWS 在多个可用区运营这些服务。Aurora 集群目前运行单个写入器实例，因此数据库恢复依赖自动备份和时间点恢复，而非同一区域内的备用实例。ProcessMind 目前未运营第二个用于客户数据的活动区域。
**2.2 托管式和无服务器服务。**ProcessMind 依赖 AWS Lambda、Amazon API Gateway、Amazon CloudFront、Amazon Aurora PostgreSQL、Amazon S3、Amazon SQS、Amazon SNS 和 Amazon CloudWatch。这减少了对客户管理的长期运行服务器的依赖，并支持从源代码重建应用程序和静态组件以进行恢复。
**2.3 环境隔离。**生产环境和开发环境在不同的 AWS 账户中运行，并使用独立的数据库和基础设施堆栈。这降低了开发活动影响生产恢复操作的风险。
**2.4 监控和检测。**CloudWatch 警报、仪表板、死信队列警报、集中式日志记录和合成服务监控有助于检测、分类和升级处理事件。潜在事件也可能通过支持请求、员工报告、供应商通知或其他调查触发因素被发现。
3. 恢复优先级
发生重大事件时，ProcessMind 通常按以下优先级进行恢复：
- 保护客户数据完整性并防止进一步损害。
- 遏制事件并稳定受影响的系统。
- 恢复核心生产访问路径和关键工作流。
- 在宣布恢复完成之前，验证服务运行情况、数据完整性和监控。
- 沟通状态更新、对客户的影响以及后续行动。
具体顺序可能因事件性质而异，包括事件是否影响数据完整性、客户访问、异步处理或支持基础设施。
4. 灾难恢复程序
**4.1 事件宣布和协调。**重大服务中断和安全事件将按照事件响应程序进行分类处理。ProcessMind 会指定事件负责人，将响应参与人员限制为获授权人员，评估严重程度和范围，协调技术响应人员，并跟踪恢复行动，直至事件解决或降级。
**4.2 遏制。**在开始更广泛的恢复工作之前，ProcessMind 会尽商业上合理的努力停止或减轻持续影响。根据故障模式，遏制措施可能包括回滚近期变更、禁用受影响的路径、隔离故障组件、在执行完整性检查期间暂停后台处理、撤销或轮换凭证，或阻止滥用活动。
**4.3 根除。**在即时影响得到稳定后，ProcessMind 会着手消除根本原因或促成因素。这可能包括应用代码或配置修复、移除恶意内容、轮换密钥、恢复可信配置或关闭暴露的访问路径。
**4.4 数据库恢复。**Aurora PostgreSQL 持续执行自动备份，保留期限为七（7）天，并支持时间点恢复。如果数据库级故障、数据损坏事件或意外破坏性变更需要恢复，ProcessMind 可以从最近的适用备份恢复，或恢复至选定的时间点，验证恢复后的环境，并将应用程序流量切换至恢复后的数据库路径。
**4.5 对象和构件恢复。**客户文件上传内容和运营构件存储在 Amazon S3 中。上传存储桶和资源存储桶均已启用版本控制，以支持从意外删除或覆盖情形中恢复。网站和前端部署存储桶被视为可复现构件，可从源代码重新构建，而非作为备份恢复。
**4.6 异步工作负载恢复。**异步处理路径使用死信队列保留失败事件以供调查。恢复措施可能包括重试失败消息、重新运行处理逻辑，或在底层工作流支持安全重新处理的情况下重放任务。
**4.7 应用程序和基础设施重建。**基础设施通过受源代码控制的基础设施即代码定义进行管理。如果需要重新创建应用程序基础设施或静态资源，ProcessMind 可以根据受版本控制的定义和构建构件重建并重新部署受影响的组件。
**4.8 恢复服务前的验证。**在关闭事件之前，ProcessMind 会使用可用的监控、日志、合成检查和有针对性的功能验证来验证服务健康状况，并使用经过验证的部署、恢复和基础设施程序恢复受影响的功能。如果事件涉及数据恢复或数据完整性风险，可能会进行额外审查。
5. 业务连续性措施
**5.1 运营连续性。**ProcessMind 维护有文档记录的运营程序，以便在发生中断事件期间继续进行事件处理、客户支持请求受理、工程响应和决策。
**5.2 沟通。**对于重大生产事件，ProcessMind 会尽商业上合理的努力，通过客户支持渠道以及在适当情况下通过公开状态页面processmind.com/status提供更新。
**5.3 受控变更管理。**我们采用纵深防御的软件开发生命周期，其中包括多个相互独立的自动化验证层、受控部署、集中式监控和事后审查，以减少可避免的服务中断，并持续改善业务连续性。
**5.4 恢复期间的安全。**恢复操作遵循适用于正常运营的相同一般安全原则，包括最小权限访问、在可行情况下记录运营活动，以及对生产系统和数据实施受控访问。
6. 备份和数据保护摘要
**6.1 数据库备份。**Aurora 自动备份经过加密，保留七（7）天，并可在该保留期限内进行时间点恢复。
**6.2 S3 保护。**Amazon S3 为存储对象提供高持久性。可变客户数据存储桶依靠主区域内的持久性和版本控制。ProcessMind 目前未为这些存储桶启用跨区域 S3 复制。
**6.3 日志和诊断。**集中式日志、警报和遥测数据有助于调查故障并验证恢复情况。这些机制支持业务连续性运营，但其本身并不作为单独的备份产品提供。
7. 事件识别与分级处理
**7.1 初步评估。**对报告的事件进行分级处理，以确定其是否符合安全事件的定义、可能受影响的系统或数据、可能的范围和严重程度，以及是否需要立即采取遏制措施。证据保存方式会根据事件性质和涉及的系统作适当处理。
**7.2 值班与升级处理。**ProcessMind 为生产环境事件提供值班支持，包括针对严重事件（定义见《服务级别协议》）提供全天候（24x7）支持，以便随时确认并对事件进行分级处理。
**7.3 文档记录。**ProcessMind 会记录重要的调查结果、响应措施和恢复决策，以便事后审查事件时间线及由此采取的纠正措施。
8. 沟通与通知
**8.1 内部沟通。**ProcessMind 会协调响应人员、决策者和支持渠道，确保在事件整个生命周期内，技术响应与客户沟通保持一致。
**8.2 客户通知。**如发生根据 DPA 或适用法律须予通知的安全事件，ProcessMind 将毫不无故拖延地通知受影响客户，并在可行的情况下，于知悉该事件后七十二（72）小时内通知。通知通常包括事件的性质和范围、已知的受影响数据类别、为遏制和补救事件而采取的措施，以及相关情况下建议客户采取的行动。
**8.3 后续更新。**如事件仍在持续或重要事实发生变化，ProcessMind 将在获得更多经核实的信息后提供后续更新。对于范围较大的生产服务中断，ProcessMind 也可能使用客户支持渠道，并在适当情况下通过公开状态页面 processmind.com/status发布信息。
9. 测试、审查与维护
ProcessMind 至少每年审查这些程序一次，并在发生重大事件或重大架构变更后进行审查；定期演练响应和恢复方法中的相关环节（例如备份恢复、重新构建部署、监控、警报和事件沟通）；并将经验教训纳入其安全、可靠性和业务连续性程序。
10. 限制与合同边界
本文件为高层次摘要，并未详细说明所有内部操作手册、升级路径、调查方法或证据处理步骤。本文件不构成 ProcessMind 承诺采用单独的跨区域故障转移设计、对所有可变存储桶实行不可变存储保留，或提供适用协议或订单中明确规定以外的独立 RTO/RPO 保证。
如本文件与适用的《客户协议》、《数据处理附录》、《服务级别协议》或强制性法律存在任何冲突，应以该等文件或法律为准。