Weblate のインシデント対応計画

範囲と目的

This IRP covers incidents impacting the confidentiality, integrity, or availability of Weblate-operated deployments.

注釈

This plan is specifically designed for deployments operated by Weblate s.r.o. Other deployments need to adapt provider-specific and organizational steps to their own environment.

Handling an incident

One team member handles the incident and names an available teammate as a backup. They coordinate investigation, containment, recovery, reporting, and user communication, asking other teammates or outside specialists for help when needed. The backup takes over when the handler is unavailable.

Use Incident reporting for reporting decisions, deadlines, and a private incident note. No separate management approval is needed to begin responding.

コミュニケーション上の調整事項

• 内部向けコミュニケーション：

  • 主要な連絡チャネルは、人同士の調整に Signal を使用します。

  • 技術的な警告はノイズを避けるため、Signal には流さないようにします。

• 対外コミュニケーション：

  • 顧客への連絡には メール を使用します。

  • サービス停止中にも接続できるよう、顧客連絡先一覧は複数の場所で管理しています。

• 公開情報の開示：

  • If an incident includes a Weblate product vulnerability, follow the product vulnerability reporting process and 脆弱性開示ポリシー in 脆弱性およびインシデント対応.

インシデントの分類と重大度

Incident activation

• 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.

• Whoever identifies the incident alerts teammates through Signal. An available teammate takes responsibility, records the initial severity, and names a backup.

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

インシデントの分類

• カテゴリ 1 – 不正アクセス

• カテゴリ 2 – データ完全性の侵害

• カテゴリ 3 – サービスの停止または劣化

• カテゴリ 4 – 設定ミスまたはデプロイメント エラー

重大度レベルと SLA（サービスレベル合意）

These are operational response targets, not a statement of continuous staffing. Assess product-security reporting separately using Incident reporting; these targets do not extend reporting deadlines.

重大度	用語の定義	目標応答時間	初動対応の目標時間
重大（クリティカル）	Total outage; Admin compromise; Active data breach; requires immediate containment.	30 分以内	< 4 Hours
高	コア機能の障害; 単一ユーザーの個人情報漏えい。	2 時間以内	12 時間
中	性能劣化; 軽度のセキュリティ上の問題。	1 営業日	3 営業日
低	UI の不具合; ステージング環境での問題; 非セキュリティ系のエラー。	ベストエフォート	ベストエフォート

インシデント対応ライフサイクル

準備

• PostgreSQL データベースおよびデータディレクトリについて、Weblate のローテーション付き組み込みバックアップ機能を用いて、日次の定期バックアップを確実に実施してください。参照: Weblate のバックアップと移動。

• Weblate は、HTTPS（TLS 1.2 以上）を有効化した適切に設定済みのリバースプロキシ（例：NGINX）経由で運用することが必要です。

• 管理者レベルのすべてのアカウントで 2FA を有効化してください。

• Weblate インスタンスと、その依存関係（Python、Django、Celery、データベースなど）を最新の状態に保ちます。

• 監査ログおよびアプリケーションログを転送するため、GELF プロトコルを使用して SIEM システムと統合します。

• Complete the preparation checklist in Incident reporting and keep private contact and access details current.

識別

• システムログおよびアプリケーションログ（journalctl、リバースプロキシのログ、Weblate のアプリケーションログと監査ログ）を監視します。

• ログインイベント、Webhook の実行状況、および プッシュ/プル の失敗を分析します。

• 複数回のログイン失敗、予期しない再起動、異常な VCS アクションを監視し、Prometheus、Zabbix、SIEM などで警告を適切に設定してください。

• Record awareness times and assess authority and user notifications using Incident reporting, without waiting for a complete investigation.

• Assess whether a security incident caused accidental or unlawful destruction, loss, or alteration of personal data, or unauthorized disclosure or access, and follow Personal-data breach notifications. This includes availability or integrity breaches without disclosure, such as accidental deletion or ransomware destruction. Seek privacy advice where needed while continuing investigation and reporting preparation.

Personal-data breach notifications

The incident handler determines whether Weblate acts as controller or processor for the affected processing and records the assessment in the private incident note. Under GDPR Article 33:

• As controller, notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the personal-data breach, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. Record the reason for a decision not to notify.

• If notification takes longer than 72 hours, include the reasons for the delay. Where information cannot be supplied together, provide it in stages without undue further delay.

• As processor, notify the controller without undue delay after becoming aware of a personal-data breach; do not wait for the controller's 72-hour deadline.

The controller's supervisory-authority notification must include the following information under Article 33(3):

• The nature of the breach, including, where possible, the categories and approximate numbers of affected individuals and personal-data records.

• The name and contact details of the person who can provide further information, such as the incident handler or a data protection officer if one is appointed.

• The likely consequences of the breach.

• Measures taken or proposed to address the breach, including measures to reduce its adverse effects where appropriate.

Identify information that is not yet available and provide it in follow-up notifications without undue further delay. Do not wait for exact counts before notifying the authority.

As controller, separately assess communication to affected individuals under GDPR Article 34. If the breach is likely to create a high risk to their rights and freedoms, inform them without undue delay unless an Article 34(3) exception applies. This applies even without active exploitation or a severe product-security incident. Notification to the supervisory authority does not replace this communication.

Explain the breach in clear language, giving a contact for further information, likely consequences, measures taken or proposed, and actions individuals can take. Record the assessment and any exception relied on: effective protection of the affected data, such as encryption making it unreadable to unauthorized people, or subsequent measures ensuring the high risk is no longer likely. If individual communication would involve disproportionate effort, use public communication or a similar measure that informs individuals equally effectively. See the EDPB data-breach guidance.

Record breach-awareness timestamps, recipients, and deadlines separately from CRA reporting. A CRA submission does not replace a GDPR notification, and the two reporting clocks may start at different times.

封じ込め

• Maintain the private incident note from Incident reporting, including timeline updates, reporting deadlines, and submission receipts.

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

• For Category 1 or 2 incidents, create a manual Hetzner Cloud Snapshot before taking disruptive action when it is safe to do so.

  • 名前形式: IRP-[CaseID]-[YYYYMMDD]-Evidence。

  • これらは通常のローテーションバックアップとは独立しており、後続の分析に備えて必ず保全してください。

• Isolate the affected host or service as needed (for example by firewall rules or service isolation).

• 攻撃経路に関与している場合は、外部連携（Git / Webhook）を無効化します。

• 影響を受けたユーザーアカウントを直ちに停止します。

• 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 バックアップから復元してください。

• サービスを段階的に再投入します。

• 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 handler records the decision to return to normal operations, checking recovery with the backup or another teammate where practical.

• 復旧後少なくとも 72 時間は、ログおよびシステムの挙動を継続的に監視します。

インシデント後レビュー

• Timeline: Hold a short team review within 5 business days of incident closure.

• インシデントの発生から解決までのタイムラインと、実施した対応内容を整理する。

• 根本原因分析（RCA）を実施し、結果を 10 営業日以内 に文書化すること。

• 調査結果を踏まえ、セキュリティポリシーおよび IRP（インシデント対応手順）文書を更新すること。

• 検知および封じ込めメカニズムの有効性を評価する。

• Verify whether escalation, alerting, and external communication followed 脆弱性およびインシデント対応 as expected.

• Check for outstanding reports, promised updates, and delayed disclosures before closing the incident note.