mcpField
E
entra-id-protection

entra-id-protection

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

entra-id-protection について

セキュリティチーム向けの Microsoft Entra ID Protection リスク対策スキルです。サインインリスクとユーザーリスクへの対応、調査、Sentinel へのシグナル送信を扱い、リスク検出を条件付きアクセスや SOC の運用につなげます。

主な機能

  1. 01リスクベースの条件付きアクセス計画
  2. 02リスクしきい値と対応策の設定
  3. 03リスクのあるユーザーとサインインの調査
  4. 04リスクイベントの Sentinel への送信

活用シーン

  1. 01高リスクのサインインに MFA を要求
  2. 02高リスクユーザーに安全なパスワード変更を要求
  3. 03リスクユーザーの調査と対処
  4. 04リスクイベントを Sentinel の SOC 分析に取り込む

インストール

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

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-id-protection

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

詳細

Microsoft Entra ID Protection

Microsoft Entra ID Protection は、Microsoft の脅威インテリジェンスと ML を使用して ID リスク（ユーザーリスクとサインインリスク）を検出し、修復を自動化するとともに、調査が必要なリスクの高いユーザーとサインインのキューを表示します。リスクポリシーを有効にするには Entra ID P2 が必要です。

使用する場面

Entra ID と Conditional Access に、リスクベースのアダプティブ保護を追加する場合に使用します。このスキルを使って、リスクのしきい値を選び、自己修復と SOC による調査のどちらにするかを決定し、シグナルを Sentinel に送信します。

このスキルは使用しないでください。オンプレミス AD の攻撃検出（defender-for-identity）、基本的な CA ポリシーの作成（conditional-access-mfa）、または PIM のアクティブ化（azure-pim）には使用しません。

リスクシグナルを対応に結び付ける

リスクの種類例推奨される対応
サインインリスク（このリクエスト）匿名 IP、通常とは異なる移動、マルウェアに関連する IP、不慣れなサインインプロパティリスクベースの CA → MFA を要求
ユーザーリスク（この ID）漏えいした資格情報（TI フィード）、Microsoft／パートナーから報告された侵害リスクベースの CA → 安全なパスワード変更を要求
同じユーザーで両方が中以上アクティブなセッション乗っ取りの兆候ブロック + 安全なパスワード変更の強制 + アナリストによるレビュー

経験則： リスクポリシーはしきい値を 高 にして開始し、30 日間運用した後、ユーザー登録と修復フローが機能することを確認してから 中 に拡大します。SSPR + MFA の登録なしで「中」から始めると、ロックアウトが発生します。

アプローチ

  1. 前提条件を確認する — Entra ID P2 ライセンスがあり、対象ユーザースコープで MFA + SSPR の登録が必須になっていることを確認します（Authentication methods の登録ポリシー）。 確認方法：Authentication methods activity レポートで、対象ユーザーの 95% 超が少なくとも 1 つの強力な方法に登録済みであることを確認します。

  2. 従来の組み込みリスクポリシーではなく、リスクベースの Conditional Access を使用する — Sign-in risk と User risk の条件を含む CA ポリシーを作成します。従来の「User risk policy」／「Sign-in risk policy」の切り替え設定は非推奨となり、CA に置き換えられています。 確認方法：従来のリスクポリシーが有効になっていないこと、また CA の What-If 結果にリスク条件が表示されることを確認します。

  3. Tier 1 - 高リスクのみ — 最初のポリシーセットでは、高リスクのサインインリスクに MFA を要求し、高リスクのユーザーリスクに安全なパスワード変更を要求します。すべてのリスクポリシーから緊急用アカウントを除外します。 確認方法：レポート専用モードで 14 日間運用し、適用前にサインイン 1,000 件あたりの誤検知が 5 件未満であることを確認します。

  4. Tier 2 - 中リスクへの拡大 — Tier 1 のメトリックに問題がない状態が 30 日続いたら、中リスクのサインインリスクにも MFA を要求するよう拡大します。アナリストによるレビューキューなしで、ユーザーリスクのしきい値を中に拡大しないでください。

  5. キューを調査する — Risky users、Risky sign-ins、Risk detections を毎日トリアージします。侵害を確認する（修復が強制され、モデルの学習にも役立ちます）か、誤検知を却下します。レビューなしで一括却下しないでください。却下すると、モデルに誤ったシグナルを学習させます。 確認方法：テナントの状態が良好な場合、週ごとのリスクユーザーキューが月間アクティブユーザーの 1% 未満であることを確認します。

  6. Sentinel に送信する — 診断設定で RiskyUsers、UserRiskEvents、RiskyServicePrincipals を Log Analytics ワークスペースに送信します。Defender XDR のインシデントで MDI および MDE と相関付けます。

ガードレール

  • すべてのリスクポリシーから緊急用アカウントを除外します。 誤ったアカウントに対する資格情報漏えいの検出によって、テナントから締め出されるおそれがあります。
  • まず MFA + SSPR を登録します。 ユーザーが完了できる場合にのみ、自己修復が機能します。登録がなければ、リスクポリシーによってロックアウトが発生します。
  • 「高」から開始し、「中」に拡大します。 調整せずに「中」のしきい値を使うと、ノイズやユーザーの負担が増えます。
  • 誤検知を一括却下しないでください。 却下は「これは安全だった」という意味で、モデルの学習に使われます。キューを整理するためではなく、意図をもって「安全を確認」／「侵害を確認」を使用します。
  • ワークロード ID のリスクは別扱いです。 サービスプリンシパルには独自のリスク検出があるため、別途ポリシーを適用します。

よくあるアンチパターン

  • 「従来のユーザーリスク／サインインリスクのポリシー切り替えを使う」 - 非推奨です。より幅広い制御と除外をサポートする CA のリスク条件を使用してください。
  • 「初日からすべてのユーザーを対象に、中リスクでリスクポリシーを適用する」 - ロックアウトにつながります。まず高リスクでパイロット運用してください。
  • 「ノイズを減らすため、リスクのあるユーザーのキューを毎週一括で却下する」 - 検出器に誤った学習をさせ、今後の精度を損ないます。
  • 「リスクイベントを Entra ポータル内にとどめる」 - SOC による相関分析ができません。Sentinel と Defender XDR にストリーミングしてください。

プロンプトの例

  • Entra ID Protection でサインインリスクとユーザーリスクに対するリスクベースの Conditional Access を構成してください。
  • 自己修復を設定してください。サインインリスクには MFA、ユーザーリスクには安全なパスワード変更を適用します。
  • リスクがあるとフラグ付けされたユーザーを調査し、侵害を確認するか、安全に却下してください。
  • SOC による相関分析のため、Entra ID Protection のリスクイベントを Sentinel にストリーミングしてください。
  • 中リスクのアラートが多すぎるのはなぜですか。調整するにはどうすればよいですか。

Microsoft Learn

コメント

Markdown 対応