Weblate 事件回應計畫¶
範圍及目標¶
此事件回應計畫涵蓋會影響 Weblate 營運部署環境之機密性、完整性或可用性的事件。
備註
此計畫專為 Weblate s.r.o. 營運的部署環境設計。其他部署環境需依自身環境調整服務提供者及組織專用步驟。
處理事件¶
由一位團隊成員負責處理事件，並指定一位有空的隊友擔任備援。兩人會協調調查、封鎖、復原、通報和使用者溝通，並視需要請隊友或外部專家協助。負責人無法處理時，由備援人員接手。
通報決策、期限及私有事件記錄請依照 事件通報 辦理。開始回應不需另外取得管理階層核准。
溝通工作¶
事件類別與嚴重程度¶
事件啟動¶
確認或高度懷疑某事件對服務的機密性、完整性或可用性造成超出日常營運雜訊的影響時，即應宣布事件。
任何發現事件的人都應透過 Signal 通知隊友。由一位有空的隊友接手負責、記錄初步嚴重程度，並指定備援人員。
若事件範圍或影響在調查期間發生變化，請重新分類事件。
事件類型¶
類別 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）。
記錄得知事件的時間，並依照 事件通報 評估是否須通知主管機關和使用者，不要等到調查完成。
請評估安全性事件是否造成個人資料意外或不法銷毀、遺失或變更，或未經授權的揭露或存取，並依照 個人資料外洩通知 辦理。這也包括沒有資料遭揭露的可用性或完整性外洩，例如意外刪除或勒索軟體銷毀資料。如有需要，請尋求隱私權意見，同時繼續調查和準備通報。
個人資料外洩通知¶
事件負責人應判斷 Weblate 對受影響的資料處理活動是控制者還是處理者，並在私有事件記錄中記下評估結果。根據 GDPR 第 33 條：
若 Weblate 是控制者，除非外洩事件不太可能對個人權利和自由造成風險，否則應儘速通知具管轄權的監督機關，並在可行時於得知個人資料外洩後 72 小時內通知。若決定不通知，請記錄理由。
若通知時間超過 72 小時，請說明延遲原因。如果無法一次提供全部資訊，請分階段提供，不得有不必要的延遲。
若 Weblate 是處理者，得知個人資料外洩後應儘速通知控制者；不要等控制者的 72 小時期限。
依第 33(3) 條規定，控制者通知監督機關時必須提供以下資訊：
外洩事件的性質；在可能的情況下，也包括受影響人數及個人資料筆數的類別和約略數量。
可提供進一步資訊者的姓名和聯絡方式，例如事件負責人；如有資料保護長，也可提供其資料。
外洩事件可能造成的後果。
已採取或預計採取的處理措施，包括適當時降低不利影響的措施。
請指出尚無法取得的資訊，並在後續通知中儘速補充。通知主管機關前不必等到取得精確數量。
若 Weblate 是控制者，還應依 GDPR 第 34 條 分別評估是否通知受影響個人。如果外洩事件可能對其權利和自由造成高度風險，除非符合第 34(3) 條的例外情形，否則應儘速通知。即使沒有主動利用或嚴重產品安全性事件也適用。通知監督機關不能取代這項通知。
請使用清楚易懂的語言說明外洩事件，提供進一步資訊的聯絡方式、可能後果、已採取或預計採取的措施，以及個人可以採取的行動。請記錄評估結果及依據的任何例外情形：有效保護受影響資料的措施（例如加密資料，讓未經授權者無法讀取），或後續措施確保高度風險已不再可能發生。如果個別通知需要付出不成比例的努力，請改用公開公告或同等有效的方式通知個人。請參閱 EDPB 個人資料外洩指引。
請將外洩事件得知時間、通知對象和期限與 CRA 通報分開記錄。提交 CRA 報告不能取代 GDPR 通知，且兩者的通報時限起算時間可能不同。
抑制¶
請依照 事件通報 維護私有事件記錄，包括更新時間軸、通報期限和提交收據。
在 Signal 中協調人員回應，並將技術警示保留於現有監控系統。
對於類別 1 或 2 的事件，若情況安全，請先手動建立 Hetzner Cloud Snapshot，再採取可能造成中斷的動作。
名稱格式：
IRP-[CaseID]-[YYYYMMDD]-Evidence。這些快照與標準輪替備份分開，必須保留以供分析。
視需要隔離受影響的主機或服務（例如透過防火牆規則或服務隔離）。
若外部整合 (Git/Webhook) 屬於攻擊途徑的一部分，請將其停用。
立即凍結受影響的使用者帳號。
視情況撤銷或輪替受影響的管理員、API、VCS 及 Webhook 認證資訊。
保留相關證據，包括系統記錄、反向 Proxy 記錄、Weblate 應用程式與稽核記錄、受影響的設定狀態，以及受影響認證資訊或整合的清單。
根除¶
刪除任何未經授權的程式碼或資料。
升級 Weblate 或伺服器組件，以修補已知弱點。
使用 SHA-256 檢查碼或 Git 記錄，驗證二進位檔案及儲存庫的完整性。
復原¶
從最近一份已知正常的 Weblate 備份還原受影響的服務或資料。
分階段重新啟用服務。
還原正常流量前，請確認已排除根本原因，或已採取補償性控制措施。
輪換受影響的憑證並驗證已還原系統、儲存庫和設定的完整性。
事件負責人應記錄回歸正常營運的決定；可行時請與備援人員或其他隊友確認復原情況。
復原後至少 72 小時持續監控日誌和系統行為。
事件後審查¶
時程： 請在事件結束後 5 個工作天內召開簡短團隊檢討。
彙整完整的事件時序及已採取的動作。
執行根本原因分析（RCA），並於 10 個工作天 內完成記錄。
依調查結果更新安全性原則及 IRP 說明文件。
審查偵測及圍堵機制的有效性。
確認呈報、警示及對外溝通是否如預期遵循 漏洞與事件處理。
結束事件記錄前，請檢查是否有尚未提交的報告、承諾的更新或延後的資訊揭露。