「海外からのサインイン成功」——そのアラートを確認したのは発生から3日後でした。その間、攻撃者はM365環境にアクセスし続け、メールボックスの内容を閲覧していました。
サインインログは「取っているだけ」では意味がありません。定期的に確認し、不審なパターンを見つけることが重要です。
この記事では、Microsoft Entra ID(旧Azure AD)のサインインログの種類・見方・不審なサインインの典型パターンと、実務での確認手順を解説します。
サインインログとは——何が記録されているのか
サインインログ(Sign-in Logs) Microsoft Entra IDに対して行われた認証要求の記録。誰が・いつ・どこから・何のアプリに・どのデバイスでアクセスしたか、そして成功・失敗の結果が記録される。不正アクセスの検知・インシデント調査・コンプライアンス対応の基本となるログ。
サインインログに記録される主な情報は以下です。
| フィールド | 内容 |
|---|---|
| ユーザー | サインインを試みたアカウント |
| 日時 | サインインの発生日時(UTC) |
| IPアドレス | アクセス元のIPアドレス |
| 場所 | IPアドレスから推定した国・都市 |
| アプリケーション | アクセス先のアプリ(M365・SharePoint等) |
| デバイス | 使用したデバイス・OS・ブラウザ |
| 状態 | 成功・失敗・中断 |
| 失敗理由 | 失敗した場合のエラーコード |
| 条件付きアクセス | 適用されたポリシーと結果 |
| MFA | MFAの要求・完了状況 |
このログを定期的に確認することで、パスワードスプレー攻撃・フィッシング後の不正ログイン・内部不正の兆候を早期に発見できます。
サインインログの種類——3つのログを使い分ける
Entra IDのサインインログは3種類あります。目的に応じて使い分けます。
| ログの種類 | 内容 | 主な用途 |
|---|---|---|
| 対話型サインインログ | ユーザーがID・パスワード・MFAで直接認証したログ | 不正ログインの検知・ユーザーの行動確認 |
| 非対話型サインインログ | トークンのリフレッシュ・自動更新など人が介在しない認証ログ | サービス間の認証確認 |
| サービスプリンシパルのサインインログ | アプリ・サービスプリンシパルの認証ログ | アプリの不審な動作確認 |
不正アクセス調査で最初に確認すべきは対話型サインインログです。
ログの保存期間
| ライセンス | 保存期間 |
|---|---|
| Entra ID Free | 7日間 |
| Entra ID P1/P2 | 30日間 |
| Log Analytics連携(Sentinel等) | 設定による(90日〜) |
7日・30日ではインシデント調査に足りない場合があります。 Microsoft Sentinelや Log Analyticsにログをエクスポートして長期保存することを推奨します。
参考:Microsoft Learn|Entra ID のサインイン ログ
不審なサインインの典型パターン

パターン① 海外・普段と異なる場所からのサインイン成功
ユーザーが普段日本からしかアクセスしていないにもかかわらず、海外IPからのサインイン成功が記録されている場合は要注意です。
特に「不可能な移動(Impossible Travel)」と呼ばれる、物理的に移動できない短時間での別国からのサインインは侵害の強いシグナルです。
不可能な移動(Impossible Travel) 例えば東京から午前9時にサインインし、同日午前9時30分にニューヨークからサインインするなど、物理的に移動不可能な時間・距離でのサインインパターン。Entra ID P2ではリスク検出として自動フラグが立てられる。
パターン② 多数のサインイン失敗後の成功
短時間に同一アカウントへのサインイン失敗が多数発生した後、成功が記録されているパターンはパスワードスプレー攻撃またはブルートフォース攻撃の疑いがあります。
確認ポイント:
- 失敗の発生時間帯(深夜・休日に集中していないか)
- 失敗のIPアドレス(同一IP or 分散しているか)
- 成功時のIPアドレス(失敗と同じIPか)
パターン③ MFAを完了していないサインイン成功
条件付きアクセスでMFAを要求しているにもかかわらず、MFAが完了していない成功ログが存在する場合は設定の不備または回避の疑いがあります。
レガシー認証プロトコル(SMTP・POP3・IMAP等)はMFAをバイパスできるため、これらのプロトコルが使われていないかを確認します。
レガシー認証(Legacy Authentication) SMTP・POP3・IMAPなどの古い認証プロトコル。MFAに対応していないため、条件付きアクセスでブロックすることが推奨されている。
パターン④ 普段と異なるデバイス・ブラウザからのアクセス
ユーザーが普段Windows・Chromeを使っているにもかかわらず、Linux・curlやPythonライブラリからのアクセスが記録されている場合は自動化ツールによるアクセスの可能性があります。
パターン⑤ 大量のアプリへの短時間アクセス
正常なユーザーは通常数個のアプリにしかアクセスしません。短時間に多数のアプリへのアクセスが記録されている場合は、アクセストークンを悪用した情報収集の疑いがあります。
Entra ID管理センターでの確認手順
基本的な確認手順
- Entra ID管理センター にグローバル管理者またはセキュリティ閲覧者でサインイン
- 「監視と正常性」→「サインイン ログ」を開く
- フィルターを使って絞り込む
効果的なフィルターの使い方
不審なサインインを絞り込む際の主なフィルター
| フィルター | 設定値 | 用途 |
|---|---|---|
| 状態 | 失敗 | 認証失敗の一覧を確認 |
| 場所 | 日本以外 | 海外からのアクセスを確認 |
| ユーザー | 管理者アカウント | 特権アカウントの使用状況確認 |
| 日時 | 深夜・休日 | 業務時間外のアクセスを確認 |
| クライアントアプリ | レガシー認証クライアント | MFAバイパスの確認 |
リスクのあるサインインの確認
Entra ID P2ライセンスがある場合、「リスクの高いサインイン」として自動フラグが立てられます。
「保護」→「リスクの高いサインイン」から確認し、フラグが立っているサインインは優先的に調査してください。
CSVエクスポートで分析する
大量のログを分析する場合はCSVにエクスポートして確認します。
- サインインログ画面で対象期間・フィルターを設定
- 「ダウンロード」→「CSV」を選択
- Excelまたはスクリプトで分析
エクスポートの上限は最大10万件です。期間を絞って取得してください。
よくある失敗パターン4選
① ログを確認する担当者・頻度が決まっていない
「サインインログは取っているが、誰も定期的に確認していない」という状態は多いです。ログは取るだけでは意味がありません。週次または月次でサインインログを確認する担当者と手順を決めて運用に組み込んでください。
② レガシー認証をブロックしていない
条件付きアクセスでMFAを要求しているのに、レガシー認証プロトコルをブロックしていないため、MFAをバイパスしたサインインが成立するケースがあります。条件付きアクセスで「レガシー認証クライアント」からのアクセスをブロックしてください。
③ ログの保存期間が7〜30日のままで調査に使えない
インシデントが発覚したときに「ログが残っていなかった」という事態を防ぐため、SentinelまたはLog Analyticsへのログエクスポートを設定し、最低90日分のログを保持してください。
④ 管理者アカウントのサインインを別途確認していない
一般ユーザーのサインインに紛れて管理者アカウントのサインインが見落とされるケースがあります。管理者アカウントは「ユーザー」フィルターで絞り込み、一般ユーザーとは別に確認する運用を作ってください。
定期確認チェックリスト
週次確認
- [ ] 管理者アカウントのサインインログを確認した
- [ ] リスクフラグが立っているサインインを確認した(Entra ID P2の場合)
- [ ] 海外IPからのサインイン成功を確認した
月次確認
- [ ] レガシー認証クライアントからのサインインがないか確認した
- [ ] MFAが完了していないサインイン成功がないか確認した
- [ ] 多数のサインイン失敗が発生しているアカウントがないか確認した
- [ ] 普段と異なるデバイス・場所からのアクセスがないか確認した
環境設定の確認
- [ ] ログの保存期間を確認した(90日以上推奨)
- [ ] SentinelまたはLog Analyticsへのエクスポートを設定している
- [ ] レガシー認証をブロックする条件付きアクセスポリシーが有効になっている
- [ ] 管理者アカウントへのMFA強制ポリシーが有効になっているまとめ
今日確認すべきことは1つです。
Entra ID管理センターのサインインログを開いて、直近7日間に海外IPからのサインイン成功がないか確認してください。
「場所」フィルターで日本以外を選択し、状態が「成功」のログが存在する場合は該当ユーザーに確認を取り、必要であればアカウントの一時無効化・パスワードリセット・MFA再登録を実施してください。
サインインログの定期確認は、不正アクセスを「起きてから気づく」から「早期に気づく」に変える最初のステップです。まず週次で管理者アカウントのログを確認する運用から始めてください。
あわせてご覧ください


コメント