Weblate 事件响应计划

范围和对象

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

备注

此计划特为由 Weblate s.r.o 运作的部署而设计。其他部署需调整针对特定提供方的步骤和组织步骤以适合自身的环境。

角色和职责

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

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

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

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

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

沟通工作

  • 内部沟通：

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

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

  • 外部沟通：

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

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

  • 公开披露：

事件类别和严重程度

事件激活

  • Declare an incident when an event is confirmed or strongly suspected to affect the confidentiality, integrity, or availability of the service beyond routine operational noise.

  • The Security Officer declares the incident, assigns the initial severity, and appoints the Incident Response Lead (IRL).

  • If the Security Officer is unavailable, any available senior operator may declare the incident and hand over ownership as soon as practical.

  • Reclassify the incident if the scope or impact changes during investigation.

事件类别

  • 类别 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）。

抑制

  • Create an incident record with a case ID and record timeline updates as actions are taken.

  • Coordinate human response in Signal and keep technical alerting in the existing monitoring systems.

  • ** 对于 1 或 2 类事件，在安全情况下，进行破坏性操作前手动创建 Hetzner Cloud Snapshot。

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

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

  • 按需要隔离受影响的主机或服务（如通过防火墙规则或服务隔离）。

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

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

  • Revoke or rotate affected administrative, API, VCS, and webhook credentials as applicable.

  • Preserve relevant evidence, including system logs, reverse proxy logs, Weblate application and audit logs, affected configuration state, and the list of impacted credentials or integrations.

消除

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

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

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

恢复

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

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

  • 分阶段重新引入服务。

  • Confirm the root cause has been removed or a compensating control is in place before restoring normal traffic.

  • Rotate affected credentials and verify integrity of the restored system, repositories, and configuration.

  • The Security Officer and IRL approve returning to normal operations.

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

事件后的调查

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

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

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

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

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

  • Verify whether escalation, alerting, and external communication followed 漏洞和事件处理 as expected.