mcpField
A
azure-monitor-security

azure-monitor-security

github.com/vinayaklattheセキュリティ17843 回インストール19 週間前に更新
リポジトリ

azure-monitor-security について

Microsoft Sentinel とセキュリティテレメトリを支える Log Analytics ワークスペースの設計・見直しを支援するスキルです。テーブル階層、保持期間、DCR、アクセス制御、コストを扱います。

主な機能

  1. 01ワークスペース構成の計画
  2. 02テーブル階層の選択
  3. 03DCRと取り込み変換の設計
  4. 04保持とアーカイブの設定
  5. 05コストとRBACの管理

活用シーン

  1. 01Sentinelワークスペース戦略の策定
  2. 02MMAからAMAへの移行
  3. 03セキュリティログ取り込み費用の削減
  4. 04テーブル単位のアクセス権設定

インストール

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

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

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

詳細

セキュリティ向け Azure Monitor と Log Analytics

Microsoft Sentinel は Log Analytics ワークスペース上で稼働します。Defender for Cloud、Defender XDR のハンティングテーブル、アクティビティログ、診断設定からのデータも、そこに流れ込みます。ワークスペース戦略によって、セキュリティテレメトリを 完全で、コンプライアンスに準拠し、手頃なコストにできる のか、それともそのうち2つだけになるのかが決まります。

このスキルでは、ワークスペース設計におけるセキュリティ関連の判断、つまりティア、保持期間、DCR、RBAC、コストを扱います。

使用する場面

Sentinel と、より広範なセキュリティテレメトリ環境を支える Log Analytics ワークスペースの設計または再構成を行う場合に使用します。

次の用途にはこのスキルを使用しないでください。Sentinel の検出ルール作成 （sentinel-detection-engineering）、App Insights の計測 （appinsights-instrumentation）、またはセキュリティ以外のオブザーバビリティ。

ログテーブルのティア — テーブルごとに選択

ティアクエリのレイテンシ保持期間の上限ユースケース
Analytics1秒未満対話型で730日検出、ハンティング、ダッシュボード
Basic数秒（制限付きの KQL）対話型で30日＋アーカイブ大量の「必要に応じて検索する」ログ
Auxiliary遅い／非同期対話型で12か月アクセス頻度の低いコンプライアンス用アーカイブフィード
Archive（すべてのティア）検索ジョブによる再取得最長12年長期保管が必要な証拠、規制上の保留

Microsoft はこれらの名称や仕組みを変更しているため、コミットする前に、お使いのリージョンでの最新の名称と料金を確認してください。

アプローチ

  1. ワークスペースの構成。

    • デフォルト：セキュリティシグナルごとにテナントあたり 1 つの Sentinel ワークスペースを使用します。これにより、相関分析が容易になります。
    • リージョン別／主権要件対応：データ所在地または主権要件で必要な場合は、ワークスペースを分けます。
    • 複数ワークスペースの Sentinel：ビジネス上の理由（M&A の境界、MSSP モデル）で必要な場合に限ります。ワークスペース間のクエリは可能ですが、複雑さが増します。
    • チームごとに分割しないでください。相関分析が分断されます。

  2. 新規導入ではすべてに Azure Monitor Agent（AMA）を使用します。 Microsoft Monitoring Agent（MMA／Log Analytics エージェント）は廃止されています。Defender for Cloud の自動プロビジョニングと Sentinel ソリューションを利用した移行パスがあります。

  3. データクラスごとに DCR を定義します。

    • データソースのファミリーごとに 1 つの DCR を使用します（Windows セキュリティイベント、Linux Syslog、カスタムログなど）。
    • transformKql を使って、取り込み時にノイズの多い列やイベント ID 全体を除外します。取り込み前に 30% 削減すれば、取り込み後のチューニングより効果的です。
    • 変換を検出用の KQL に照らして検証してください。Sentinel の分析ルールが依存する列を削除しないでください。

  4. テーブルごとにティアを選択します。

    • Analytics：SecurityEvent（フィルター適用済み）、SigninLogs、AuditLogs、DeviceLogonEvents（Defender XDR）、Sentinel 主導の検出ソース。
    • Basic：AzureDiagnostics（ログ量の多いリソース向け）、NSG フローログ、Web サーバーのアクセスログ（インシデント検索にのみ必要な場合）。
    • Auxiliary：長期保存が必要なコンプライアンス用フィード（例：未加工のファイアウォールログを 12 か月間保存）。 ティアの選択によって、取り込みコストと保持コストが大きく変わります。

  5. 保持とアーカイブ。

    • インタラクティブ保持期間：デフォルトは 90 日です。検出のルックバック期間に合わせて延長します（多くの場合 180～730 日）。
    • コンプライアンスと IR の再生用にアーカイブ（コールド）を利用します（一部のシナリオでは最大 12 年）。
    • 必要に応じて、検索ジョブでアーカイブデータを再取得します。

  6. コスト管理。

    • ワークスペースのコミットメントティア（100 GB／日～5,000 GB／日）により、GB あたりの料金を約 15～30% 削減できます。
    • 主なデータソース（DNS、NSG フロー、Linux Syslog）を特定して上限を設定します。通常、コストの 80% を占めます。
    • 日次上限をガードレールとして設定します（上限を超えたデータは破棄されます。上限に達したらアラートを出します）。
    • 毎月、上位のテーブル、リソース、取り込み傾向を確認します。

  7. データ分類要件に応じて、ワークスペースに**カスタマー マネージド キー（CMK）**を設定します。専用クラスターが必要であることと、運用が複雑になることを考慮して計画してください。

  8. RBAC。

    • ワークスペースレベル：Log Analytics Reader、Log Analytics Contributor。
    • テーブルレベルの RBAC：アナリストのアクセスを特定のテーブルに限定します（例：HR のメールボックス監査ログは内部脅威対策チームのみが閲覧可能）。
    • Sentinel：Sentinel Reader／Responder／Contributor の各ロールを分けます。
    • SOC アナリストにワークスペースの Owner を割り当てないでください。

  9. ワークスペース間およびテナント間。

    • MSSP 型のマルチテナント環境には、Sentinel ワークスペース マネージャー（リージョンごとにプレビューまたは GA）を使用します。
    • 統合された環境では、union を使ったワークスペース間クエリを使用します。

ガードレール

  • デフォルトの 90 日間の保持期間では、セキュリティ調査に不十分な場合がほとんどです。 APT の潜伏期間の中央値はこれを超えます。主要な検出ソースは 180～730 日間保持する計画を立ててください。
  • 安全のためにすべてを Analytics ティアに取り込まないでください。 コストが急増します。「保存して必要な場合のみ検索」するデータには Basic を追加してください。
  • 変換は強力ですが危険です。 今日の列削除が明日の検出を壊す可能性があります。DCR をソース管理し、変更をレビューしてください。
  • コスト管理のための日次上限は、セキュリティデータを含むデータを破棄します。 アラートと併用し、セキュリティテーブルの上限を過去の最大値より低く設定しないでください。
  • 2025 年以降に MMA をデプロイしないでください。 AMA を使用してください。既存の MMA ワークロードには移行計画が必要です。
  • ワークスペースで CMK を使うには、専用クラスターと 500 GB／日以上のコミットメントが必要です。 運用とコストの負担が大きくなります。
  • 複数ワークスペースの Sentinel では、ハンティングが難しくなります。 チームの好みではなく、ビジネス上の理由に基づいて正当化してください。
  • アーカイブのデータ再取得には検索ジョブを使い、ネイティブクエリは使いません。 IR の SLA に関する想定が変わります。
  • 診断設定はリソースごとに行います。大規模に適用するにはサブスクリプション単位のポリシーを使用します。 Azure Policy で適用してください。

よくあるアンチパターン

  • 「各チームが『自分たちのデータ』を求めるため、チームごとにワークスペースを用意する」 — 相関分析ができなくなり、 コストが膨らみます。
  • 「すべてを Analytics ティアにする」 — リアクティブにクエリするテーブルでは、Basic と比べてコストが 5 倍になります。
  • 「NSG フローログを完全な精度で Sentinel に永久保存する」 — 最大のコスト要因です。サンプリング、変換、または Basic ティアを使用します。
  • 「コストを抑えるために保持期間を 30 日にする」 — 6 週目に発見されたインシデントのデータがありません。
  • 「通常のデータ量を下回る日次上限を設定する」 — 気付かないままデータが失われ、検出を見逃します。
  • 「50 個のサブスクリプションにわたる DCR をポータルで手作業で編集する」 — 構成の不整合が発生し、監査もできません。Bicep + Azure Policy を使用します。
  • 「Sentinel と Defender XDR を別々の 2 つのワークスペースに配置する」 — 複数製品をまたいだハンティングが困難になります。統合します。
  • 「データ量の根拠もなく CMK のために専用クラスターにアップグレードする」 — 予期せぬコストが発生します。

プロンプトの例

  • EU と APAC のデータ主権に関する制約がある、従業員 100,000 人規模のマルチリージョン Sentinel 展開向けに、Log Analytics ワークスペース戦略を設計してください。
  • Defender for Cloud の自動プロビジョニングを使用して、6,000 台のサーバーを MMA から AMA に移行し、切り替え中の検出カバレッジの不足を特定してください。
  • SecurityEvent と Syslog からノイズの多い列を除外し、取り込み量を 35% 削減する想定の DCR を作成してください。
  • Sentinel + DfC のワークロードについて、保持期間も含め、どのテーブルを Analytics、Basic、Auxiliary にするか、ティア計画を作成してください。
  • コストを最適化するため、1 日あたり 12 TB のワークスペースにおけるコスト要因の上位 10 項目を特定し、対象を絞った削減策を提案してください。
  • テーブルレベルの RBAC を構成し、内部不正リスクのアナリストが EmailEvents を参照できる一方、DeviceProcessEvents は参照できないようにしてください。
  • セキュリティ ワークスペースに対するカスタマー マネージド キーの展開 — 専用クラスター、キーのローテーション、復旧手順書。
  • 予算を保護しながら、検出に不可欠なテーブルのデータを破棄しない日次上限と取り込みアラートの戦略を設定してください。

Microsoft Learn

コメント

Markdown 対応