Close

インシデント管理改善への道はここから始まります

インシデント対応のライフサイクルについて知る

セキュリティとインシデント管理のプロとともに働く時間が長くなると、あるパターンに気づくでしょう。このような業界で最も賢い人々は、直線ではなくサイクルとして物事を捉えています。

なぜでしょうか? それは何を意味するのでしょうか? これが意味するのは、一つひとつのインシデントと機能停止は、開始点と終了点を持つ孤立したイベントではないということです (ただし、そのように見えるかもしれません)。インシデントは学習の機会です。

サービスが再び「運用可能」になったからといって、チームの作業が終わったわけではありません。インシデント後のアクティビティとして、将来のロードマップに基づいて計画を立て、将来のインシデントに備える方法を変更し、将来のインシデントの増加を防ぐ新しい方法を発見する必要があります。これは終わりなき改善サイクルであり、自分の考え方の基盤となる思想に応じて、さまざまな段階とさまざまな考え方が存在します。

インシデント対応のライフサイクルとは?

インシデント対応とは、サイバー攻撃、セキュリティ侵害、サーバーのダウンタイムなどの IT の脅威に対応する組織のプロセスです。

インシデント対応のライフサイクルは、サービスの停止やセキュリティの脅威を特定して対応するための、組織の段階的なフレームワークです。

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

Atlassian のインシデント対応のライフサイクルのチャート

1. インシデントを検出する

Atlassian のインシデント検出は通常、モニタリング ツールとアラート ツールから始まります。ただし、お客様やチーム メンバーからインシデントについて最初に知ることもあります。

2. チームのコミュニケーション チャンネルを設定する

最初の重要なステップは、インシデント チームのコミュニケーション チャンネルを設定することです。この時点での目標は、専用の Slack チャンネルやビデオ カンファレンス ブリッジなど、よく知られている場所にチームのコミュニケーションを集中させることです。

3. 影響を評価して、重大度レベルを適用する

ここで、インシデントの影響を評価すべきです。これにより、チームが他の誰に連絡して顧客や関係者に何を伝えるべきかを決定できるようになります。

4. 顧客に伝える

Atlassian では、社内外の関係者にできるだけ早く伝えることを目指しています。迅速かつ正確に伝えることで、顧客や組織のその他の関係者との信頼関係を築くのに役立ちます。

5. 適切な対応者にエスカレートする

最初の対応者はしばしば、Opsgenie などのアラート ツールを使用して他のチームに通知することで、インシデントに他のチームを参加させる必要があります。

6. インシデント対応ロールを委任する

別のチーム メンバーが対応に参加するのに応じて、インシデント マネージャーがこれらのメンバーにロールを委任します。

7. インシデントを解決する

現在または差し迫ったビジネスへの影響が終了したら、インシデントが解決したと言えます。その時点で緊急対応プロセスは終了して、チームはクリーンアップ タスクと事後分析に移行します。

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

もう 1 つの業界標準のインシデント対応のライフサイクルは、米国国立標準技術研究所 (NIST) に由来します。NIST は、インシデント対応やサイバーセキュリティなどのトピックに関する基準と慣行を設定する政府機関です。

NIST は国立標準技術研究所を表します。NIST は米国政府機関であり、自らを誇らしげに「国内最古の物理科学研究所の 1 つ」だと公言しています。NIST はサイバーセキュリティを含む、あらゆるテクノロジーに関わる業務を行っています。この分野において NIST は、インシデント対応手順を使用したインシデント対応に関する 2 つの主力の業界標準の 1 つとなっています。

NIST は Atlassian と同様、すべてのインシデントを防げるわけではないと考えています。このため、準備することが最善です。

「リスク評価の結果に基づく予防アクティビティにより、インシデントの数を減らせますが、すべてのインシデントが防げるわけではありません。したがって、インシデントの迅速な検出、損失と破壊の最小化、悪用される弱点の軽減、IT サービスの復元には、インシデント対応機能が必要になります」— NIST

NIST のインシデント対応のライフサイクルでは、インシデント対応を「準備」、「検出と分析」、「封じ込め、根絶、回復」、「イベント後のアクティビティ」の 4 つのフェーズに分けています。

フェーズ 1: 準備

準備フェーズは、インシデント対応に備えるために組織が実施する作業が対象です。これには、適切なツールとリソースの確立や、チームのトレーニングが含まれます。このフェーズには、インシデントが発生しないようにするための作業が含まれます。

フェーズ 2: 検出と分析

NIST によると、インシデントを正確に検出して評価することは往々にして、多くの組織にとってインシデント対応における最も困難な作業となります。

フェーズ 3: 封じ込め、根絶、回復

このフェーズでは、インシデントの影響を可能な限り小さく保って、サービスの中断を軽減することに重点を置きます。

フェーズ 4: イベント後のアクティビティ

インシデント後の学習と改善は、インシデント対応の最も重要な作業の 1 つでありながら、最も軽視されるものです。このフェーズでは、インシデントとインシデント対応の取り組みを分析します。ここでの目標は、インシデントが再発生する可能性を制限して、将来のインシデント対応アクティビティを改善する方法を特定することです。

現代の DevOps チームのインシデント対応

Over the past decade, the DevOps movement has helped teams reshape how they build, deploy, and operate software. Along with that are innovations on how these teams respond to incidents.

インシデント管理に対する DevOps のアプローチは、効果的なインシデント管理のための従来の手順と劇的に違うわけではありません。DevOps インシデント管理では、最初からオンコールを含む開発者チームを関与させることと役職ではなく専門知識に基づいて作業を割り当てることを、明示的に重視しています。

インシデント対応と継続的な改善

この記事は、サイクルと直線の違いについて説明することから始まりました。これらすべてのインシデント管理アプローチに共通していること、すなわち、これらのアプローチが直線的ではないことにお気付きでしょう。各アプローチには、同じ基本コンポーネント パーツが含まれています。すなわち、インシデントを定義、検出、識別する方法、インシデントに迅速に対応して軽減するための措置を講じる方法、インシデントを分析して将来の検出と対応を向上させる方法です。すでに発生したインシデントをそのインシデントのためだけに分析しても無意味です。時間を遡って、起こったことを変えることはできません。インシデントから学習するのは、今後の検出と対応を改善するためです。不断の継続的な学習と改善が、チームがそのサイクルを終わらせるのです。

次の記事
On call