Weblate 事件回應計畫¶
範圍及目標¶
此事件回應計畫涵蓋會影響 Weblate 營運部署環境之機密性、完整性或可用性的事件。
備註
此計畫專為 Weblate s.r.o. 營運的部署環境設計。其他部署環境需依自身環境調整服務提供者及組織專用步驟。
角色和責任¶
事件回應負責人 (IRL)：協調回應過程的所有階段。
系統管理員： 執行圍堵及復原措施。
安全主管： 評估安全性影響及法規後果。
資料保護長 (DPO)： 評估個人資料 (PII) 是否遭到危害，並管理 GDPR 強制通知。
溝通負責人： 視需要管理對內部利害關係人及外部當事方的通知。
溝通工作¶
事件類別與嚴重程度¶
事件啟動¶
確認或高度懷疑某事件對服務的機密性、完整性或可用性造成超出日常營運雜訊的影響時，即應宣布事件。
安全主管 會宣布事件、指定初始嚴重程度，並任命 事件回應負責人 (IRL)。
若安全主管無法處理，任何可聯絡的資深營運人員均可宣布事件，並在可行時盡快移交責任。
若事件範圍或影響在調查期間發生變化，請重新分類事件。
事件類型¶
類別 1 – 未經授權的存取
類別 2 – 資料完整性破壞
類別 3 – 服務中斷或效能降低
類別 4 – 設定錯誤或部署錯誤
嚴重程度層級與 SLA¶
嚴重程度 |
定義 |
目標知悉 |
目標初始動作 |
|---|---|---|---|
重大 |
全面中斷；管理員帳號遭入侵；持續發生資料外洩；需要立即圍堵。 |
< 30 分鐘 |
< 4 小時 |
高 |
核心功能故障；單一使用者的個人辨識資訊外洩。 |
< 2 小時 |
12 小時 |
中 |
效能降低；輕微安全性問題。 |
1 個工作天 |
3 個工作天 |
低 |
使用者介面錯誤；預備環境問題；非安全性錯誤。 |
最佳結果 |
最佳結果 |
事件回應生命週期¶
準備¶
請使用 Weblate 內建的輪替備份功能，確保每天定期備份 PostgreSQL 資料庫及資料目錄；請參閱 備份和移動 Weblate。
確保 Weblate 使用已正確設定 HTTPS (TLS 1.2+) 的反向 Proxy（例如 NGINX）。
為所有管理員層級帳號啟用 2FA。
保持 Weblate 執行個體及其相依套件（Python、Django、Celery、資料庫等）為最新版。
使用 GELF 通訊協定與 SIEM 系統整合，以轉送稽核記錄及應用程式記錄。
辨識¶
監控系統及應用程式記錄（
journalctl、反向 Proxy 記錄、Weblate 應用程式記錄及稽核記錄）。分析登入事件、Webhook 執行及推送／拉取失敗。
針對多次登入失敗、非預期重新啟動或異常 VCS 動作設定警示（透過 Prometheus、Zabbix 或 SIEM）。
抑制¶
建立含有案件 ID 的事件記錄，並在採取動作時記下事件時序更新。
在 Signal 中協調人員回應，並將技術警示保留於現有監控系統。
對於類別 1 或 2 的事件，若情況安全，請先手動建立 Hetzner Cloud Snapshot，再採取可能造成中斷的動作。
名稱格式：
IRP-[CaseID]-[YYYYMMDD]-Evidence。這些快照與標準輪替備份分開，必須保留以供分析。
視需要隔離受影響的主機或服務（例如透過防火牆規則或服務隔離）。
若外部整合 (Git/Webhook) 屬於攻擊途徑的一部分，請將其停用。
立即凍結受影響的使用者帳號。
視情況撤銷或輪替受影響的管理員、API、VCS 及 Webhook 認證資訊。
保留相關證據，包括系統記錄、反向 Proxy 記錄、Weblate 應用程式與稽核記錄、受影響的設定狀態，以及受影響認證資訊或整合的清單。
根除¶
刪除任何未經授權的程式碼或資料。
升級 Weblate 或伺服器元件，以修補已知弱點。
使用 SHA-256 檢查碼或 Git 記錄，驗證二進位檔案及儲存庫的完整性。
復原¶
從最近一份已知正常的 Weblate 備份還原受影響的服務或資料。
PII 評估： DPO 會判斷資料外洩是否需要在 72 小時內發出 GDPR 通知。
分階段重新啟用服務。
還原正常流量前，請確認已排除根本原因，或已採取補償性控制措施。
輪換受影響的憑證並驗證已還原系統、儲存庫和設定的完整性。
安全主管及 IRL 會核准回復正常營運。
復原後至少 72 小時持續監控日誌和系統行為。
事件後審查¶
時程： 在事件結案後 5 個工作天 內召開檢討會議。
彙整完整的事件時序及已採取的動作。
執行根本原因分析（RCA），並於 10 個工作天 內完成記錄。
依調查結果更新安全性原則及 IRP 說明文件。
審查偵測及圍堵機制的有效性。
確認呈報、警示及對外溝通是否如預期遵循 漏洞與事件處理。