はじめに
２年前のアドベント カレンダーで Entra ID のサインイン ログからパスワード漏えいを検知する方法について共有しました。
その後、Entra ID のサインイン ログは進化しており、AI エージェントによるサインインかどうかを識別する Agent フィールドや、グローバル セキュア アクセスからのサインインかどうかを識別する IsThroughGlobalSecureAccess フィールドが追加されるなど、気づいたらサインイン ログにも色々と情報が増えてきました。
しかし、たとえ取得できる情報が多くなっても、サインイン ログから脅威を検知したり分析したりする方法は今も大きく変わっていません。
今回は Entra ID サインイン ログを分析するにあたり勘違いしやすいポイントを解説したいと思いますので、ぜひ調査などにお役立てください。（ちょっと細かすぎる内容になったかも・・）
Entra ID サインイン ログの取得方法
Microsoft Sentinel を使っている場合は、SigninLogs テーブルから上記の新しいフィールド含めた詳細な情報をクエリできます。
Graph API からログを取得する場合は、下記の API エンドポイントを使用することで上記の新しいフィールドを含めた詳細な情報を取得できます。
https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2025-12-09T00:00:00Z and createdDateTime le 2025-12-09T01:00:00Z and signInEventTypes/any(t: t eq 'interactiveUser')
上記の API は beta バージョンを使用していることにご注意ください。
signInEventTypes として interactiveUser を指定した（もしくは何も指定しない）場合は対話型サインインを取得でき、nonInteractiveUser を指定すると非対話型サインインを取得できます。
覚えておくとよいこと３つ
下記の３つは勘違いしやすいポイントなので、順番に解説します。
- 条件付きアクセス ポリシーが適用されないアプリケーションがある
- リスクは上書きされる
- AuthenticationRequirement は MFA かどうかを意味しない
条件付きアクセス ポリシーが適用されないアプリケーションがある
パスワードによる認証が成功するとその次のステップとして条件付きアクセス ポリシーによる評価が行われ、その結果が ConditionalAccessPolicies や ConditionalAccessStatus フィールドに書き込まれます。
つまり、これらの列に値があるかどうかを確認することでパスワードが通っているかどうかを判断できます。
しかし、下記のようなアプリケーションは ConditionalAccessStatus の値は常に notApplied になるため、そのようなアプリケーションもあるということを留意しておかないと判断を誤ることになります。
- Windows Sign In
- Microsoft Authentication Broker（ResourceDisplayName が Windows Azure Active Directory
の時）
上記のようなアプリケーションに条件付きアクセス ポリシーが適用されない理由について説明している公式情報は見つかっていませんが、下記のディスカッションでは「Windows Sign In はデバイス ローカルへのサインインだから」とのことです。
Conditional Access will never apply to Windows Sign In, that mechanism is excluded as the user will always be able access the desktop if their account is enabled. Because it's a password sign-on locally to the desktop, it's why it's showing up as single factor, again, Windows sign-in acquires/refreshes the PRT locally on the device and then accessing other resources would initiate a CA policy calling for something like MFA.
ちょっと納得感はないですが、いったん仕様としてそうなっているので覚えておきましょう。
リスクは上書きされる
ログは一般的に後から変わることはないですよね？もちろん Entra ID のサインイン ログも "ログ" なので後から情報が変わることはないと思うのが自然だと思います。
しかし、下記のフィールドの値は後から変わってしまう場合があります。
- riskDetails
- riskLevelAggregated
- riskState
このような状況は、リスクがあるサインインが行われた後、ユーザーがパスワードを変更するなどしてリスクが解決された場合に発生します。
Microsoft 365 が侵害された後に影響調査などを行う際には、このような動作になることを知っておかないと右側のログだけを見て「当時もリスクはなかった」と判断を誤ることになってしまいます。
この状況は調査対象の時間と API を使用してログ取得する時間が大きく離れている場合に発生する可能性があり、Sentinel や SIEM へリアルタイムに近い形でログ収集する場合には発生しません。しかし、arg_max などで Id ごとに重複を排除して調査をする場合には同じ状況になるので、リスク情報は後から変わる場合があることを覚えておきましょう。
AuthenticationRequirement は MFA かどうかを意味しない
サインインログには AuthenticationRequirement というフィールドがあり、下記のいずれかの値が入ります。
- singleFactorAuthentication
- multiFactorAuthentication
もし「singleFactorAuthentication」という値のログがあった場合は「MFA ではなかった」と思ってしまいそうですが、実はそのように判断するのはまだ早いかもしれません。
AuthenticationRequirement は認証ポリシー（条件付きアクセス ポリシー、ID Protection、Security Defaults、ユーザーごとの MFA など）によって要求された認証レベルが格納されます。
これらの認証ポリシーによって MFA が特に求められていない場合、このフィールドには singleFactorAuthentication という値が格納されます。
しかし、実際にはユーザーが MFA 相当のサインイン方法（例えば Authenticator のパスワードレス サインインや Windows Hello for Business など）を使用した場合、これらのサインインは MFA です。
もし調査対象のサインインが実際に MFA だったのかどうかを確認したい場合、AuthenticationRequirement ではなく AuthenticationDetails フィールドを確認することをお勧めします。
このフィールドからは "MFA requirement satisfied by claim in the token" "Passwordless MFA" などの実際の認証ステップの情報を確認できます。
おわりに
少し細かい内容になってしまいましたが、実務で「あれ？」となりやすいポイントを３つ紹介させていただきました。
特に侵害調査や不正アクセス調査の場面では、今回ご紹介した挙動を知らないことで誤った結論に至ってしまう可能性もあると思います。
Entra ID サインイン ログを扱う際の地雷ポイントとして、ぜひ頭の片隅に置いておいていただけると幸いです。