Microsoft Entra ID Protection

解決する課題

• パスワードが漏れても正規ユーザーのサインインと見分けがつかず、侵害に気づけない
• 不正アクセスの兆候（見慣れない地域・匿名 IP・マルウェア感染端末からのサインイン）を人手で監視しきれない
• 全員に常時 MFA を課すと負担が大きい → リスクが高いときだけ追加認証やパスワード変更を求めたい
• 漏えい済みの資格情報やパスワードスプレー攻撃を、サインインの瞬間にブロックしたい
• 検知したリスクを SIEM や SOAR に流し、調査・対応のワークフローに乗せたい

主要概念と用語

ID Protection は「リスクの検知」と「リスクへの対応（自動修復）」を担う機能群です。

• リスク（Risk）: アカウントが侵害されている確からしさ。サインインリスク（その 1 回のサインインが不正である可能性）とユーザーリスク（アカウント自体が侵害されている可能性）の 2 種類がある
• リスク検知（Risk Detection）: 個々の異常シグナル。匿名 IP アドレス、見慣れない場所、不可能な移動、漏えい資格情報、パスワードスプレーなどが該当する
• リスクレベル: 各検知やユーザー/サインインに付く深刻度。低・中・高に区分され、ポリシーの発動条件に使う
• リアルタイム検知とオフライン検知: サインイン時に即時評価されるものと、後からバックエンドで相関分析して判定されるものがある
• リスクベースのポリシー: リスクレベルに応じて対応を強制する仕組み。サインインリスクポリシー（MFA を要求）とユーザーリスクポリシー（セキュアなパスワード変更を要求）がある
• 自動修復（Self-remediation）: 利用者自身が MFA 完了やパスワード変更を行うとリスクが解消され、管理者の手を介さずアカウントが回復する
• リスクの状態: 各リスクには「危険（At risk）」「修復済み」「却下（Dismissed）」「侵害を確認」などの状態があり、調査の起点になる

仕様・制限・クォータ

• Microsoft Entra ID P2 ライセンスが前提。下位の P1 や Free でも一部のリスク検知は動くが、リスクの詳細表示・リスクベースの条件付きアクセス・自動修復・リスク API といった中核機能は P2 で開放される
• グローバルサービス（テナント単位で動作し、特定リージョンに縛られない）
• リスク検知は Microsoft の脅威インテリジェンスと機械学習で生成され、利用者が検知エンジンを保守する必要はない
• リスクベースのポリシーは、独立した従来型ポリシーよりも条件付きアクセスに統合する方法が推奨される（場所・デバイス等の条件と組み合わせやすいため）
• 検知やリスクイベントは Microsoft Graph のリスク API で取得・操作でき、Sentinel や外部 SIEM への連携に使える
• リスクデータの保持期間や個々の検知種別は更新されることがあるため、最新の対応範囲は公式ドキュメントを参照する

内部の仕組み

ID Protection は、サインインごとに集めたシグナルを Microsoft 側で解析し、リスクスコアに変換します。

リアルタイム検知は、サインインの瞬間に IP 評価・位置・デバイス・行動パターンなどを評価し、条件付きアクセスの判定に間に合うタイミングでリスクレベルを返します。オフライン検知は、サインイン後にバックエンドで相関分析し、漏えい資格情報の照合（流出した認証情報データベースとの突き合わせ）や、複数サインインをまたいだ異常（不可能な移動など）を後追いで判定します。

リスクは個々の検知を集約して「サインインリスク」と「ユーザーリスク」に整理され、リスクベースのポリシー（または条件付きアクセス）の評価に渡されます。利用者が MFA を完了したり安全なパスワードに変更したりすると、対応するリスクは自動的に修復済みへ遷移します。管理者は侵害確認・却下などの操作で、機械学習モデルへのフィードバックも与えられます。

• 認証そのものは Entra ID（OAuth 2.0 / OpenID Connect） が担い、ID Protection はその上でリスク評価層として働く
• 強制の実体は条件付きアクセスで、「リスクが高ければ MFA」「ユーザーリスクが高ければパスワード変更」といった制御を適用する
• 検知・リスクイベントは Microsoft Graph のリスク API や Microsoft Sentinel へ連携し、相関分析・自動対応につなげられる

設計パターン / ベストプラクティス

• 条件付きアクセスでリスクポリシーを実装する。サインインリスクが中以上なら MFA、ユーザーリスクが高なら安全なパスワード変更を必須にする
• 段階的にロールアウトする。まずレポート専用モードで影響範囲を確認し、対象グループを限定してから全体へ広げる
• 緊急アクセスアカウント（Break-glass）は除外する。リスクポリシーで自分自身を締め出さないよう、非常用の管理者は対象から外す
• フィッシング耐性のある MFA（パスキー / FIDO2）を優先し、リスク時の本人確認の強度を上げる
• 管理者ロールには特に厳しいリスクしきい値を設定し、特権アカウントの侵害兆候を早く止める
• 自動修復を活かす。利用者が自分で MFA / パスワード変更してリスクを解消できる導線を整え、運用負荷を下げる

運用・監視

• リスクレポート（リスクのあるユーザー、リスクのあるサインイン、リスク検知）を定期レビューし、傾向と多発元を把握する
• 高リスクユーザーは優先調査する。侵害確認・却下の操作でリスク状態を正しく更新し、モデルへのフィードバックにする
• Microsoft Sentinel / Log Analytics へエクスポートし、長期保管と他ログとの相関分析を行う
• Graph のリスク API で自動化する。高リスク検知をトリガーにチケット起票やセッション失効などの対応を回す
• 誤検知の扱いを決めておく。正規利用（出張・VPN 等）で出るリスクの却下基準を運用ルール化し、ノイズを抑える
• ポリシー変更の影響を継続監視し、ユーザーのロックアウトやサポート問い合わせの増加を早期に検知する

コスト

ID Protection の中核機能は Microsoft Entra ID P2 ライセンスに含まれます。保護対象ユーザー単位の月額ライセンスで、検知量やイベント数による従量課金ではありません。具体的な単価はプランや契約形態で変動するため、最新の料金は公式を参照してください。

セキュリティ

• 最小権限: ID Protection の閲覧・調査・ポリシー変更を RBAC（セキュリティ閲覧者 / セキュリティ管理者など）で分離する
• 多層防御の一部: リスク検知（ID 脅威の検知）を、MFA・条件付きアクセス・PIM などの予防的制御と組み合わせる
• 特権アカウントの優遇監視: 管理者ロールは低めのしきい値で保護し、侵害兆候を早く捉える
• 自動修復で侵害を封じ込め: 高ユーザーリスクで安全なパスワード変更を強制し、漏えい資格情報の有効化を断つ
• 証跡の保全: リスクイベントを Sentinel / Log Analytics に保持し、インシデント調査の根拠を残す

関連サービス・比較

ID Protection は単独で動くより、条件付きアクセスと組み合わせてリスクを実際の制御に変換します。両者の役割分担は明確に分かれます。

ハンズオン / CLI例

ID Protection のリスク情報は主に Microsoft Graph 経由で扱います。az rest で Graph のリスク API を呼ぶ例を示します。

# サインインして対象テナントを確認
az login
az account show --query tenantId -o tsv

# リスクのあるユーザー一覧を取得（Graph: identityProtection/riskyUsers）
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/identityProtection/riskyUsers" \
  --headers "Content-Type=application/json" -o json

# 高リスクのユーザーだけに絞り込む（リスクレベルでフィルタ）
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?\$filter=riskLevel eq 'high'" \
  -o json

# 直近のリスク検知を取得（Graph: identityProtection/riskDetections）
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/identityProtection/riskDetections" \
  -o json

# 調査の結果、安全だったユーザーのリスクを却下する（dismiss）
az rest --method post \
  --url "https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/dismiss" \
  --headers "Content-Type=application/json" \
  --body '{"userIds":["<user-object-id>"]}'