Weblate 事件响应计划¶

范围和对象¶

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

备注

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

角色和职责¶

事件响应负责人 (IRL)：协调响应过程的所有阶段。
系统管理员：执行抑制和恢复措施。
安全官：评估安全影响和监管后果。
数据保护官（DPO）： 评估个人数据（PII）是否沦陷并管理强制性的 GDPR 通知。
沟通负责人：管理对内部利益相关者和外部方（如需要）的通知。

沟通工作¶

内部沟通：
- 主要渠道是 Signal，用于人际协作。
- 仍然不会在 Signal 中发布技术警报以避免信息噪音。
外部沟通：
- 电子邮件 用于联系客户。
- 我们在数个地点维护客户联系列表确保在服务中断期间的访问。
公开披露：
- 如果发现了安全漏洞，请按照漏洞和事件处理中的内容行事。

事件类别和严重程度¶

事件激活¶

当确认事件或强烈怀疑事件会给服务带来超出日常运营噪音的机密性、完整性或可用性影响时宣布事故。
安全官 宣布事件，指定初始严重程度并任命 事件响应负责人 (IRL)。
如果没有安全官，任何可用的资深运营者均可宣布事件，并以可行的最快速度移交所有权。
如果事件范围或影响在调查期间改变重新分类事件。

事件类别¶

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

抑制¶

创建有案件 ID 的事件记录并在采取行动时记录时间线更新。
在 Signal 中协调人员响应并在现有监控系统中保留技术警告信息。
** 对于 1 或 2 类事件，在安全情况下，进行破坏性操作前手动创建 Hetzner Cloud Snapshot。
- 名称格式：IRP-[CaseID]-[YYYYMMDD]-Evidence .
- 这些快照和标准轮换备份隔开，必须留存用于事件分析。
按需要隔离受影响的主机或服务（如通过防火墙规则或服务隔离）。
禁用外部集成（Git/webhooks），如果它们是攻击载体的一部分。
立即暂停受影响的用户账户。
如果适用，撤销或轮换受影响的管理、API、VCS 和 webhook 凭据。
保留相关证据，包括系统日志、反向代理日志、Weblate 程序和审计日志，受影响的配置状态、受影响的凭证或集成的列表。

消除¶

删除任何未经授权的代码或数据。
升级 Weblate 或服务器不见打上已知漏洞的补丁。
使用 SHA-256 校验和或 Git 日志验证二进制文件和仓库完整性。

恢复¶

从最新的已知良好的 Weblate 备份中恢复受影响服务或数据。
PII 评估： DPO 决定数据泄露是否需要 72 小时的 GDPR 通知。
分阶段重新引入服务。
恢复正常流量前确认根本原因已解决或存在补偿性控制措施。
轮换受影响的凭证并验证已恢复系统、仓库和配置的完整性。
安全官和事件响应负责人批准回到正常运营。
恢复后至少 72 小时持续监控日志和系统行为。

事件后的调查¶

时间线： 在事件结束的 5 个营业日 内举行一次回顾会议。
编译完整的事件时间线和采取的行动。
执行根源分析（RCA）并在 10 个营业日内 进行文档记录。
基于发现更新安全策略和事件响应计划（IRP)文档。
审核检测和抑制机制的有效性。
验证提升、警报和外部沟通是否如预期遵照漏洞和事件处理规范。