Microsoft Sentinel での分析ルールに関するトラブルシューティングを実行する
この記事では、Microsoft Sentinel でのスケジュールされた分析ルールの実行に関して発生する可能性のある、特定の問題に対処する方法について説明します。
問題点:クエリ結果にイベントが表示されない
イベントのグループ化が各イベントのアラートをトリガーするように設定されている場合、後で表示されるクエリ結果が欠落しているか、予想とは異なるように見える場合があります。 たとえば、関連するインシデントを調査するときにクエリの結果を後で確認することがあり、その調査の一環として、このクエリの前の結果に戻ることにした場合です。
結果は、アラートと共に自動的に保存されます。 ただし、結果が大きすぎる場合、結果は保存されず、クエリ結果をもう一度表示したときにデータが表示されません。
インジェストの遅延が発生した場合、または集計が原因でクエリが決定的ではない場合、アラートの結果は、手動でクエリを実行したときに表示される結果とは異なる場合があります。
この問題を解決するため、Microsoft Sentinel では、ルールにこのイベント グループ化設定がある場合、OriginalQuery フィールドをクエリの結果に追加します。 既存の Query フィールドと新しいフィールドの比較を次に示します。
| フィールド名 | 内容 | このフィールドでクエリを実行した場合の 結果 |
|---|---|---|
| クエリ | このアラート インスタンスを生成したイベントの圧縮レコード。 | このアラート インスタンスを生成したイベント。 10 キロバイトに制限されます。 |
| OriginalQuery | 分析ルールに記述されている元のクエリ。 | クエリによって定義されたパラメーターに適合する、クエリが実行される時間枠内で最新のイベント。 |
つまり、OriginalQuery フィールドの動作は、既定のイベント グループ化設定のもとでの Query フィールドの動作と似ています。
問題点:スケジュールされたルールの実行に失敗するか、名前に「自動無効化」が追加される
スケジュールされたクエリ ルールの実行が失敗することはめったにありませんが、発生する可能性があります。 Microsoft Sentinel は、具体的な障害の種類とそれを引き起こした状況に基づいて、障害を一時的または永続的として事前に分類します。
一時的な障害
一時的な障害は、一時的な状況が原因で発生し、すぐに正常な状況に戻ります。その時点で、ルールの実行は成功します。 Microsoft Sentinel によって一時的として分類される障害の例を次に示します。
- ルール クエリの実行に時間がかかりすぎて、タイムアウトになった。
- データ ソースと Log Analytics 間、または Log Analytics と Microsoft Sentinel 間の接続に問題がある。
- その他の新規および不明な障害は一時的なものと見なされます。
一時的な障害が発生した場合、Microsoft Sentinel では、(ある時点まで) 毎回増分するように事前定義された間隔で、ルールの実行が再試行し続けられます。 その後、ルールは次回のスケジュールされた時刻にのみ再び実行されます。 一時的な障害が原因で、ルールが自動的に無効になることはありません。
永続的な障害 - ルールの自動無効化
永続的な障害は、ルールの実行を許可する条件が変更されたことが原因で発生します。これは、人間の介入なしでは元の状態に戻すことはできません。 永続的として分類される障害の例をいくつか次に示します。
- (ルール クエリが運用されている) ターゲット ワークスペースが削除された。
- (ルール クエリが運用されている) ターゲット テーブルが削除された。
- Microsoft Sentinel がターゲット ワークスペースから削除された。
- ルール クエリで使用される関数が有効ではなくなった (変更または削除された)。
- ルール クエリのいずれかのデータ ソースに対するアクセス許可が変更された (例をご覧ください)。
- ルール クエリのいずれかのデータ ソースが削除された。
同じルールに対して同じ種類の永続的な障害が事前に指定されている回数連続して発生した場合、Microsoft Sentinel ではルールの実行が停止され、次の手順も実行されます。
- ルールを無効にします。
- ルールの名前の先頭に「自動無効化」という単語を追加します。
- 障害 (および無効化) の理由をルールの説明に追加します。
ルールの一覧を名前で並べ替えると、自動無効化されたルールがあるかどうかを簡単に確認できます。 自動無効化されたルールは、一覧の先頭またはその付近にあります。
SOC マネージャーは、自動無効化されたルールがあるかどうかについて、ルールの一覧を定期的に確認する必要があります。
リソースのドレインによる永続的な障害
別の種類の永続的な障害の原因として、不適切に構築されたクエリがあります。これにより、ルールが過剰なコンピューティング リソースを消費し、システムのパフォーマンス低下のリスクを引き起こします。 Microsoft Sentinel でこのようなルールが識別されると、他の種類の永続的な障害について説明したときと同じ 3 つの手順が実行されます。ルールが無効になり、ルール名の前に "AUTO DISABLED" が付加され、エラーの理由が説明に追加されます。
このルールを再度有効にするには、クエリでリソースの使用が多すぎる原因となっている問題に対処する必要があります。 Kusto クエリを最適化するためのベスト プラクティスについては、次の記事を参照してください。
また、追加の支援のために、「Microsoft Sentinel で Kusto 照会言語を操作する際に役立つリソース」も参照してください。
サブスクリプション/テナント間でアクセスが失われたための永続的なエラー
データソースに対するアクセス許可の変更 (一覧を参照) が原因で永続的なエラーが発生する可能性がある場合の具体例として、Microsoft Security ソリューション プロバイダー (MSSP) の場合など、分析ルールがサブスクリプションまたはテナント間でクエリを実行するシナリオに関するものがあります。
分析ルールを作成すると、アクセス許可トークンがルールに適用され、一緒に保存されます。 このトークンを使用すると、ルールのクエリによって参照されたデータを含むワークスペースにそのルールからアクセスできるようになり、ルールの作成者がこのワークスペースへのアクセスを失った場合でも、このアクセスは維持されます。
ただし、例外が 1 つあります。MSSP の場合のように、他のサブスクリプションまたはテナントのワークスペースにアクセスするためのルールが作成される場合、Microsoft Sentinel では顧客データへの無認可のアクセスを防ぐために追加のセキュリティ対策を講じます。 これらの種類のルールには、独立したアクセス トークンではなく、それらに適用されるルールを作成したユーザーの資格情報が含まれます。 ユーザーが他のテナントにアクセスできなくなった場合、そのルールは機能しなくなります。
Microsoft Sentinel をクロス サブスクリプションまたはクロス テナントのシナリオで運用する場合、およびアナリストまたはエンジニアのうちの誰かが特定のワークスペースへのアクセスを失った場合、そのユーザーによって作成されたすべてのルールが機能しなくなります。 "リソースへのアクセスが不十分" という稼働状況の監視に関するメッセージが表示され、ルールは前述の手順に従い自動的に無効になります。
次のステップ
詳細については、次を参照してください。
- チュートリアル: Microsoft Sentinel でインシデントを調査する
- Microsoft Sentinel でのインシデントの確認と調査 - プレビュー
- Microsoft Sentinel でエンティティを使用してデータを分類および分析する
- チュートリアル: Microsoft Sentinel でオートメーション ルールとプレイブックを使用する
また、カスタム コネクタで Zoom を監視するするときにカスタム分析ルールを使用する例も参照してください。