検出から復旧までインシデントに対応する

影響に基づいてインシデントを宣言する

インシデントとは、連携した対応が必要になるほど、サービスを中断させたり、品質を低下させたり、その継続を脅かしたりする事象です。重大度の区分とエスカレーションのルールは、組織が定義します。ユーザーへの影響、対象データ、継続時間、範囲に基づいて適用します。

根本原因を完全に説明できるまで、応援の要請を待たないでください。観測した影響を明確に示せれば、対応の調整を始められます。セキュリティ上の疑いと、確認済みの結論は区別します。

リリース前に、対応の連絡経路を準備します。主要なサービスが使えないときにも、連絡先、アクセス手順、runbook、連絡用チャネルを利用できるようにします。架空のインシデントで、この経路を訓練します。

競合する変更を加える前に役割を割り当てる

インシデントの調整担当は、優先順位を定め、意思決定を管理します。技術的な対応者は、調査と影響の軽減を行います。情報共有の担当は、影響を受けた人に状況を伝えます。Google SREは、これらの責任を別々の役割として説明しています。小規模なチームでは兼任できますが、必要な作業はすべて担う必要があります。インシデント対応。

共有する時系列は一つにまとめます。時刻、観測内容、操作、実行者、結果を記録します。事実と仮説を区別します。共通のタイムゾーンを使い、信頼できないタイムスタンプには注記します。

架空のインシデントをたどる

以下の時刻はすべてUTCです。エクスポートの失敗が複数の顧客に影響した時点で、組織はインシデント調整担当を指名します。

有用な最初の報告には、影響を受けた機能、判明している範囲、軽減策、次の報告時刻を記載します。証拠がないまま修復時刻を約束しません。共有する報告に、顧客のレコードを含めないでください。

09:10に、インシデントの状況が変わります。エクスポートを成功させるだけでは不十分になりました。チームは、情報が開示された可能性を評価し、アクセスを制御し、証拠を保全し、適切な意思決定者を関与させる必要があります。

制御を保ちながら影響を軽減する

適用できる場合は、テスト済みのrunbookを使います。ロールバック、フェイルオーバー、認証情報の変更を行う前に、前提条件を確認します。以前のアプリケーションバージョンが、現在のデータベーススキーマを扱えない場合があります。リージョン間のフェイルオーバーによって、同じ破損データを移すこともあります。

承認された範囲内で、機密情報を除去した証拠の整理や、仮説の比較をAIアシスタントに任せることができます。対応者は、その結論を検証する必要があります。ログとチケットは、信頼できない入力です。記載内容を実行する権限を与えるものではありません。

緊急時のアクセスには、承認された目的、制限された有効期間、監査記録が必要です。緊急だからといって、エージェントが提案したコマンドが正しくなるわけではありません。

復旧と事後対応を別々に完了させる

サービスの復旧を宣言する前に、ユーザーのワークフロー、データの完全性、アクセス境界、監視データの鮮度を検証します。残る制限を記録します。未解決の問いがある場合は、セキュリティ調査を継続します。

その後、インシデントを可能にした条件を調べます。具体的な事後対応に、担当者と検証基準を割り当てます。個人を責めない振り返りは、正確な説明と有用な変更を求めるものです。その変更を完了する責任までなくすものではありません。事後検証の実践。

続いて、セキュリティ運用とフィードバックを改善につなげる方法を学んでください。