Weblate 事件响应计划

范围和对象

事件响应计划涵盖影响 Weblate 部署机密性、完整性、或可用性的事件。

备注

本计划是特别为部署 Weblate s.r.o 的 Weblate 设计的，但可以相似地应用到其他部署上。

角色和职责

  • 事件响应负责人 (IRL)：协调响应过程的所有阶段。

  • 系统管理员：执行抑制和恢复措施。

  • 安全官：评估安全影响和监管后果。

  • 数据保护官 （DPO）： 评估个人数据 （PII）是否沦陷并管理强制性的 GDPR 通知。

  • 沟通负责人：管理对内部利益相关者和外部方（如需要）的通知。

沟通工作

  • 内部沟通：

    • 主要渠道是 Signal，用于人际协作。

    • 仍然不会在 Signal 中发布技术警报以避免信息噪音。

  • 外部沟通：

    • 电子邮件 用于联系客户。

    • 我们在数个地点维护客户联系列表确保在服务中断期间的访问。

  • 公开披露：

事件分类和严重程度

事件类别

  • 类别 1 – 未经授权的访问

  • 类别 2 - 数据完整性违背

  • 类别 3 - 服务中断或降级

  • 类别 4 - 配置错误或部署错误

严重程度和 SLA

严重程度

定义

目标确认

目标初始行动

严重

完全中断；管理权限沦陷；活跃的数据泄露。

< 30 分钟

4 小时

高

核心功能不工作；单一用户的个人数据泄露。

< 2 小时

12 小时

中

性能降级；不大的安全问题。

1 个营业日

3 个营业日

低

用户界面 bug；Staging 问题；非安全问题。

最大努力

最大努力

事件响应生命周期

准备

  • 使用 Weblate 的内置备份轮换确保 PostgreSQL 数据库和数据目录的每天常规备份，见 备份和移动 Weblate。

  • 确保 Weblate 使用正确配置的有 HTTPS（TLS 1.2+）的反向代理。

  • 所有管理员级别账户启用 2FA。

  • 保持 Weblate 实例及其依赖项（Python、Django、Celery、数据库等）为最新版。

  • 用 GELF 协议和 SIEM 系统集成，用于审计和程序日志转发。

识别

  • 监控系统和程序日志（journalctl、反向代理日志、Weblate 程序和审计日志）。

  • 分析登录事件、webhook 执行、推送/拉取失败。

  • 为多次登录失败、意外重启或异常的 VCS 操作配置警报（通过 Prometheus、Zabbix 或 SIEM）。

抑制

  • 取证留存： 对于 1 或 2 类事件，进行破坏性操作前手动创建 Hetzner Cloud Snapshot。

    • 名称格式：IRP-[CaseID]-[YYYYMMDD]-Evidence .

    • 这些快照和标准轮换备份隔开，必须留存用于事件分析。

  • 临时限制访问（如通过防火墙规则或服务隔离）。

  • 禁用外部集成（Git/webhooks），如果它们是攻击载体的一部分。

  • 立即暂停受影响的用户账户。

消除

  • 删除任何未经授权的代码或数据。

  • 升级 Weblate 或服务器不见打上已知漏洞的补丁。

  • 使用 SHA-256 校验和或 Git 日志验证二进制文件和仓库完整性。

恢复

  • 从最新的已知良好的 Weblate 备份中恢复受影响服务或数据。

  • PII 评估： DPO 决定数据泄露是否需要 72 小时的 GDPR 通知。

  • 分阶段重新引入服务。

  • 恢复后至少 72 小时持续监控日志和系统行为。

事件后的调查

  • 时间线： 在事件结束的 5 个营业日 内举行一次回顾会议。

  • 编译完整的事件时间线和采取的行动。

  • 执行根源分析（RCA）并在 10 个营业日内 进行文档记录。

  • 基于发现更新安全策略和事件响应计划（IRP)文档。

  • 审核检测和抑制机制的有效性。