結論から言うと、2026年4月16日時点で注目すべき更新は、Microsoft Entra External IDでConditional Accessのセッション制御を設計対象に含めやすくなったことです。Microsoftの2026年3月分のEntra更新では、Microsoft Entra External IDの新リリースとして「Session Control Conditional Access Policies in Entra External ID」が挙げられています。これにより、外部ユーザーや顧客向けアプリに対して「どのくらいの頻度で再認証させるか」「ブラウザを閉じた後もサインイン状態を保持するか」を、より実務的に検討する必要が出てきました。(TECHCOMMUNITY.MICROSOFT.COM)
特に重要なのは、外部IDのリスクは「ログイン時」だけで終わらない点です。顧客、取引先、パートナー、委託先、B2Cユーザーは、管理外デバイス・共有端末・個人メール・海外ネットワークからアクセスすることがあります。Microsoft Entra External ID / Conditional Accessのセッション制御は、こうした外部IDに対して、利便性を残しながら高リスクな操作だけを引き締めるための設計要素になります。
Microsoft Entra External IDで何が変わったのか
今回のポイントは、Microsoft Entra External IDの外部テナントで、Conditional Accessのセッション制御としてSign-in frequencyとPersistent browser sessionを使えることです。Microsoft Learnでは、外部テナントで利用できるセッション制御としてこの2つが明記されています。(Microsoft Learn)
| セッション制御 | 何を制御するか | 実務での使いどころ |
|---|---|---|
| Sign-in frequency | ユーザーが再サインインを求められるまでの時間を制御する | 決済情報変更、管理画面、個人情報変更、データエクスポートなどで再認証を求める |
| Persistent browser session | ブラウザを閉じて再度開いた後もサインイン状態を保持するかを制御する | 共有端末、管理外端末、パートナー用ポータルでセッションを残しすぎないようにする |
これまで外部IDの設計では、MFA、サインアップ時の不正対策、アプリ側の認可設計に注目が集まりがちでした。しかし、実際の攻撃ではサインイン後のセッション、Cookie、トークン、放置されたブラウザセッションも狙われます。つまり、認証の成否だけでなく、認証後のセッションをどの条件で維持・更新・終了させるかが重要になります。
session-aware controlsが外部IDで重要になる理由
session-aware controlsを日本語で言い換えるなら、「現在のセッション状態を前提にしたアクセス制御」です。単に「MFAを要求する」「アクセスを許可する」だけではなく、次のような問いに答える設計です。
- このユーザーの認証は、いつ行われたものか
- そのセッションは、まだ信頼してよい状態か
- ブラウザを閉じた後もサインイン状態を残してよいか
- 高リスク操作の直前に、もう一度本人確認すべきか
- 顧客体験を壊さずに、どこまでセッションを短くできるか
外部向けID基盤では、この考え方が特に重要です。社内ユーザーであれば、管理デバイス、端末準拠、MDM、EDR、社内ネットワークなどの補助的な信頼材料を使いやすい一方、外部ユーザーではそれらを前提にできないことが多いからです。
たとえば、顧客向けWebアプリで一度サインインしたユーザーが、数週間後に同じブラウザから支払い方法を変更できる状態だとします。ユーザー体験としては便利ですが、その端末を家族と共有している、ブラウザプロファイルが漏えいした、端末がマルウェア感染している、といったケースではリスクが高まります。ここでSign-in frequencyやPersistent browser sessionを組み合わせると、「通常閲覧はスムーズに、危険度の高い操作では再確認」という設計に近づけます。
外部IDで想定すべきリスクは「入口」だけではない
MicrosoftのExternal ID向けセキュリティ資料では、外部向けIDシステムはcredential stuffing、ボットによるサインアップ、アカウント乗っ取り、大量トラフィックなどの攻撃パターンの標的になりやすいと説明されています。また、対策はWAFやボット対策、MFA、Conditional Access、アプリ側の認可、監視を組み合わせる多層防御として整理されています。(Microsoft Learn)
ここで見落としやすいのが、Conditional Accessを「サインイン時の門番」としてだけ扱ってしまうことです。外部IDのリスクは、少なくとも次の3段階で考える必要があります。
| 段階 | 主なリスク | 必要な対策の例 |
|---|---|---|
| サインアップ前後 | ボット登録、なりすまし登録、不正な大量登録 | WAF、ボット対策、サインアップ不正検知、メール確認 |
| サインイン時 | 盗まれたパスワード、フィッシング、異常な場所からのアクセス | MFA、Conditional Access、場所条件、ブロックポリシー |
| サインイン後 | セッション乗っ取り、共有端末での残存セッション、重要操作の悪用 | Sign-in frequency、Persistent browser session、アプリ側の再認証、ログ監視 |
今回の更新が設計上重要なのは、3段階目の「サインイン後」をConditional Accessの設計に組み込みやすくなる点です。外部ID基盤では、サインインできたからといって、すべての操作を同じ信頼度で許可すべきではありません。
Sign-in frequencyは「再認証のタイミング」を決める制御
Sign-in frequencyは、ユーザーがリソースへアクセスする際、どのくらいの期間サインイン状態を維持できるかを制御する設定です。管理者は時間または日数を指定でき、必要に応じて毎回の再認証も選択できます。Microsoft Learnでは、OAuth 2.0やOpenID Connectを使うアプリでこの設定が機能することが説明されています。(Microsoft Learn)
実務では、すべての外部ユーザーに短い再認証間隔を強制するのは得策ではありません。たとえば、ニュース閲覧、注文履歴の確認、一般的なプロフィール閲覧のたびに再認証を求めると、ユーザー体験が悪化します。一方で、次のような操作では短いサインイン頻度や再認証を検討すべきです。
- メールアドレスや電話番号の変更
- パスワード変更、MFA設定変更
- 配送先や請求先の変更
- 支払い方法の追加・変更
- 高額注文、送金、払い戻し
- APIキーやシークレットの発行
- 管理者・サポート担当者による顧客データ閲覧
- 個人情報、契約情報、監査ログのエクスポート
重要なのは、Sign-in frequencyを「短ければ安全」と単純に考えないことです。Microsoftのドキュメントでも、再認証を頻繁に求めすぎるとMFA疲れやフィッシングリスクにつながる可能性があるため、毎回再認証を求めるポリシーの対象アプリは限定するよう注意されています。(Microsoft Learn)
Persistent browser sessionは「サインイン状態を残すか」を決める制御
Persistent browser sessionは、ユーザーがブラウザを閉じて再度開いた後もサインイン状態を維持するかを制御します。Microsoft Learnでは、永続的なブラウザセッションにより、ブラウザを閉じて再度開いた後もサインイン状態を維持できると説明されています。(Microsoft Learn)
外部IDでこの設定が重要になるのは、ユーザーの端末管理を組織側で保証できないためです。たとえば、パートナー企業の共有PC、店舗端末、コールセンター端末、家族共用PC、インターネットカフェの端末などでは、ブラウザにセッションが残ること自体がリスクになります。
一方で、一般消費者向けアプリでは、毎回サインインを要求すると離脱率が高まる可能性があります。そのため、Persistent browser sessionは「常に無効」ではなく、ユーザー種別・アプリ・操作の重要度・端末の性質で分けるのが現実的です。
| 対象 | 推奨される考え方 |
|---|---|
| 一般的な顧客向け閲覧機能 | 利便性を重視し、短すぎるセッション制限は避ける |
| 支払い、個人情報変更、アカウント復旧 | セッションが古い場合は再認証を求める |
| 管理者、サポート担当者、委託先オペレーター | Persistent browser sessionを残さない設計を優先する |
| 共有端末・キオスク端末 | サインアウト、短いセッション、アプリ側のセッション破棄を組み合わせる |
高リスク操作では「ログイン済み」だけを信頼しない
Customer identity teamsが特に見直すべきなのは、高リスク操作の直前です。たとえば、ユーザーが2週間前にサインインした状態のまま、今日になって支払い方法を変更するケースを考えます。このとき「ログイン済みだから許可」で処理すると、セッション盗用や共有端末のリスクを見逃します。
より安全な設計では、アプリ側で操作の重要度を分類し、必要に応じてMicrosoft Entra External IDのセッション制御やアプリ側の再認証要求と組み合わせます。OpenID ConnectやSAMLアプリでは、アプリが認証要求のパラメーターによってユーザーに再認証を促す設計もあります。Microsoft Learnでは、セッションの無効化や再認証が必要になる要因として、セッション期限、Cookieやキャッシュの削除、Conditional Accessポリシー、セッション失効、疑わしいアクティビティなどが挙げられています。(Microsoft Learn)
実務では、次のように分けると設計しやすくなります。
| 操作の種類 | 例 | セッション設計の目安 |
|---|---|---|
| 低リスク操作 | 商品閲覧、ヘルプ閲覧、通知確認 | 長めのセッションでも許容しやすい |
| 中リスク操作 | プロフィール編集、配送先変更、サブスクリプション変更 | セッション年齢を確認し、一定時間を超えたら再認証 |
| 高リスク操作 | 支払い方法変更、MFA設定変更、データエクスポート、管理者操作 | 短いSign-in frequency、再認証、永続セッション抑制を検討 |
| 不正影響が大きい操作 | 返金、送金、権限昇格、APIキー発行 | アプリ側の承認フロー、監査ログ、アラートも併用 |
Security architectsがまず見直すべき設計ポイント
Microsoft Entra External ID / Conditional Accessのセッション制御は、単体で完結する機能ではありません。設計時には、認証、認可、セッション、監視、ユーザー体験をまとめて見る必要があります。
外部テナントとworkforce tenantを混同しない
Microsoft Entra External IDには、従業員や社内リソース向けのworkforce tenantでB2B collaborationを使うパターンと、顧客やビジネス顧客向けアプリを公開するexternal tenantのパターンがあります。Microsoft Learnでも、workforce tenantは従業員・社内アプリ・組織リソース向け、external tenantは消費者やビジネス顧客にアプリを公開するExternal IDシナリオ向けと整理されています。(Microsoft Learn)
同じ「外部ID」でも、B2BゲストとCIAM向け顧客アカウントでは、期待されるユーザー体験が異なります。B2Bではセキュリティ要件を強く出しやすい一方、B2Cや顧客向けアプリでは再認証の多さが離脱に直結します。ポリシーをコピーして使い回すのではなく、テナント種別とユーザー体験ごとに設計を分けるべきです。
条件と制御の対応範囲を確認する
外部テナントのConditional Accessでは、利用できる条件や制御がworkforce tenantと完全に同じとは限りません。Microsoft Learnの機能比較では、外部テナントのConditional Accessで利用できる要素として、場所、デバイスプラットフォーム、MFA、セッション制御などが整理され、セッション制御としてSign-in frequencyとPersistent browser sessionが示されています。(Microsoft Learn)
そのため、設計時には「社内Entra IDで使っているConditional Access設計をそのまま外部テナントに移植できる」と考えないことが重要です。特に、デバイス準拠、リスク検知、ID Protection、利用可能な認証方式、アプリ登録方式は、テナント種別やライセンス、プレビュー状態によって確認が必要です。
ID Protectionがない前提のリスク設計を考える
外部テナントでは、Microsoft Entra ID Protectionが利用できないとされています。Microsoft Learnの機能比較でも、外部テナントではID Protectionが「Not available」と記載されています。(Microsoft Learn)
これは、外部IDでリスクを見なくてよいという意味ではありません。むしろ、ID Protectionのリスクシグナルに依存しない設計が必要です。たとえば、以下のような代替・補完策を組み合わせます。
- 場所条件によるアクセス制御
- MFAの適用
- 短いSign-in frequency
- Persistent browser sessionの抑制
- アプリ側の不正検知
- WAFやボット対策
- Azure MonitorやMicrosoft Sentinelによるログ監視
- 高リスク操作時の追加確認
導入時の実務手順
セッション制御は、いきなり本番全体に適用するとユーザー体験を壊す可能性があります。以下の順番で進めると、セキュリティとUXのバランスを取りやすくなります。
対象ユーザーとアプリを棚卸しする
まず、誰に対してどのアプリを保護するのかを明確にします。外部IDでは、同じExternal ID環境でもユーザー属性が大きく異なります。
- 一般顧客
- 法人顧客
- 代理店・販売店
- 取引先担当者
- 委託先オペレーター
- サポート担当者
- 外部テナントの管理者
この分類をせずに「外部ユーザー全員」としてポリシーを作ると、低リスクな顧客体験に不要な摩擦を入れたり、逆に管理者操作の保護が弱くなったりします。
操作をリスク別に分類する
次に、アプリ内の操作をリスク別に分類します。セッション制御は、アプリ単位だけでなく、業務や操作の重要度を意識して設計するのが効果的です。
| リスク分類 | 判断基準 | 例 |
|---|---|---|
| 低 | 情報漏えいや金銭被害につながりにくい | 閲覧、検索、通知確認 |
| 中 | アカウント情報や契約情報に影響する | 住所変更、プロフィール編集 |
| 高 | 金銭、権限、本人確認情報に影響する | 支払い方法変更、MFA設定変更、管理者操作 |
| 重大 | 悪用時の被害範囲が大きい | データ一括出力、APIキー発行、返金、権限昇格 |
この分類ができると、「どこで再認証させるべきか」「どこではセッションを長めにしてよいか」が判断しやすくなります。
ポリシーはReport-onlyで検証する
Conditional Accessポリシーは、最初から強制適用するのではなく、検証モードで影響を確認するのが安全です。Microsoft Learnの手順例でも、ポリシー作成時にReport-onlyで確認し、影響を確認した後にOnへ切り替える流れが示されています。(Microsoft Learn)
検証時には、少なくとも以下を確認します。
- 想定したユーザーだけにポリシーが適用されているか
- 顧客やパートナーの通常利用に過剰な再認証が発生していないか
- 管理者や高リスク操作に対して十分に制御できているか
- モバイルアプリ、SPA、Webアプリ、SAMLアプリで挙動差がないか
- ブラウザを閉じた後のセッション保持が期待通りか
- サインインログで適用ポリシーを追跡できるか
失敗しやすいポイント
「短いセッション＝安全」と考えてしまう
短いセッションはリスクを下げる要素になりますが、過度に短い設定はユーザーのストレスを増やします。特にMFAが頻繁に表示されると、ユーザーが確認内容を見ずに承認するようになり、結果としてフィッシング耐性が下がることがあります。
高リスク操作だけを短くし、通常操作は現実的な長さを保つ。これが外部IDでは重要です。
アプリ側のセッションを見落とす
Conditional Accessでセッション制御を設定しても、アプリ側が独自のCookieやセッションを長期間保持している場合、期待した再認証動作にならないことがあります。Sign-in frequencyはOAuth 2.0やOIDCアプリで機能しますが、アプリがどのタイミングでMicrosoft Entraにリダイレクトするかによって、ユーザー体験は変わります。(Microsoft Learn)
アプリ開発チームとは、次の点を必ず確認してください。
- アプリ独自セッションの有効期限
- リフレッシュトークンの扱い
- サインアウト時のCookie削除
- 高リスク操作時の再認証要求
- モバイルアプリとWebアプリの違い
- SAMLアプリでのForceAuthn相当の扱い
共有端末の前提を忘れる
外部ユーザーは、企業管理端末だけでアクセスするとは限りません。店舗PC、共有PC、家族共用PC、委託先端末などからアクセスされる場合、Persistent browser sessionを安易に許可すると、次の利用者が前のユーザーのセッションにアクセスできるリスクが出ます。
共有端末が想定される業務では、アプリ側の自動サインアウト、短いアイドルタイムアウト、明確なサインアウト導線、Persistent browser sessionの抑制を組み合わせてください。
顧客体験とセキュリティを別々に設計する
Customer identity teamsでありがちな失敗は、セキュリティチームが強いポリシーを作り、プロダクトチームが後からUX悪化に気づくパターンです。External IDのセッション制御は、セキュリティだけでなく、コンバージョン、離脱率、問い合わせ件数にも影響します。
そのため、導入前に次の指標を決めておくと運用しやすくなります。
- 再認証発生率
- MFA失敗率
- サインイン完了率
- 高リスク操作の完了率
- サポート問い合わせ件数
- 不審なサインインやセッション失効の件数
- 国・地域・デバイス別の失敗傾向
すぐに取るべきアクション
Microsoft Entra External ID / Conditional Accessの今回の更新を受けて、Security architectsとcustomer identity teamsは、まず既存設計を次の観点で見直すべきです。
| 確認項目 | 具体的なアクション |
|---|---|
| 外部テナントの有無 | 顧客向け、パートナー向け、管理者向けのExternal ID利用箇所を洗い出す |
| 高リスク操作 | 支払い、個人情報、権限、APIキー、データ出力に関わる操作を一覧化する |
| 現在のセッション設定 | アプリ独自セッション、Cookie、トークン、有効期限を確認する |
| Conditional Accessポリシー | Sign-in frequencyとPersistent browser sessionの適用候補を決める |
| ユーザー体験 | 再認証が発生しても許容されるタイミングをプロダクト側と合意する |
| 検証方法 | Report-only、テストユーザー、サインインログで影響を確認する |
| 監視 | Azure Monitor、Microsoft Sentinel、アプリログを組み合わせて異常を追跡する |
最初の一歩としては、すべてのユーザーに強い制限を入れるのではなく、管理者、サポート担当者、高リスク操作、共有端末利用の可能性があるシナリオから優先して設計するのが現実的です。
Microsoft Entra External IDのセッション制御は、外部IDのセキュリティを「サインイン時点」から「サインイン後の操作」へ広げるための重要な更新です。まずは外部ユーザーの種類、アプリの重要度、高リスク操作を棚卸しし、Sign-in frequencyとPersistent browser sessionをどこに適用すべきかを整理してください。強い制御を一律にかけるのではなく、危険な操作に絞ってセッションを短くし、通常利用では摩擦を抑えることが、外部IDにおける実用的なゼロトラスト設計につながります。
コメント