Weblate のインシデント対応計画¶
範囲と目的¶
この IRP は、Weblate のデプロイメントにおける機密性、完全性、または可用性に影響を与えるインシデントを対象とします。
注釈
この計画は Weblate s.r.o. による Weblate のデプロイメント向けに特別に設計されていますが、同様に他のデプロイメントにも適用できます。
役割と責任¶
インシデント対応リード（IRL）： 対応プロセスのすべての段階を統括します。
システム管理者： 封じ込めおよび復旧の措置を実行します。
セキュリティ担当者： セキュリティへの影響と規制上の結果を評価します。
Data Protection Officer (DPO): Evaluates if personal data (PII) was compromised and manages mandatory GDPR notifications.
コミュニケーションリード： 必要に応じて、内部関係者および外部関係者への通知を管理します。
Communication logistics¶
- Internal Communication:
Primary channel is Signal for human-to-human coordination.
Technical alerts remain outside of Signal to avoid noise.
- External Communication:
E-mail is used to reach customers.
Customer contact lists are maintained in several locations to ensure access during service outages.
- Public Disclosure:
If a security vulnerability is discovered, follow 脆弱性およびインシデント対応.
Incident categories and severity¶
インシデントの分類¶
カテゴリ 1 – 不正アクセス
カテゴリ 2 – データ完全性の侵害
カテゴリ 3 – サービスの停止または劣化
カテゴリ 4 – 設定ミスまたはデプロイメント エラー
Severity levels and SLAs¶
重大度 |
Definition |
Target Acknowledge |
Target Initial Action |
|---|---|---|---|
Critical |
Total outage; Admin compromise; Active data breach. |
< 30 Minutes |
4 Hours |
高 |
Core feature failure; PII leak of single user. |
< 2 Hours |
12 Hours |
中 |
Performance degradation; Minor security issue. |
1 Business Day |
3 Business Days |
低 |
UI bugs; Staging issues; Non-security errors. |
Best Effort |
Best Effort |
インシデント対応ライフサイクル¶
準備¶
Ensure regular daily backups of the PostgreSQL database and the data directory using Weblate's built-in backup with rotation, see Weblate のバックアップと移動.
Ensure Weblate uses a properly configured reverse proxy (e.g., NGINX) with HTTPS (TLS 1.2+).
Enable 2FA for all admin-level accounts.
Weblate インスタンスと、その依存関係（Python、Django、Celery、データベースなど）を最新の状態に保ちます。
監査ログおよびアプリケーションログを転送するため、GELF プロトコルを使用して SIEM システムと統合します。
識別¶
システムログおよびアプリケーションログ（
journalctl、リバースプロキシのログ、Weblate のアプリケーションログと監査ログ）を監視します。ログインイベント、Webhook の実行状況、および プッシュ/プル の失敗を分析します。
Configure alerting (via Prometheus, Zabbix, or SIEM) for multiple login failures, unexpected restarts, or irregular VCS actions.
封じ込め¶
- Forensic Preservation: For Category 1 or 2 incidents, create a manual Hetzner Cloud Snapshot before taking disruptive action.
Name format:
IRP-[CaseID]-[YYYYMMDD]-Evidence.These are separate from standard rotating backups and must be preserved for analysis.
一時的にアクセスを制限します（例：ファイアウォールルールの適用やサービスの隔離）。
攻撃経路に関与している場合は、外部連携（Git / Webhook）を無効化します。
影響を受けたユーザーアカウントを直ちに停止します。
根絶¶
不正なコードやデータをすべて削除します。
既知の脆弱性を解消するため、Weblate またはサーバーコンポーネントをアップグレードします。
SHA-256 チェックサムや Git のログを用いて、バイナリおよびリポジトリの整合性を検証します。
復旧¶
Restore affected services or data from the latest known-good Weblate backups.
PII Assessment: DPO determines if the breach requires a 72-hour GDPR notification.
サービスを段階的に再投入します。
復旧後少なくとも 72 時間は、ログおよびシステムの挙動を継続的に監視します。
インシデント後レビュー¶
Timeline: Hold a review meeting within 5 business days of incident closure.
インシデントの発生から解決までのタイムラインと、実施した対応内容を整理する。
Perform Root Cause Analysis (RCA) and document it within 10 business days.
Update security policies and IRP documentation based on findings.
検知および封じ込めメカニズムの有効性を評価する。