いいえ。Microsoft Entra IDで「サインインセッションを失効」しても、すべてのアプリが同時に強制ログアウトされるとは限りません。
セッション失効は、主にMicrosoft Entra IDが管理する更新トークンを無効にする操作です。しかし、すでに発行済みのアクセストークンや、各アプリが独自に発行したCookie・セッショントークンは別に管理されています。退職者や侵害された利用者のアクセスを確実に止めるには、次の処置を組み合わせる必要があります。
- Microsoft Entra IDでユーザーのサインインをブロックする
- サインインセッションを失効させる
- ハイブリッド環境ではオンプレミスActive Directory側も無効化する
- 各業務アプリでアカウント、権限、独自セッションを無効化する
- サインインログとアプリ側ログで残存アクセスを確認する
特に重要なのは、「セッション失効を実行した」ことと「すべてのアプリからアクセスできなくなった」ことは同義ではないという点です。
Entraでサインインセッションを失効させてもアクセスが残る理由
Microsoft Entra IDによる認証では、ひとくちに「セッション」と呼ばれていても、実際には複数の認証情報が使われています。
| 認証情報 | 主な役割 | 管理主体 |
|---|---|---|
| アクセストークン | APIやクラウドサービスへアクセスする | Microsoft Entra IDと対象サービス |
| 更新トークン | 新しいアクセストークンを取得する | Microsoft Entra ID |
| Entraのセッション | Microsoft Entra IDへのサインイン状態を維持する | Microsoft Entra ID |
| アプリ独自のCookie | アプリ内のログイン状態を維持する | 各アプリ |
| アプリ独自のセッショントークン | アプリ内で利用者を識別する | 各アプリ |
Microsoft Entra IDの「セッションの失効」は、これらすべてを一括削除する機能ではありません。
ユーザーのサインインをブロックし、更新トークンを失効させれば、そのユーザーは新しいトークンを取得できなくなります。一方、すでに発行されているアクセストークンは、対象サービスが失効を検知しない限り、有効期限まで利用できる場合があります。
さらに、ブラウザベースのSaaSなどでは、Microsoft Entra IDで認証した後に、アプリ自身が独自のCookieを発行することがあります。そのCookieを使ったアクセスでは、利用者がMicrosoft Entra IDへ戻されないままアプリを使い続けられる場合があります。Microsoft Entra IDは、アプリが独自に発行したセッショントークンを直接失効させることはできません。([Microsoft Learn][1])
「サインインをブロック」と「セッションを失効」は別の操作
退職者や侵害アカウントの停止では、少なくとも次の違いを理解しておく必要があります。
| 操作 | 主な効果 | それだけで十分か |
|---|---|---|
| サインインのブロック | 新しいサインインやトークン発行を拒否する | 不十分 |
| サインインセッションの失効 | 更新トークンを失効させ、再認証を要求する | 不十分 |
| アプリ側のユーザー無効化 | アプリ内の利用権限を止める | アプリごとに必要 |
| アプリ側のセッション終了 | 独自Cookieやセッションを無効化する | 対応機能がある場合に必要 |
| オンプレミスADの無効化 | 社内ADや連携システムへのアクセスを止める | ハイブリッド環境で必要 |
| 端末の無効化・ワイプ | 紛失端末や侵害端末からデータを保護する | 状況に応じて必要 |
サインインをブロックしても、すでに取得済みのトークンやアプリ内セッションが直ちに消えるとは限りません。
反対に、セッションだけを失効させてもユーザーアカウントが有効なままであれば、本人または攻撃者が再び認証し、新しいトークンを取得できる可能性があります。
そのため、緊急停止ではユーザー無効化とセッション失効をセットで行うのが基本です。
アクセストークンは失効操作後も残ることがある
アクセストークンは、利用者がサービスへアクセスする際に提示する認証情報です。
Microsoft Learnでは、通常のアクセストークンについて既定の有効期間を1時間と説明しています。ただし、これは「失効操作から必ず1時間アクセスできる」という意味でも、「必ず1時間後に切れる」という意味でもありません。
実際の反映時間は、次の要素で変わります。
- アプリやサービスがContinuous Access Evaluationに対応しているか
- クライアントアプリがCAEに対応しているか
- 対象サービスが失効イベントを受け取れるか
- アプリが独自のセッションを利用しているか
- アクセストークンやアプリCookieの有効期限
- アプリとMicrosoft Entra IDの同期頻度
したがって、運用手順書に「セッション失効後は必ず即時停止」「必ず1時間で停止」と固定的に書くのは適切ではありません。([Microsoft Learn][1])
CAE対応アプリでも「完全な即時停止」とは限らない
Continuous Access Evaluation、略してCAEは、ユーザー無効化や更新トークン失効などの重要なイベントを、対応するサービスへ伝える仕組みです。
CAEに対応したサービスでは、アクセストークンの有効期限を待たず、ユーザーの無効化やセッション失効を比較的早く反映できます。
ただし、CAEはすべてのアプリ、クライアント、通信方式で同じように動作するわけではありません。また、Microsoftの資料でも、重要イベントの反映は「near real time」とされており、イベント伝播による遅延が生じる可能性が示されています。([Microsoft Learn][2])
そのため、CAEを利用している環境でも、次のような断定は避けます。
- セッション失効を押せば全アプリが瞬時に切れる
- Microsoft 365なら必ず同じ時間で切れる
- アクセストークンが残っていても必ず即時拒否される
- ブラウザ、モバイル、デスクトップで挙動が同じになる
CAEはアクセス停止を速める重要な仕組みですが、アプリ独自のCookieまで一括削除するものではありません。
退職者や侵害アカウントのアクセスを止める手順
対象ユーザーと影響範囲を記録する
操作を始める前に、対象とするユーザーを確実に特定します。
最低限、次の情報を記録します。
| 確認項目 | 記録する内容 |
|---|---|
| 利用者 | 表示名、ユーザープリンシパル名、社員番号など |
| 停止理由 | 退職、異動、端末紛失、認証情報漏えいなど |
| 実施時刻 | 停止操作を開始した日時 |
| 利用端末 | PC、スマートフォン、共有端末など |
| 重要アプリ | Microsoft 365、業務SaaS、VPN、基幹システムなど |
| ディレクトリ構成 | クラウド専用か、オンプレミスAD同期か |
| 管理者 | 操作担当者と承認者 |
| 復帰条件 | 誰の承認で再有効化できるか |
表示名だけで対象を判断すると、同姓同名の利用者を停止する事故につながります。ユーザープリンシパル名やオブジェクトIDなど、重複しない情報も確認してください。
Microsoft Entra IDでサインインをブロックする
適切な管理者権限を持つアカウントで、対象ユーザーを無効化します。
Microsoft Learnに示されている管理センターでの基本的な流れは、次のとおりです。
- Microsoft Entra管理センターを開く
- 「Entra ID」からユーザー一覧を開く
- 対象ユーザーを選択する
- アカウントの状態を編集する
- アカウントを無効にして保存する
管理画面の名称や配置は変更される可能性がありますが、目的は対象ユーザーに新しいサインインを許可しない状態にすることです。
管理者アカウントを無効化する場合は、一般ユーザーとは異なる管理ロールが必要になることがあります。操作権限が不足している場合に、強い権限を安易に恒久付与するのではなく、承認済みの緊急対応手順に従ってください。([Microsoft Learn][1])
サインインセッションを失効させる
アカウントを無効化した後、対象ユーザーの「Revoke sessions」に相当する操作を実行します。
Microsoft Graph PowerShellを利用する場合は、Microsoft Learnで次のコマンドが案内されています。
Revoke-MgUserSignInSession -UserId $userIdこの操作には適切なMicrosoft Graph権限が必要です。対象ユーザーの取り違えを防ぐため、表示名だけでなくユーザープリンシパル名やIDを事前に出力し、確認してから実行します。
大量退職などで自動化する場合も、次の処理は分けて記録するのが安全です。
- ユーザーを無効化した結果
- セッションを失効させた結果
- アプリのプロビジョニングを停止した結果
- 各処理で発生したエラー
一つのスクリプトが正常終了しただけで、すべてのアプリから切断されたと判断してはいけません。
侵害が疑われる場合は認証情報も再確立する
アカウント侵害が疑われる場合、サインインのブロックとセッション失効だけで対応を終えないようにします。
状況に応じて、次の処置を計画します。
- パスワードのリセット
- 多要素認証方法の確認
- 不審な認証方法や端末登録の調査
- 利用者本人の確認後に認証方法を再登録
- 登録端末の無効化
- 不審なアプリ同意や権限付与の確認
- メール転送設定や受信トレイルールの確認
- アプリ側APIキーや個人用トークンの確認
退職処理ではアカウントを再利用しない前提で進められますが、侵害対応では安全な状態へ戻した後に再有効化する場合があります。復帰させるときは、利用者からの連絡だけで有効化せず、管理者や所属責任者などによる承認を必須にします。
クラウド専用とハイブリッド環境では対応が異なる
クラウド専用ユーザーの場合
Microsoft Entra IDだけで管理しているユーザーでは、主に次の処置を行います。
- Microsoft Entra IDでユーザーを無効化する
- サインインセッションを失効させる
- 登録端末の扱いを確認する
- 各アプリのアカウントとセッションを無効化する
- サインインログとアプリ側ログを確認する
ただし、アプリ内に独立したローカルアカウントが作成されている場合は、Microsoft Entra ID側の無効化だけでは止まりません。
オンプレミスADと同期している場合
オンプレミスActive DirectoryからMicrosoft Entra IDへ同期している環境では、クラウド側だけを無効化して完了としてはいけません。
基本的には次の両方を実施します。
- オンプレミスActive Directoryでユーザーを無効化する
- Microsoft Entra IDでサインインをブロックする
- Microsoft Entra IDのセッションを失効させる
- 同期処理の結果を確認する
- オンプレミス接続アプリやファイルサーバーのアクセスを確認する
オンプレミスADのアカウントが有効なままだと、クラウド外のWindows認証、ファイルサーバー、社内アプリなどへ引き続きアクセスできる可能性があります。
Microsoftは、ハイブリッド環境でアカウント侵害が疑われる場合、オンプレミスAD側での無効化に加え、パスワード複製の遅延やPass-the-Hashへの対策としてパスワードを複数回リセットする手順も示しています。ただし、侵害の可能性がない通常の退職処理では、環境の運用基準に従って判断します。([Microsoft Learn][1])
アプリ独自のセッションを別途無効化する
Microsoft Entra IDでの対応後は、対象ユーザーが利用していたアプリを分類します。
Entra IDのトークンを継続的に確認するアプリ
対象サービスがCAEなどに対応していれば、ユーザー無効化やセッション失効が比較的早く反映される可能性があります。
ただし、対応状況はサービス名だけで決めつけず、次の組み合わせで確認します。
- 対象サービス
- デスクトップ、ブラウザ、モバイルなどのクライアント種別
- クライアントのバージョン
- 認証方式
- CAEへの対応状況
ログイン後に独自Cookieを発行するアプリ
説明例として、Microsoft Entra IDで初回認証した後、アプリが8時間有効な独自Cookieを発行する構成を考えます。
このアプリがCookieの有効期間中にMicrosoft Entra IDへ問い合わせない設計であれば、Entra側でセッションを失効させても、アプリ内のアクセスがすぐには止まらない可能性があります。
この場合は、アプリ側で次のいずれかを実施します。
- ユーザーアカウントを無効化する
- ユーザーを削除またはデプロビジョニングする
- すべてのセッションからログアウトさせる
- アプリ側のセッションを管理者が失効させる
- グループやロールからユーザーを削除する
アプリに強制ログアウト機能がない場合は、アプリベンダーへの問い合わせや、セッションの有効期限を待たずにアクセスを止める代替策が必要です。
Entra IDを経由せず直接ログインできるアプリ
Microsoft Entra IDとのシングルサインオンを利用していても、アプリ側のIDとパスワードで直接ログインできる構成が残っていることがあります。
この場合、Entra IDでユーザーを無効化しても、アプリのローカル認証でアクセスされる可能性があります。
次の点を確認します。
- ローカルパスワードでのログインが許可されていないか
- 緊急用アカウントとして登録されていないか
- 個人用アクセストークンが発行されていないか
- APIキーやアプリパスワードが残っていないか
- 外部IDとローカルIDが別アカウントになっていないか
Microsoftも、セッショントークンを利用するアプリや、Entra IDを経由せず直接サインインできるアプリについて、アプリ側でのデプロビジョニングを推奨しています。([Microsoft Learn][1])
サインインログだけでは停止完了を証明できない
アクセス停止後はMicrosoft Entra IDのサインインログを確認します。ただし、サインインログに新しい成功記録がないことだけで、アクセス停止が完了したとは判断できません。
アプリ独自のCookieが使われている間は、アプリがMicrosoft Entra IDへ認証要求を送らない場合があります。このアクセスは、新しいEntraサインインとして記録されない可能性があります。
そのため、確認先を分けます。
| 確認先 | 確認すること |
|---|---|
| Entraサインインログ | 停止後に新しい認証が成功していないか |
| 監査ログ | ユーザー無効化やセッション失効が実行されたか |
| アプリ管理画面 | ユーザーが無効または削除されているか |
| アプリ監査ログ | 停止後にも操作やデータ参照が続いていないか |
| 端末管理 | 対象端末が無効化、回収、ワイプ対象になっているか |
| プロビジョニングログ | デプロビジョニングが成功したか |
| オンプレミスAD | アカウントが無効化され、同期結果が反映されたか |
特に重要な業務アプリでは、「管理操作を実施した記録」と「実際にアクセスが拒否された記録」の両方を残します。
よくある失敗
セッション失効だけを実行して終える
更新トークンを失効させても、アカウントが有効なら再認証される可能性があります。先に、または同時にサインインをブロックします。
ユーザー無効化だけで全アプリが切れたと思う
発行済みアクセストークンやアプリ独自Cookieが残ることがあります。重要アプリは個別にセッションを終了します。
「1時間待てば必ず止まる」と判断する
アクセストークンの既定値だけを基準にしてはいけません。CAE、クライアント、アプリ独自セッション、同期頻度によって反映時間は変わります。
クラウド側だけを無効化する
ハイブリッド環境ではオンプレミスAD側も停止します。ファイルサーバーやオンプレミスアプリなど、クラウド外の認証先も確認が必要です。
サインインログに記録がないため安全と判断する
既存のアプリセッションによる操作は、新しいEntraサインインを発生させない場合があります。アプリ側の監査ログも確認します。
問い合わせを受けてすぐ再有効化する
侵害対応では、攻撃者が本人になりすまして復旧を依頼する可能性も考慮します。本人確認、原因調査、認証方法の再確立、管理承認を終えてから有効化します。
アクセス停止時の実務チェックリスト
- 対象ユーザーをユーザープリンシパル名などで特定した
- 停止理由と実施時刻を記録した
- クラウド専用かハイブリッドかを確認した
- Microsoft Entra IDでサインインをブロックした
- サインインセッションを失効させた
- 侵害時はパスワードと認証方法を再確認した
- 必要に応じて登録端末を無効化した
- オンプレミスAD側のユーザーを無効化した
- 同期処理の結果を確認した
- 重要なSaaSや業務アプリでユーザーを無効化した
- アプリ独自のセッションを終了した
- ローカルログインやAPIトークンの有無を確認した
- Entraサインインログと監査ログを確認した
- アプリ側のアクセスログを確認した
- 再有効化の承認者と条件を記録した
セッション失効は「停止処理の一部」と考える
Microsoft Entra IDのサインインセッション失効は、退職者や侵害アカウントへの対応で欠かせない操作です。しかし、単独で全アプリを即時切断する機能ではありません。
確実にアクセスを止めるには、次の順序で対応します。
- 対象ユーザーと利用アプリを特定する
- Microsoft Entra IDでユーザーを無効化する
- サインインセッションを失効させる
- ハイブリッド環境ではオンプレミスADも無効化する
- アプリ独自のアカウントとセッションを停止する
- Entraとアプリ双方のログで残存アクセスを確認する
運用上は、「失効ボタンを押したか」ではなく、重要なアプリへのアクセスが実際に拒否されているかを完了条件にしてください。
[1]: https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access “Revoke user access in an emergency in Microsoft Entra ID – Microsoft Entra ID | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation “Continuous access evaluation in Microsoft Entra – Microsoft Entra ID | Microsoft Learn”
コメント