Microsoft 365やAzureを利用していると、サインインログに見慣れないMicrosoft CorporationのIPアドレスが記録され、匿名トークンという表示も見かけることがあります。こうした挙動は不正アクセスと関係があるのか、どんな原因が考えられるのか、気になるところです。
Microsoft IPアドレスによる不審なサインインが疑われる背景
Microsoft 365やAzure Active Directory（以下、Azure AD）を使っていると、ログイン履歴にMicrosoft Corporationが保有するIPアドレス（例: 51.140.177.153 / 52.171.132.174）からのサインインが記録される場合があります。さらに、そのログの詳細を見ると「匿名トークン（Anomalous Token）」として表示され、自分のアカウント名でサインインしたかのように見えることもあります。このようなログが残ると、不正アクセスやアカウントの乗っ取りが疑われがちです。しかし実際には、Microsoftのクラウド認証基盤が内部的に行っている正規の挙動であるケースが少なくありません。ここでは、その背景や仕組み、そしてセキュリティ観点からの注意点について解説します。
Microsoftのクラウドインフラが絡むサインインとは
Microsoft 365やAzureは、複数のサービスが相互に連携しながらユーザー認証やトークンの発行を行います。そのため、ユーザーが直接アクセスしていないタイミングでも、Microsoft側のシステムがユーザーのアクセス トークンや認証情報を扱うことがあります。
例えば、以下のようなケースが挙げられます。
- Azure ADやMicrosoftアカウントのトークンをバックエンドで更新する
- SSO（シングルサインオン）を実現するため、セッションを継続させる処理
- 認証プロバイダ同士の連携（OAuthやOpenID Connectなど）の過程
これらのプロセスでは、Microsoftが管理するIPアドレスからの認証処理がサインインログに記録されることがあるため、一見すると「MicrosoftのIPから自分のアカウントでログインされた」ように見えてしまうのです。
匿名トークン（Anomalous Token）の正体
サインインログに表示される「匿名トークン」や「Anomalous Token」は、トークンを発行した主体とログを記録するシステムとの間に差異がある場合に付与されるラベルです。Microsoftのクラウドでは多数のサービスが連携しており、その過程で以下のような理由で匿名トークン扱いになることがあります。
- トークンが異なる認証プロバイダを経由して発行されている
- IPアドレスが通常のユーザー接続とは異なるために疑義があると認識されている
- ログイン元端末の位置情報や時刻情報と整合性が不明確な場合
ただし「匿名トークン」と表示されているからといって、即座に不正アクセスがあったとは限りません。実際には認証プロセスを連携するうえで想定内の挙動であることも多いです。
不正アクセスの可能性はあるのか
結論からいうと、Microsoft IPアドレスからのログが常に不正アクセスを意味するわけではありません。むしろ正規の認証プロセスである場合が多いです。とはいえ、以下のポイントを押さえておくことで、不審な活動と正規のシステム挙動を区別しやすくなります。
疑わしいアクセスを見極めるチェックリスト
下記のような視点でサインインログや運用状況を確認すると、不審なアクセスが疑われるかどうかを判断しやすくなります。
| チェック項目 | 具体的なチェックポイント |
|---|---|
| アクセス日時 | その時間帯に自分や組織がMicrosoft 365やAzureにログインする操作を行っていたか確認する。深夜や休日など普段の運用と明らかにかけ離れている場合は要注意。 |
| 操作内容 | ログで示されるアクセス先リソースや操作内容（例：Exchange Onlineへのアクセス、SharePoint操作など）を比較し、自身の業務と乖離していないか調べる。 |
| 試行回数 | 短時間で大量のログイン試行や失敗が記録されていないか確認。アカウントロックが頻発している場合も不正アクセスの兆候。 |
| IPアドレスの所属 | アクセス元IPアドレスがMicrosoftや自社VPNなど正当な場所に紐付いているかを確認。インターネット上の不審なホストやブラックリスト登録がないかもチェック。 |
| 多要素認証(MFA)状況 | MFAを有効にしている場合、想定外の時間帯や場所からのアクセスでMFAが実施されていないなら要注意。本人以外がアクセスしている可能性。 |
もし上記のどれにも当てはまらず、さらに心当たりのないログが続くようであれば、不正アクセスの可能性をより強く疑い、パスワードの変更やアカウントのロックダウンを検討しましょう。
本当に不正アクセスだった場合の症状
不正アクセスによって実害が発生する場合、以下のような兆候が現れることが多いです。
- ファイルの勝手な削除や変更、メールの不正送信
- アカウントのパスワード変更通知やアラートの増加
- 組織内の複数アカウントが同時にロックアウトされる
- 二要素認証の設定が勝手に無効化されている
このような症状が見られる場合は、速やかにセキュリティチームやMicrosoftサポートへ連絡し、調査を依頼することが重要です。
Microsoft IPアドレスでサインインが行われる仕組み
では、なぜMicrosoft自身のIPアドレスからのサインインが必要になるのでしょうか。これはMicrosoftのクラウドインフラが、ユーザーの認証プロセスを代行し、背後でトークンを更新・認証する仕組みが関係しています。
シングルサインオン（SSO）の裏側
SSOが機能している環境では、以下のようなフローがよく実行されます。
- ユーザーが一度ログインすると、セッションやトークンが発行される
- 別のサービスやアプリにアクセスした際、認証トークンを持参してログインがシームレスに行われる
- 裏でトークンの期限更新や、追加のアクセススコープの承認が行われる
- これらの認証プロセスはMicrosoftの認証サーバーが仲介し、トークンを再発行する
その仲介プロセス自体が、MicrosoftのIPアドレスからサインインしているように見える原因です。ユーザーからすると「勝手にMicrosoftが自分のアカウントでログインしている」と感じますが、実際にはSSOの利便性やセキュリティを確保するために必要な処理だといえます。
トークンのライフサイクル管理
トークンには有効期限が設定されており、期限が近づくとリフレッシュトークンを使って再発行される仕組みがあります。これもまたMicrosoftのIPアドレスで行われる処理の一部で、サインインログに残る原因の一つです。
リフレッシュトークンの発行や再認証のタイミングで「匿名トークン」扱いになると、異常なアクセスに見えることがありますが、多くは正当な理由による動きです。
セキュリティを強化するための具体策
Microsoft 365やAzureを運用するうえで、万が一の不正アクセスに備えてセキュリティ対策を講じることは不可欠です。ここでは代表的な対策をいくつか挙げます。
多要素認証（MFA）の導入・徹底
最も有効な対策の一つがMFAの導入です。パスワードだけではなく、スマートフォンのアプリや電話、SMS認証コードなどを組み合わせることで、アカウント乗っ取りのリスクを大幅に下げることができます。
また、MFAを導入しているだけでなく、定期的に認証手段が動作しているかテストし、アカウント運用ポリシーに穴がないか確認しましょう。
条件付きアクセスポリシーを活用する
Azure ADでは「条件付きアクセス」という機能が利用できます。アクセス元のIPアドレスや端末の状態、ユーザーの所属グループなどに基づいて、追加の認証を要求したり、アクセスをブロックしたりする高度な制御が可能です。
例えば以下のようなポリシーを設定することでリスクを低減できます。
- 社内ネットワーク外からのアクセスに対してMFAを必須化
- デバイスがIntune管理下にない場合にはアクセス制限
- 不審なIPアドレス（海外からの大量アクセスなど）をブロック
サインインアラート・レポートの活用
Microsoft 365やAzure ADには、多数のセキュリティレポートが用意されています。特に「危険度の高いサインイン」や「リスクの高いユーザー」などは、通常と異なる挙動を自動で検知して通知してくれる仕組みです。これらのレポートやアラートを定期的にチェックすることで、早期発見と対処が可能になります。
PowerShellやGraph APIでのログ監視
より詳細な監査ログが必要な場合、以下のようなスクリプトを活用してログイン履歴を定期取得・分析できます。
例として、PowerShellでAzure ADに接続し、サインインログを取得するコードは以下の通りです。
# Azure ADに接続
Connect-AzureAD
# サインインアクティビティを取得
# 最後の100件のサインインログを取得する例
$signInLogs = Get-AzureADAuditDirectoryLogs -Category SignInLogs -Top 100
# ログを表示
$signInLogs | Format-Table CreatedDateTime, UserPrincipalName, IPAddress, ResultStatusこのようにして取得したログをExcelにエクスポートしたり、自社のSIEM（Security Information and Event Management）に連携したりすることで、より高度な分析ができます。
Microsoft IPからのサインインは「通常挙動」である可能性大
多くの場合、MicrosoftのIPアドレスからのサインインはクラウドサービスの認証基盤が正常に動作している証拠であり、必ずしも不正アクセスを示すものではありません。
しかし、自分の知らない時間帯や操作が発生していたり、多数の失敗したログイン試行が記録されていたりする場合は、注意が必要です。Microsoftやセキュリティチームと連携し、アカウントのパスワードリセットや監査ログの精査を行いましょう。
社内ガイドラインやユーザー教育の重要性
「MicrosoftのIPアドレスでのサインインは怪しいから即ブロックする」という短絡的な対応は、業務に支障をきたす可能性があります。むしろ、クラウドサービスならではの挙動を正しく理解し、どのようなログが通常の挙動なのかを社内で共有することが重要です。
ユーザー教育としては、以下のようなポイントを周知すると良いでしょう。
- 匿名トークンやMicrosoft IPからのサインインを見かけた場合の確認手順
- MFAが要求された場合は正規の操作であること
- 不審なメールやリンクを踏まないなど、基本的なセキュリティ対策
まとめ：正常な動作と不正を見分ける鍵は「ログ分析」と「MFA」
Microsoft 365やAzureのように高度にクラウド化された環境では、従来のオンプレミス環境とは異なるログが頻繁に出現します。その中でも「Microsoft CorporationのIPアドレス」や「匿名トークン（Anomalous Token）」といった記録は混乱を招きやすい要素です。しかしながら、大半は正当なクラウド認証プロセスによるものであり、必ずしも不正の兆候ではありません。
一方で、不審な挙動が少しでも疑われる場合には、サインインログの詳細分析やMFAの強制、条件付きアクセスの適用など、具体的な対策を行うことが最重要です。「本当に危険なのか」または「通常のクラウド処理なのか」を見極めるために、日頃から監査ログを活用し、組織全体でセキュリティ意識を高めていきましょう。
コメント