異常サインイン検知からMicrosoft Sentinelアラート起票までを完全自動化する方法

2026.03.10

情報システム部門の皆様、日々のMicrosoft 365運用、お疲れ様です。 ログインに関する通知やログの確認、増加していませんか？ 「不審なサインイン」を発見した際の初動対応は、時間との勝負であり、大きな負担となりがちです。

この記事では、異常なサインインの兆候を検知した瞬間、人が介在する前に「自動で」防御と検知を行う仕組みを、ゼロから構築します。

この記事のゴール

本記事の最終的な目標は、以下の状態を実現することです。 「異常なサインインを検知したら、自動的にMFAを要求し、即座にMicrosoft Sentinelでアラートを上げる」

構築するフローは以下の通りです。

  1. 攻撃者（または検証者）が、異常なサインイン（例：海外IPからのアクセス）を試みる。
  2. Microsoft Entra IDがリスクを検知し、条件付きアクセス（CA）が自動的にMFAを要求して防御する。
  3. そのサインインログ（SigninLogs）が、リアルタイムでMicrosoft Sentinelに集約される。
  4. SentinelのNRT（準リアルタイム）分析ルールがログを即時分析し、アラート化する。
  5. 運用者は、Sentinelの「インシデント」画面を見るだけで状況を把握できる。

1. 背景と解決策

現状の課題（Before）

多くの運用現場では、以下のような手動対応が行われています。

  • 管理者がEntra管理センターを開き、怪しいサインインログを目視で確認する。
  • IPアドレスや場所を調査し、必要に応じてユーザーへの連絡やアカウントの一時停止を行う。
  • 対応結果をチャットやチケット管理システムに手動で記録する。

この運用には、「担当者が通知に気づくまで動けない（初動の遅れ）」、「調査スキルが属人化しやすい」という大きな問題があります。

3．解決策（After）

そこで今回は、Microsoft Entra ID（入口の防御） と Microsoft Sentinel（監視・分析の頭脳） を連携させ、初動の負荷を下げ、見逃しをゼロにする構成を構築します。

解決策の全体像：

  • 防御 (Entra ID): 条件付きアクセスを使い、「リスクの高いサインイン」と判断された場合のみ、動的にMFAを要求します。
  • 集約 (Sentinel): Entra IDのサインインログをSentinelに取り込みます。
  • 検知 (Sentinel): SentinelのNRTルールで「リスクによってMFAが強制されたログ」を即座に検知し、インシデントとして起票します。

解決策の全体像：

防御 (Entra ID): 条件付きアクセスを使い、「リスクの高いサインイン」と判断された場合のみ、動的にMFAを要求します。

集約 (Sentinel): Entra IDのサインインログをSentinelに取り込みます。検知 (Sentinel): SentinelのNRTルールで「リスクによってMFAが強制されたログ」を即座に検知し、インシデントとして起票します。

目次

1．基礎知識

本記事では、Microsoft Entra ID と Microsoft Sentinel を利用して
異常ログインの検知と対応を行う構成を構築します。

その前提として、使用するセキュリティ用語を整理します。

MFAとは

MFA（Multi-Factor Authentication） とは、
複数の認証要素を組み合わせてログインを行う仕組みです。

通常のログインは
「ID＋パスワード」のみですが、
MFAでは追加の認証が必要になります。

例：

  • スマホ通知
  • ワンタイムコード
  • 指紋認証

条件付きアクセスとは

ログイン条件によってアクセス制御する機能です。

例：

  • 海外IP → MFA
  • リスク高 → ブロック

Sentinelとは

Microsoft Sentinel は
クラウド型 SIEM です。

役割：

  • ログ収集
  • 分析
  • アラート生成
  • インシデント管理

2．事前準備

構築を始める前に、必要な環境とライセンスを確認します。

2-1. 前提知識とライセンス

項目

説明

必須ライセンス

MFA (多要素認証)

パスワードに加え、スマホアプリ通知などで本人確認を行う仕組み。

(基本機能に含まれる)

条件付きアクセス (CA)

「海外からのアクセスならMFAを要求」のように、条件に応じてアクセス制御を行う機能。

Entra ID P1 以上

Identity Protection

「普段と異なる場所からのアクセス」「漏洩した資格情報」などのリスクを検知する機能。今回の肝です。

Entra ID P2 以上

Microsoft Sentinel

ログを収集・分析し、脅威を検知するクラウド型SIEM。

Azure サブスクリプション (従量課金)

※今回の構成では、リスクベースの条件付きアクセスを利用するため、Microsoft Entra ID P2 ライセンスが必須となります。

2-2. 検証用ユーザーの作成とライセンス付与

本番環境への影響を避けるため、検証用ユーザーでテストを行います。

  1. Microsoft Entra 管理センター を開きます。
  2. 左メニューの「ユーザー」>「すべてのユーザー」から「新しいユーザー」>「ユーザーの作成」をクリックします。
  3. 検証用ユーザーを作成します（例: test-risk-user01）。
  4. 作成したユーザーのプロファイルを開き、「ライセンス」メニューから「Microsoft Entra ID P2」を含むライセンスを割り当てます。

2-3. 検証用ユーザーでのMFA登録（必須）

条件付きアクセスでMFAを要求した際、ユーザーがMFA未登録だとサインインがブロックされてしまいます。必ず先に登録を済ませます。

  1. 作成した検証用ユーザーで My Account (https://myaccount.microsoft.com) などにログインします。
  2. 「詳細情報が必要」という画面が表示されたら、「次へ」進みます。
  3. 画面の指示に従い、スマートフォンの「Microsoft Authenticator」アプリなどを連携させてMFA登録を完了させます。

2-4. 検証用グループの作成

条件付きアクセスは、設定を誤ると管理者自身も締め出されるリスクがあります。安全のため、ポリシーは必ず「グループ」に対して適用します。

  1. Entra 管理センターで「グループ」>「すべてのグループ」>「新しいグループ」をクリックします。
  2. セキュリティグループを作成します（例: CA-Test-Group-RiskMFA）。
  3. 作成したグループの「メンバー」に、先ほど作成した検証用ユーザーを追加します。

3．具体的な手順

1．「セキュリティ」をクリックします。

2．「条件付きアクセス」をクリックします。

3．「ポリシー」をクリックし、「+ 新しいポリシー」をクリックします。

4．「ユーザーとグループの選択」をクリックします。

5．「ユーザーとグループ」をクリックします。

6．「対象のグループ」をクリックします。

7．「すべてのリソース (以前の ‘すべてのクラウド アプリ’)」をクリックします。

8．「0 個の条件が選択されました」をクリックします。

9．「はい」を選択し、「高」と「中」にチェックを入れ、「完了」をクリックします。

10．「アクセス権の付与」を選択し、「多要素認証を要求する」にチェックを入れて「選択」をクリックします。

11．「作成」をクリックします。

12．「ポリシー」をクリックし、「新しいポリシー」をクリックします。

13．「CA-Test-IdentityProtection」をクリックし、「選択」をクリックします。

14．「はい」をクリックし、「高」にチェックを入れ、「完了」をクリックします。

15．「アクセスのブロック」をクリックします。

16．「レポート専用」をクリックし、「作成」をクリックします。

17．「Microsoft Sentinel」、「構成」、「分析」の順にクリックします。

18．「+ 作成」をクリックし、「NRT クエリ ルール」をクリックします。

19．「名前」と「説明」を入力し、「重大度」と「MITRE ATT&CK」を選択したら、「次へ: ルールのロジックを設定 >」をクリックします。

20．「ルールのクエリ」に、指定のクエリを入力します。

クエリ

let HomeCountries = dynamic([‘JP’]);

SigninLogs

| where isnotempty(IPAddress)

| extend Country = tostring(LocationDetails.countryOrRegion)

| where Country !in (HomeCountries)

| extend IngestTime = ingestion_time()

| summarize

    Count = count()

  by bin(IngestTime, 1m), UserPrincipalName, Country

| where Count >= 2

保存。

21．「Name」と「UserPrincipalName」に値を入力します。

22．「Address」と「UserPrincipalName」をクリックします。

23．「次へ: インシデントの設定」をクリックします。

24．「次へ: 自動応答 >」をクリックします。

25．「次へ: 確認と作成」をクリックします。

26．「保存」をクリックします。

これで設定が完成しました！

4. 動作検証

実際に異常なサインインを発生させて、仕組みが動くか確認します。

検証シナリオ: 日本にいるはずのユーザーが、VPNを使って海外のIPアドレスからサインインを試みる。

  1. 準備: 手順1で作成したCAポリシーを「レポート専用」から「オン」に変更し、保存します。
  2. 攻撃実行:
    • PCまたはスマホでVPNアプリを使い、接続先を「アメリカ」などに設定します。
    • ブラウザのシークレットモードを開き、検証用ユーザーで Microsoft 365 ポータルなどにアクセスします。
  3. 防御の確認 (Entra ID):
    • IDとパスワードを入力した後、MFA（Authenticator通知など）が求められることを確認します。

※Entra IDがリスクを検知するまで数分かかる場合があります。MFAが出ない場合は、一度ログアウトして時間を空け、再度試してください。

また条件付きアクセスをMFA強制ではなく危険なサインインのブロックにするとVPNにつないでサインインすると以下のようにアカウントがブロックされます。

  1. 検知の確認 (Sentinel):

・数分後（NRTルールは通常1分間隔で実行されます）、Microsoft Sentinel の「調査と対応」>「アラート」を開きます。

・先ほど作成したルール名で新しいインシデントが作成されていれば成功です！

・以下のようにログイン時のアラートの詳細が表示されます。

また、条件付きアクセスの評価結果では、以下のポリシーが適用されていることが確認できます。

・Sign-in risk (Medium) + MFA 要求ポリシー

この結果から、Microsoft Entra ID のリスクベース条件付きアクセスにより、不審なサインインが適切に検知・ブロックされていることが確認できました。

4．まとめ

本記事では、Microsoft Entra ID と Microsoft Sentinel を組み合わせ、異常なサインインが発生した瞬間からアラート生成までを自動化する構成を構築しました。

なぜこの構成が優れているのか

今回の構成は、セキュリティ対応における「検知」「防御」「記録」「通知」という一連の流れを、人の手を介さずに自動化した点に価値があります。

  • インシデント初動の劇的な高速化: 従来は「担当者が通知に気づいてから調査開始」でしたが、この構成では「担当者が画面を見た時点で、すでに防御が完了し、調査用データが揃ったインシデントが起票されている」状態になります。
  • 属人化の排除と標準化: 「怪しいログ」という曖昧な状態ではなく、Sentinel上の「管理されたインシデント」として扱われるため、誰が対応しても一定の品質を保てます。調査履歴もシステムに残ります。
  • 運用担当者は「判断」に集中できる: ログの収集やIPアドレスの確認といった単純作業は機械に任せ、人間は「このアクセスは本当に問題ないか？」「追加の対策が必要か？」といった高度な判断にリソースを集中できます。

今後の拡張性

今回構築したのは「最小構成」の自動化です。ここからさらに発展させることができます。

  • 通知の自動化: Sentinelのオートメーション機能（Logic Apps）を使い、インシデント発生時にTeamsのセキュリティ担当者チャネルに即時通知を飛ばす。
  • 対応の自動化: 「リスクレベルが『高』の場合は、MFA要求ではなくアカウントを自動的に無効化する」といった、より強力な防御ポリシーを検討する。