インシデント後のレビュー プロセス

インシデント事後レビューの重要な部分は、インシデントの非線形性を反映した、共有された正確な時系列の構築です。

非線形とは、インシデントが通常「この出来事が起こり、その後それが起こって、それから私たちは気づいて、何かを行い、そして完了した」という流れにはならないことを意味します。人々は出たり入ったりし、異なる人々がそれに気づいて、様々なことを試みます。成功するものもあれば、そうでないものもあります。 また、複数のユーザーが同時に作業している場合、これらの処理も同時に発生する可能性があるため、もう少し複雑になります。

複雑なタイムラインであっても、このようなタイムラインを作成するには、常に重要な最初の手順であるデータの収集があります。

データを収集する

インシデント後のレビューを実施する前に、まずデータを収集する必要があります。 具体的には、イベントに含まれるすべての重要なデータを使用できるように、可能な限り多くの会話とコンテキスト (技術的および非技術的) を収集する必要があります。 停止またはインシデントの間に発生したチーム メンバー間の会話は、最も豊富な情報ソースの 1 つです。

また、監視システムや、インシデントに関係する人々がコンテキストを引き出したその他の場所からデータを収集する必要があります。 インシデントが発生したときに、システムからどのような情報が得られましたか?

最後に、可能であれば、インシデントの発生前と発生中に何が変更されたかを把握すると役立ちます。これは、多くの場合、変更がインシデントの発生時に要因となるためです。

このプロセスは、次の 3 つの独立した部分として見ることができます。

• 会話を収集する: このラーニング パスの他のモジュールでは、インシデント中にユーザーがコミュニケーションを取るための特定の場所を切り開することが重要であることを説明しました。 インシデントの間、理想的には、人々は何がうまくいき、何が失敗したか、試してみるのをためらっているのか、過去に何を試したかを共有しています。 問題を解決するユーザー間のこの会話は、学習の最良のソースです。
• コンテキストを決定する: インシデント内のユーザーは、さまざまな場所から信号を受信しています。 1 つの主要な場所は、監視システムです。 このラーニング パスの前のモジュールで、堅牢な監視システムを使用することの重要性について説明しました。 理想的には、監視システムを調べ、インシデントの前後または関連する期間のポイントインタイム スナップショットを作成できる必要があります。
• 変更を見つける: アクティビティ ログと監査ログを使用してこれを行うことができます。

データの収集に役立つAzure ツール

Azureには、このプロセスに役立つさまざまなツールが用意されています。

インシデントに関するメタデータを保持するためのAzure DevOps

このラーニング パスの前のモジュールでは、Azure DevOps スイートのAzure Boardsを 1 つの場所として使用して、最初の応答からインシデントに関するすべての情報を収集する方法について説明しました。 これは、インシデントが最初に宣言された時期、呼び出し中のユーザー、インシデントに割り当てられたユーザーなどに関する質問に役立ちます。 また、Azure DevOps Wiki を一元的な方法として使用して、インシデント自体とインシデント中に発生した会話の両方に関する情報の一部を取り込むこともできます。

会話を抽出するための Microsoft Graph API

Microsoft Graph API は、この特定のインシデントに特化した Teams チャネル内で収集された会話をプログラムで取得する方法を提供します。 取得されるデータには、タイムスタンプ、オーサリング、編集、応答、一部のシステム メッセージが含まれます。これらはすべて、時系列を構築するときに役立ちます。

Microsoft Graph API を使い始める簡単な方法の 1 つは、Microsoft Graph エクスプローラーを使用することです。 Microsoft Graph Explorer は Web ベースの API ブラウザーで、Sample クエリ パネルから API 呼び出しを選択し、対話形式で試すことができます。

クエリを実行する前に、使用しているユーザーまたはアプリに、選択したアクセス モードに必要なアクセス許可と同意があることを確認します。 委任されたシナリオでは、参加したチームの一覧表示では Team.ReadBasic.Allが使用され、登録チャネルでは Channel.ReadBasic.Allが使用され、チャネル メッセージの読み取りには ChannelMessage.Read.Allが必要です。 後でアプリ専用アクセスを使用してワークフローを自動化する場合は、委任されたGET /users/{id | user-principal-name}/joinedTeamsエイリアスではなく、/me/joinedTeams アプリケーションのアクセス許可を使用してTeam.ReadBasic.Allを使用します。 チャネル固有の読み取り手順では、リソース固有の同意を必要とする最小特権のアプリ専用オプションとして、チャネルを一覧表示するためのChannelSettings.Read.Group オプションおよびメッセージを読み取るためのChannelMessage.Read.Group オプションがあります。

Microsoft Graph v1.0 の "Microsoft Teams" API 呼び出しの一連の手順を踏んで、会話を取得します。 (チャネル メッセージは数年前にベータ版から v1.0 に移行されているため、このシナリオではベータ エンドポイントは不要になりました)。各手順では、クエリを選択し、クエリを実行し、次の手順に役立つ情報を応答から選択します。 次に、この情報を使用して次の要求を作成します。 たとえば、最初にチーム ID の一覧を照会して、所属するチームを表示します。 応答から必要なものを選択し、この ID を次のクエリ URL に挿入して、そのチーム内のチャネルの一覧を取得します。

Microsoft Graph v1.0 エンドポイントとして示されている手順は次のとおりです。

1. GET /me/joinedTeams (委任されたシナリオで使用するチームのチーム ID を検索するため) または GET /users/{id | user-principal-name}/joinedTeams (アプリ専用シナリオで同じ操作を行う場合)。
2. GET /teams/{team-id}/channels (そのインシデントに使用したチャネルのチャネル ID を検索する場合)。
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (スレッド化された会話を取得するため)。
4. 必要に応じて @odata.nextLink と replies@odata.nextLink に従うか、 GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies を呼び出して大きなスレッドをページングします。

共有チャネルを使用した場合、 joinedTeams API は、ユーザーが直接メンバーである共有チャネルのホスト チームを返さないことに注意してください。 この注意事項は、 GET /me/joinedTeams と GET /users/{id | user-principal-name}/joinedTeamsのどちらを呼び出すかに関係なく適用されます。 その場合は、既知のチームとチャネル識別子から開始するか、関連付けられているチーム API を使用してホスト チームを見つけます。

Graph Explorer では、これらの URL を直接入力するか、Microsoft TeamsSample クエリ パネルから同等のエントリを選択>。

これらの各手順を実行するプログラムを後で作成する場合 (実際には実行します)、要求ウィンドウに、そのクエリのサンプル コードをさまざまなプログラミング言語で表示するコード スニペット オプションがあります。

チームでの Teams の使用方法に応じて、メンバーがいつ追加または削除されたかを説明するのに役立つシステム メッセージをメッセージ履歴に含めることもできます。 ただし、チャネル メンバーシップまたはアクセス変更の権限のある監査証跡が必要な場合は、Microsoft 365監査ログでこのデータを補完します。

コンテキスト表示用のダッシュボードとワークブック

AzureダッシュボードとAzure Monitorブックは、インシデント発生時にオペレーターが見たコンテキストを再構築するのに役立ちます。 ダッシュボードは、Azure サービス全体の操作の概要をひとめで確認するのに役立ちます。 ワークブックは、グラフと共に豊富なクエリ、パラメーター、ドリルダウン、説明文をサポートするため、通常、インシデント分析に適しています。

適切なシグナルをキャプチャするダッシュボードまたはブックが既にある場合は、その時間範囲をインシデントの前後の期間に設定し、それを使用して、その時点でユーザーが見たものを再構築します。 これは、メトリック、ログ、アラートを複数のリソースに関連付ける場合に特に役立ちます。

共有ダッシュボードはリソースAzureであり、引き続きポータルから JSON としてエクスポートできます。 このエクスポート/インポート パスは、ダッシュボードをバージョン管理またはテンプレート化する場合に便利です。 ただし、インシデント調査後のほとんどのシナリオでは、視覚化、KQL クエリ、説明テキストを 1 つの成果物に結合できるため、ブックはより柔軟なツールになります。

変更の探索用のアクティビティ ログ、リソース ログ、およびLog Analytics

Log Analytics ワークスペースは、Azureアクティビティ ログ、Azure リソース ログ、サービス固有の診断など、多くのソースからのデータを取り込むことができます。 まず、新しい Log Analytics ワークスペースを作成します。 次に、Azure ポータルで、Monitor → アクティビティ ログを開き、ウィンドウの上部にある Export アクティビティ ログ を選択します。 これにより、Azure サブスクリプションのアクティビティ ログをワークスペースに送信できる診断設定が開きます。

短時間で、Kusto クエリ言語 (KQL) を使用して、データ ソースを接続してからそのサブスクリプションで行われた変更に関する詳細情報を取得できます。

たとえば、次のクエリは、変更または削除されたリソースに関する情報を示しています。 ログ エクスペリエンスの時間の範囲を、インシデントの直前の期間により正確に設定できます。

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc

このクエリは、管理プレーンの変更に役立ちますが、表示されない内容を覚えておいてください。 AzureActivity は、作成、更新、削除、ポリシー アクションなどのコントロール プレーン操作をキャプチャします。 サービス内のデータ プレーンまたはアプリケーション レベルの変更はキャプチャされません。 それらを調査するには、このクエリをAzureリソース ログ、サービス固有の監査ログ、デプロイ履歴、CI/CD またはソース管理レコードと組み合わせて使用します。

1 つの簡単な注意: Azure アクティビティ ログをエクスポートすると、その時点から情報が Log Analytics ワークスペースに流れ始めます。 接続前に発生したイベントについて、そのワークスペースにさかのぼってクエリを実行することはできません。

これらのツールを使用すると、インシデント後のレビューで時系列を使用するために必要な情報の収集を開始できます。 インシデント後のレビューに進む前に、いくつかの一般的なトラップについて警告します。 それが次のユニットのテーマです。