Weblate のインシデント対応計画¶
範囲と目的¶
この IRP は、Weblate のデプロイメントにおける機密性、完全性、または可用性に影響を与えるインシデントを対象とします。
これは、オンプレミスかクラウド環境かを問わず、自己ホスト型 Weblate インスタンスに適用されます。
役割と責任¶
インシデント対応リード（IRL）： 対応プロセスのすべての段階を統括します。
システム管理者： 封じ込めおよび復旧の措置を実行します。
セキュリティ担当者： セキュリティへの影響と規制上の結果を評価します。
コミュニケーションリード： 必要に応じて、内部関係者および外部関係者への通知を管理します。
インシデントの分類¶
カテゴリ 1 – 不正アクセス
カテゴリ 2 – データ完全性の侵害
カテゴリ 3 – サービスの停止または劣化
カテゴリ 4 – 設定ミスまたはデプロイメント エラー
インシデント対応ライフサイクル¶
準備¶
PostgreSQL データベースとデータディレクトリの毎日の定期バックアップを確実に実施します。
NGINX や Apache などのリバースプロキシと、HTTPS（TLS 1.2 以上）を使用して Weblate を保護します。
管理者レベルのアカウントで 2FA を有効にします。
Weblate インスタンスと、その依存関係（Python、Django、Celery、データベースなど）を最新の状態に保ちます。
監査ログおよびアプリケーションログを転送するため、GELF プロトコルを使用して SIEM システムと統合します。
識別¶
システムログおよびアプリケーションログ（
journalctl、リバースプロキシのログ、Weblate のアプリケーションログと監査ログ）を監視します。ログインイベント、Webhook の実行状況、および プッシュ/プル の失敗を分析します。
次の事象に対して、Prometheus、Zabbix、または SIEM などを用いてアラートを設定します： - 複数回のログイン失敗 - 想定外のサービス再起動やメモリ使用量の急増 - バージョン管理システムからの不規則な push／pull 操作
封じ込め¶
一時的にアクセスを制限します（例：ファイアウォールルールの適用やサービスの隔離）。
攻撃経路に関与している場合は、外部連携（Git／Webhook）を無効化します。
影響を受けたユーザーアカウントを直ちに停止します。
根絶¶
不正なコードやデータをすべて削除します。
既知の脆弱性を解消するため、Weblate またはサーバーコンポーネントをアップグレードします。
SHA-256 チェックサムや Git のログを用いて、バイナリおよびリポジトリの整合性を検証します。
復旧¶
影響を受けたサービスやデータを、既知の正常な最新バックアップから復元します。
サービスを段階的に再投入します。
復旧後少なくとも 72 時間は、ログおよびシステムの挙動を継続的に監視します。
インシデント後レビュー¶
インシデントの発生から解決までのタイムラインと、実施した対応内容を整理する。
根本原因分析（RCA）を実施する。
セキュリティポリシーと IRP（インシデント対応計画）文書を更新する。
検知および封じ込めメカニズムの有効性を評価する。