Exchange サーバーのセキュリティログ（イベント ID 4624 / 4648）で、社内ユーザーの利用なのに IpAddress が 52.96.xx.xx など Microsoft の公開 IP になることがあります。多くは Outlook モバイルがクラウド中継を使う設計が原因です。仕組み、見分け方、端末の実 IP を追う運用を整理します。
現象の整理：4624/4648 の IpAddress が「社内端末」ではなく「Microsoft 公開 IP」になる
Exchange を運用していると、次のような状況に遭遇します。
- ユーザーは社内 LAN（プライベート IP）から Outlook を使っていると言っている
- Exchange サーバーのセキュリティログ（4624 / 4648）を見ると、送信元 IP（IpAddress / Source Network Address）が 52.96.xx.xx などのパブリック IP
- WHOIS や IP レピュテーションで調べると Microsoft のネットワークに見える
- 「社内からのログオンなのに外部 IP。侵害では？」と疑ってしまう
結論から言うと、Outlook for iOS / Android（Outlook モバイル）を利用している場合、この挙動は想定どおりです。Exchange が見ている“直近の通信相手”が端末ではなく、Microsoft 側の中継サーバーになるためです。
先に結論：Outlook モバイルは Microsoft 中継を経由するため、Microsoft 公開 IP がログに残りやすい
Outlook モバイルは、接続・認証・同期の過程で Microsoft 側のクラウド中継（プロキシ）サービスを使うことがあります（多くの環境でこの形になります）。その場合、Exchange（IIS / w3wp.exe）が受け取る通信の“直近の接続元”は社内端末ではなく Microsoft の中継サーバーです。
このため、Windows のセキュリティログ（4624/4648）が記録する IpAddress は、端末の社内 IP ではなく Microsoft の公開 IP（例：52.96.xx.xx）として見えることがあります。
まず押さえるポイント：セキュリティログの IP は「最終的に見えた接続元」
イベント ID 4624 / 4648 は、Windows の監査ログとして「ログオン」や「明示的資格情報でのログオン試行」を記録します。ここで記録される IP は、ざっくり言うと その時点でサーバーが通信相手として認識したアドレスです。
ネットワーク的にプロキシ／リバースプロキシ／ロードバランサ（SNAT）／NATなどが挟まると、サーバーから見える相手は「本来の端末」ではなく「中継機器」になります。Outlook モバイルの場合は、その中継が Microsoft クラウド側にあるため、Microsoft 公開 IP が出る、という構図です。
| イベント ID | 概要 | Exchange で起きやすいパターン | IP の読み方（要点） |
|---|---|---|---|
| 4624 | アカウントのログオン成功 | HTTP(S) 経由の認証（IIS / w3wp.exe）やサービス動作に紐づくログオンが記録される | 「接続の最終到達点」から見た送信元。プロキシがいればプロキシの IP になりやすい |
| 4648 | 明示的資格情報でのログオン試行 | 認証処理の流れの中で、別の資格情報を使う場面があると記録されることがある | 同様に“直近の相手”が出る。4624 とセットで相関を見ると解像度が上がる |
4624/4648 のイベント詳細で見るべき項目
「Microsoft の IP が出た」だけで判断すると、誤検知も見落としも起こりやすくなります。イベント詳細のどこを見れば良いか、実務で使う観点をまとめます（表示名は OS 言語やログビューアで多少変わります）。
| 見る項目 | 例 | 意味 | 読み取りのコツ |
|---|---|---|---|
| ログオン タイプ（Logon Type） | 3（Network） | どんな形のログオンか | Exchange へのリモートアクセス系は 3 が出やすい。対話ログオン（2）とは性質が違う |
| プロセス名（Process Name） | w3wp.exe | どのプロセスが認証を発生させたか | HTTP 経由なら IIS ワーカープロセス（w3wp.exe）周辺が出やすい。別プロセスなら別経路の可能性 |
| アカウント名（TargetUserName など） | user@domain / DOMAIN\user | 誰の認証か | 同名ユーザーの取り違えに注意。UPN と SAMAccountName の違いも把握しておく |
| ワークステーション名 | （空欄 / 不明） | 接続元のホスト名の手がかり | HTTP/プロキシ経由では埋まらないことが多い。ここが取れないのは異常とは限らない |
| 送信元 IP（IpAddress / Source Network Address） | 52.96.xx.xx | サーバーから見えた接続元 | 中継があれば中継の IP。端末の実 IP とは限らない |
| 送信元ポート（Source Port） | 49321 など | クライアント側の一時ポート | FW/NAT のセッションログと突合しやすい。時刻と合わせて相関の鍵になる |
原因：Outlook モバイルは Microsoft のクラウド中継サービスを経由する
Outlook モバイル（Outlook for iOS / Android）は、端末から Exchange に直接つなぎに行くのではなく、Microsoft 側のクラウドサービスがいったん通信を受け、そこから Exchange に接続するアーキテクチャを採ることがあります。
その結果、Exchange（IIS / w3wp.exe）が受け取る TCP/HTTP の“直近の接続元”は社内端末ではなく、Microsoft データセンター側の中継サーバーです。Windows のセキュリティログは基本的にネットワーク層（接続元）を見て記録するため、4624/4648 の IpAddress が Microsoft の公開 IP（例：52.96.xx.xx）として残ります。
| 通信経路 | Exchange が認識する送信元 IP | セキュリティログ（4624/4648）の傾向 | 補足 |
|---|---|---|---|
| Outlook（PC）→ 社内 LAN → Exchange | 端末の社内 IP（または VPN 付与 IP） | 社内 IP が出やすい | 途中で NAT や LB が SNAT すると、その IP に置き換わる |
| OWA（ブラウザ）→ 社内 LAN → Exchange | 端末の社内 IP（または VPN 付与 IP） | 社内 IP が出やすい | リバースプロキシ配下だとプロキシ IP になりやすい |
| Outlook モバイル → Microsoft 中継 → Exchange | Microsoft 公開 IP | Microsoft 公開 IP が出やすい | 「端末が社内にいるかどうか」とは独立して起きうる |
誤解しやすい点：社内 Wi-Fi 利用でも Microsoft 公開 IP になるのか
なります。ポイントは「端末がどこにいるか」ではなく「Exchange に到達する直前の相手が誰か」です。Outlook モバイルが Microsoft 中継を使う場合、端末が社内 Wi-Fi でも社外 LTE でも、Exchange から見える相手は Microsoft になり、結果として 4624/4648 の IpAddress が Microsoft 公開 IP になります。
ここが、“社内 IP で記録されるはず”という運用上の前提が崩れる典型パターンです。特に SIEM で「社内 IP 以外はアラート」としている場合、Outlook モバイル利用者が増えるほど誤検知が増えます。
Outlook モバイル経由かどうかを見分ける具体的な方法
「Microsoft の IP が出ている」だけで Outlook モバイルと断定するのは早計です。まずは、同時刻・同ユーザーで以下を突き合わせて、根拠を積み上げるのが安全です。
IIS ログで User-Agent と URL を確認する
Exchange の IIS ログは、HTTP のリクエスト情報（URL、User-Agent、クライアント IP、ステータスなど）を追えるため、セキュリティログよりも“どのクライアントが何をしに来たか”の判別に向きます。特に次の観点が有効です。
- URL パス：/Microsoft-Server-ActiveSync、/EWS、/mapi、/autodiscover など、どのエンドポイントに来ているか
- User-Agent：Outlook-iOS、Outlook-Android、またはモバイル系の識別子が含まれるか
- 時刻：4624/4648 の発生時刻と、該当ユーザーの IIS リクエストが一致するか
もし IIS ログ上でもクライアント IP が Microsoft 公開 IP になっており、かつ User-Agent が Outlook モバイル系であれば、今回の現象と筋が通ります。
Exchange 側のモバイル端末情報を確認する
Exchange には、メールボックスに紐づくモバイル端末（ActiveSync のパートナーシップ等）を確認できる仕組みがあります。運用の現場では、「このユーザーに Outlook モバイル端末が登録されているか」を見ておくだけでも切り分けが早くなります。
ここで端末が確認でき、さらに IIS ログの User-Agent と整合していれば、セキュリティログの Microsoft 公開 IP は「中継の結果」と説明しやすくなります。
“Microsoft 公開 IP”が出るのは Outlook モバイルだけではない
今回の原因として Outlook モバイルが最有力でも、運用としては「中継が挟まると IP が置き換わる」という一般則を理解しておくのが重要です。代表例を表にまとめます。
| 構成・製品 | ログに出やすい IP | 起きる理由 | 確認のヒント |
|---|---|---|---|
| リバースプロキシ（WAF / WAP / Nginx 等） | プロキシの IP | プロキシが Exchange へ新規接続するため | IIS の X-Forwarded-For、プロキシ側アクセスログ |
| ロードバランサ（SNAT あり） | LB の SNAT アドレス | 送信元変換でクライアント IP が置き換わる | LB の SNAT 設定、フローデータ |
| NAT ゲートウェイ | NAT の外向き IP | 出口の IP が統一される | FW/NAT のセッションログ |
| クラウド中継（Outlook モバイル等） | クラウド側の公開 IP | クラウドが端末に代わって Exchange へ接続する | User-Agent、端末登録、Azure AD サインイン（利用している場合） |
端末の実 IP（社内 IP）を追いたいときの考え方
4624/4648 だけで端末の社内 IP を追いきれないケースでは、「ログの取り方」を切り替える必要があります。結論として、“どこで端末→外部への通信を捕まえるか”が鍵です。
おすすめのログ突き合わせ先
| ログ/データ | 追えるもの | 強み | 注意点 |
|---|---|---|---|
| FW / プロキシ / VPN 機器のログ | 社内端末の IP、宛先（Microsoft など）、時刻 | 「社内端末→外」方向の実 IP を押さえられる | ユーザー名が取れない場合は DHCP/端末台帳との相関が必要 |
| Exchange IIS ログ | URL、User-Agent、認証結果、クライアント IP | “どのクライアントが何のエンドポイントを叩いたか”が見える | 中継があるとクライアント IP は中継の IP になりうる |
| Exchange プロトコルログ（環境依存） | プロトコル単位の詳細（例：EAS/EWS など） | アプリ種別の推定材料が増える | 出力範囲・粒度はバージョン/設定で差が出る |
| MDM（Intune 等）/ 端末管理台帳 | 端末の識別子、利用アプリ、準拠状態 | “どの端末が Outlook モバイルを使っているか”を特定しやすい | ネットワークの瞬間的な IP とは別管理になりやすい |
| Azure AD サインインログ（利用している場合） | サインイン元 IP、デバイス情報、アプリ | クラウド側の認証イベントから追跡できる | オンプレのみで完結している環境では使えない場合がある |
特に監査・インシデント対応で「社内端末の実 IP を証跡として出したい」場合は、FW/プロキシ/VPN のログを一次情報として押さえ、Exchange 側は“誰の認証だったか”の突合せに使う運用が現実的です。
IIS ログで“元のクライアント IP”を残す工夫
中継機器がある場合、HTTP ヘッダーに元のクライアント IP を載せる（例：X-Forwarded-For）設計にして、IIS 側でそのヘッダーをログに出すと、切り分けが楽になります。
- リバースプロキシや WAF が X-Forwarded-For を付与できるか確認する
- IIS のログ項目として、該当ヘッダーを記録できるようにする（拡張ログ/追加フィールド）
- 中継が多段の場合は、ヘッダーの並び順（最初が元クライアント、最後が直近中継など）を運用で統一する
ただし、Windows セキュリティログ（4624/4648）はヘッダー情報を理解してくれないため、あくまで「IIS ログやプロキシログで元 IP を確保し、相関分析で補う」という位置づけになります。
Microsoft 公開 IP を許可リストに入れるときの注意
「Microsoft 公開 IP が出るなら、その IP を FW の許可リストに入れれば良い」と考えがちですが、ここには注意点があります。
- IP は増減・変動し得る：クラウドの IP 帯は固定とは限りません。静的な手入力運用は破綻しやすいです。
- 目的を分ける：許可リストは「サービス稼働のための到達性確保」、アクセス制御は「本人性・端末性・リスク」で分ける方が安全です。
- 最小権限：公開する URL/ポート、認証方式、条件付きアクセスや MFA を組み合わせ、IP 許可だけに依存しない設計にします。
運用上は「Microsoft だから安全」と単純化せず、アプリ種別（Outlook モバイル）と認証の強度（MFA 等）をセットで考えるのが現実的です。
トラブルシューティング：短時間で原因に到達するチェックリスト
誤検知と不正アクセスの切り分けを急ぐときは、次の順番が効率的です。
| 手順 | 確認内容 | 判断の目安 | 次のアクション |
|---|---|---|---|
| IP の帰属確認 | 該当 IP が Microsoft のネットワークか | Microsoft に紐づくなら中継の可能性が上がる | 同時刻の IIS ログへ |
| IIS ログの突合 | 同ユーザー・同時刻・同 IP のアクセスがあるか | User-Agent が Outlook モバイル系なら濃厚 | 端末登録情報の確認へ |
| 端末情報の確認 | 該当ユーザーに Outlook モバイル/モバイル端末が紐づくか | 一致すれば“想定どおり”説明が可能 | SIEM/監査ルール見直しへ |
| ネットワークログ | 社内端末から Microsoft 宛ての通信があったか | 端末 IP と時刻が一致すれば実 IP の特定に近づく | DHCP/端末台帳で利用者特定 |
| 例外パターン検討 | リバースプロキシ/LB/NAT/VPN の存在 | 構成上あり得るなら、その IP が出るのも自然 | X-Forwarded-For 等のログ設計へ |
セキュリティ運用の落とし穴と、現実的な対策
Outlook モバイルや各種プロキシを前提にすると、「IP だけで内外判定する」運用は破綻しがちです。代わりに、次のように複数のシグナルで判断する設計が安定します。
推奨する判断軸
- ユーザー本人性：MFA、パスワードレス、リスクベース認証など
- 端末の健全性：Intune 準拠、デバイス証明書、アプリ保護ポリシー
- アクセス元の属性：国/地域、ASN、普段の利用傾向（UEBA）
- アプリ種別：Outlook モバイル、Outlook PC、ブラウザなど（User-Agent、サインインログ）
- ネットワーク情報：IP だけでなく、VPN 接続有無、プロキシ通過有無、出口 IP の変化
SIEM ルールの改善例（考え方）
たとえば「社内 IP 以外はアラート」という単純ルールは、Outlook モバイル利用者に対して誤検知を量産します。代わりに以下のような設計にすると、実用性が上がります。
- Microsoft 公開 IP からのアクセスでも、User-Agent が Outlook モバイルで、端末が準拠なら許容
- Microsoft 公開 IP からのアクセスでも、短時間に大量失敗や、普段と異なる時間帯・国ならアラート
- Microsoft 公開 IP ではなく、未知のクラウド事業者や VPN 事業者の IP が出た場合は優先度を上げる
よくある質問
Microsoft の IP が出ている＝不正アクセスではない、で確定してよい？
確定は避けた方が安全です。Outlook モバイルの可能性が高いのは事実でも、同時刻の IIS ログや端末情報で整合性を取るまでは「仮説」として扱うのが推奨です。特に、普段そのユーザーがモバイルを使わない運用なら、なぜ急にモバイル経由になったのかを確認してください。
特定の範囲（例：52.96.xx.xx）ばかり出るのはなぜ？
Microsoft のクラウド中継や Microsoft 365 のサービスは、データセンターの公開 IP から接続します。地域やサービスの収容状況によって、よく登場する IP 帯が偏ることがあります。運用では「固定の少数 IP だから安全」と決めつけず、あくまでアプリ種別・認証状態・端末状態も合わせて判断するのが堅実です。
監査で「端末の社内 IP」を求められた。4624/4648 だけで出せない？
中継が挟まる設計では、4624/4648 だけで端末の社内 IP を出すのは難しいケースが多いです。代替として、FW/プロキシ/VPN のログを証跡として提示し、Exchange 側のログ（4624/4648、IIS）で「該当ユーザーの認証・アクセスである」ことを突合せると説明しやすくなります。
社内からの利用だけ許可したい。Outlook モバイルを使うと無理？
「社内 IP であること」を条件にする方式は、Outlook モバイルやクラウド中継を前提にすると成立しにくくなります。代わりに、VPN 必須や 準拠デバイスのみ許可、アプリ保護ポリシーなど、IP 以外の条件で制御する設計を検討してください。
まとめ：Microsoft 公開 IP は“仕様”になりうる。追跡はログの役割分担で解決する
Exchange のセキュリティログ（4624 / 4648）に Microsoft 公開 IP が記録される現象は、Outlook モバイルがクラウド中継を使う場合に起こり得る、よくある挙動です。重要なのは、4624/4648 の IP は「端末 IP」ではなく「直近の接続元」になり得ると理解し、実 IP を追うときは FW/プロキシ/VPN・IIS ログ・端末管理情報を組み合わせて運用することです。これにより、誤検知を減らしつつ、監査やインシデント対応で必要な証跡も取りやすくなります。
コメント