mcpField
S
sentinel

sentinel

github.com/vinayaklattheセキュリティ17980 回インストール1 日前に更新
リポジトリ

sentinel について

ログの集約、検知、データハンティング、自動対応を行うセキュリティ運用チーム向けの Microsoft Sentinel ガイダンススキルです。取り込み階層とコスト、ワークスペース、コネクタ、KQL、UEBA、Logic Apps のプレイブックを扱います。

主な機能

  1. 01ログ取り込み階層とコストの計画
  2. 02Log Analytics ワークスペースの設計
  3. 03Microsoft とサードパーティの接続
  4. 04分析ルールとインシデントグループ化
  5. 05KQL ハンティングと UEBA の有効化
  6. 06ルールとプレイブックによる対応自動化

活用シーン

  1. 01新しいテナントの初期コネクタ選定
  2. 02大量ログの取り込み階層の最適化
  3. 03セキュリティ検知ルールの作成と調整
  4. 04アラートのトリアージと対応プレイブックの構築

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill sentinel

インストール後、Claude Code で/sentinelを入力して読み込まれたか確認します。

詳細

Microsoft Sentinel

Microsoft Sentinel は、Log Analytics ワークスペース上に構築され、統合 SecOps プラットフォームの一部として Microsoft Defender ポータルから提供される、クラウドネイティブの SIEM + SOAR です。Microsoft およびサードパーティのソースからログを取り込み、KQL でスケジュール実行およびほぼリアルタイムの検出を行い、アラートをインシデントに関連付け、Logic Apps のプレイブックを通じて対応をオーケストレーションします。

使用する場面

Microsoft およびサードパーティのソースからセキュリティログを一元化し、検出ルールを作成し、データ全体を調査し、対応を自動化します。Microsoft 365 だけでなく、クラウド、オンプレミス、SaaS にまたがる単一の SIEM が必要な場合に Sentinel を使用してください。

このスキルを使用しないでください。目的が M365 アラートの関連付けだけの場合は defender-xdr を使用し、既存の Sentinel ワークスペースを統合 Defender ポータルにオンボードする場合は unified-secops-platform を使用してください。

ログソースを適切な取り込み層に振り分ける

まず層を選び、次にコネクタを選択します。コストに最も大きく影響するのは層の選択です。

ログの種類送信先デフォルトの保持期間コストの仕組み
検出に使用する高精度なセキュリティログ（サインイン、監査、EDR）Analytics90 日間は無料、その後は有料GB 単位の従量課金（コミットメント層）
詳細だが、たまにしかクエリしないログ（CDN、カスタムアプリ、ファイアウォール情報）Basic logs30 日間、分析ルールは利用不可Analytics の約 1/5
大量で精度が低く、検索のみを行うログ（NetFlow、DNS、プロキシ）Auxiliary logsホットストレージで 30 日間 + 長期ストレージで 12 か月Analytics の約 1/8
コンプライアンスまたはまれな調査のための長期アーカイブAzure Data Explorer (ADX)数年間ADX クラスターのコスト
Microsoft 365 / Defender XDR のアラートのみM365 Defender コネクタ経由で無料該当なし無料

経験則（2026 年の料金）： テーブルの平均取り込み量が 1 日あたり 50 GB を超え、分析ルールからクエリされない場合は、Analytics 層に配置すべきではありません。DNS またはプロキシログを Auxiliary に移行すると、通常 Sentinel の料金を 30～50% 削減できます。

アプローチ

  1. データ量を見積もり、コミットメント階層を選択する — Sentinel の料金計算ツールで30日間のサンプルを実行します（Usage | summarize sum(Quantity) by bin(TimeGenerated, 1d), DataType を使用します）。 コミットメント階層は100 GB/日から利用でき、GBあたりの料金は従量課金と比べて約50％低くなります。 確認：コミットする前に、1日あたりの取り込み量が見積もりの±20％以内で安定していることを確認します。

  2. ワークスペースの設計 — 原則として、テナントごとに1つの中央 Log Analytics ワークスペースを使用します。 ワークスペースを分割するのではなく、Azure RBACとテーブルレベルのRBACを使ってスコープを設定します。エグレスとレイテンシを減らすため、データの大半が生成されるリージョンにワークスペースを配置します。 確認：主要な検出でクロスワークスペースクエリが不要であることを確認します。必要な場合は、分割しすぎています。

  3. データソースを優先順位順に接続する — M365 テナントの約80％をカバーする上位5つのコネクタは、Entra ID（サインイン＋監査）、Office 365（Exchange＋SharePoint）、Defender XDR（アラート＋未加工の高度なハンティング）、Azure Activity、Microsoft Threat Intelligenceです。 サードパーティ向けでは、Codeless Connector Platform > AMA/syslog/CEF > Logstash の順です。 確認：union withsource=Tbl * | summarize count() by Tbl, bin(TimeGenerated, 1h) により、途切れることなくデータが取り込まれていること（横ばいになっていないこと）を確認します。

  4. 未加工のルールではなくソリューションを有効にする — Content Hubからインストールします（Entra ソリューション、MDE ソリューションなど）。コネクタ、パーサー、ブック、ハンティングクエリ、分析ルールをまとめてインストールできます。テンプレートを調整し、ゼロから作成するのは避けます。

  5. 分析ルール — 広く開始し、すばやく調整する — インストールしたソリューションの組み込みテンプレートをすべて、ほぼリアルタイムモードまたはスケジュールモードで有効にします。最初の週は10～20件の誤検知ルールが発生することを想定し、無効にするのではなく、エンティティのマッピングとしきい値を調整します。インシデントのグループ化設定を使い、関連するアラートをインシデントにまとめます。

  6. ハンティングとUEBA — EntraとオンプレミスのADデータ（IdentityInfo、BehaviorAnalytics テーブル）でUEBAを有効にします。組み込みのハンティングクエリを毎週使用し、有用なハンティングをスケジュール済みルールに昇格させます。

  7. 自動化 — トリアージ（割り当て、タグ付け、ノイズの多い真陽性のクローズ）には自動化ルールを、対応（Teamsへの通知、TIによる情報補完、デバイスの隔離、ユーザーの無効化）にはLogic Apps のプレイブックを使用します。カバレッジのレポート作成に備え、すべてのルールをMITRE ATT&CKにマッピングします。

  8. 毎月コストを見直す — Usage テーブルで、データ量の多い上位テーブルを確認し、価値の低いテーブルをBasic/Auxiliaryに移行します。テーブルレベルの保持期間を意図的に設定します。コネクタの設定ミス（デバッグログが有効なままになっているなど）に注意します。

ガードレール

  • コミットする前に見積もる。 コミットメント階層は1日あたりの最低料金が課されます。30％過剰にコミットすると、従量課金より高くなります。まず30日間は従量課金を利用してから、コミットします。
  • 重複した取り込みを避ける。 特定の検出で両方が必要な場合を除き、Defender XDRの未加工イベントと高度なハンティングを両方取り込まないでください。二重に料金がかかります。
  • 複数のワークスペースではなく、テーブルレベルのRBACを使用する。 ワークスペースを分割するとコネクタのコストが倍増し、ソース間の検出が機能しなくなり、インシデント対応が複雑になります。
  • テーブルごとに保持期間を設定する。 既定の90日間はすべてのAnalyticsテーブルに適用されます。使用頻度の低いテーブル（例：AzureActivity）は30日間に短縮でき、頻繁に使用するテーブル（SigninLogs）は1年間に延長できます。
  • ノイズの多いルールを無効にせず、調整する。 無効にすると検出されなくなります。まずエンティティのマッピング、しきい値、またはスコープを調整します。
  • Auxiliaryログをスケジュール済み分析ルールの実行に使用することはできません。 検出が依存しているテーブルをAuxiliaryに移行しないでください。

よくあるアンチパターン

  • 「分離のためにビジネスユニットごとにワークスペースを作る」 - コストが倍増し、相関分析ができなくなります。代わりにリソースコンテキストの RBAC を使用してください。
  • 「初日から 500 GB/日にコミットする」 - そのティアから 31 日間変更できません。必ず最初に PAYG でベースラインを確認してください。
  • 「必要になるかもしれないので、すべてを取り込む」 - Sentinel の請求額は GB に比例して増加します。テーブルごとのティアの決定が、コストを左右する最大の要因です。
  • 「ノイズの多い検出ルールを無効にした」 - チューニングではなく、カバレッジを削除しています。エンティティごとの除外またはしきい値の調整を使用してください。
  • 「すべての分析ルールを 5 分間隔で実行する」 - クエリユニットを消費し、重複アラートを発生させます。スケジュールは検出ウィンドウに合わせてください（認証攻撃は 5 分、ラテラルムーブメントは 1 時間）。
  • 「すべてのルールにプレイブックを設定する」 - ほとんどのルールで必要なのは対応ではなく、トリアージの自動化です。対応用プレイブックは、信頼度の高い検出に限定してください。

プロンプトの例

  • Entra ID、Defender XDR、Azure firewall 全体で 200 GB/日の場合、Sentinel の月額コストを見積もってください。
  • Sentinel のワークスペースはビジネスユニットごとに分割すべきですか、それともテーブルレベルの RBAC を使用すべきですか？
  • DNS とプロキシのログを Analytics から Auxiliary に移すと、何が機能しなくなりますか？
  • 新しい M365 テナントで、最初に有効にすべきコネクタはどれですか？
  • 不可能な移動を伴うサインインを検出する、ほぼリアルタイムの分析ルールを作成してください。
  • MDE がランサムウェアの動作を検出したときに、デバイスを分離して Teams に通知するプレイブックを作成してください。
  • ワークスペースを監査し、取り込み量が多い上位 10 個のテーブルと、ティアまたは保持期間を下げられるテーブルを教えてください。

Microsoft Learn

コメント

Markdown 対応