Microsoft Entra の Conditional Access を「All resources」対象で運用し、一部のリソースを除外している組織は、baseline scopes の扱いを必ず確認する必要があります。2026年7月1日に更新された Microsoft Learn では、これまで条件付きアクセスの評価から外れる場合があった低権限スコープが、今後はディレクトリアクセスとして評価されるようになることが説明されています。結果として、Visual Studio Code、Azure CLI、独自Webアプリなどで、従来は求められなかった MFA や準拠済みデバイスの要求が発生する可能性があります。(Microsoft Learn)
特に影響を受けやすいのは、「All resources を対象にした Conditional Access ポリシー」と「リソース除外」を組み合わせているテナントです。管理者は、ポリシーの棚卸し、除外アプリの必要性確認、baseline scopes のみを要求するアプリの特定、アプリ側の Conditional Access チャレンジ対応を順に進める必要があります。
今回の更新で変わること
今回の変更は、Microsoft Entra ID の Conditional Access における All resources ポリシーとリソース除外の組み合わせに関するものです。
従来は、All resources を対象にしたポリシーにリソース除外が含まれている場合、openid、profile、User.Read などの baseline scopes が条件付きアクセスの評価から自動的に外れることがありました。更新後は、これらの baseline scopes がディレクトリアクセスとして扱われ、Conditional Access の評価対象になります。(Microsoft Learn)
つまり、これまで「除外しているアプリだから MFA が出ない」「低権限スコープだけだから条件付きアクセスの影響を受けない」と見えていたサインインでも、ポリシーの条件に一致すれば MFA、準拠済みデバイス、アプリ保護ポリシー、ブロック制御などが適用される可能性があります。
変更前後の考え方
| 観点 | 変更前 | 変更後 |
|---|---|---|
| baseline scopes の扱い | All resources ポリシーにリソース除外がある場合、評価から外れるケースがあった | ディレクトリアクセスとして評価され、Conditional Access の対象になる |
| ユーザー体験 | MFA やデバイス準拠チェックが出ないことがあった | ポリシー設定に応じて MFA などのチャレンジが出る |
| 管理者の確認ポイント | リソース除外を設定していれば想定どおり動くと判断しがち | 除外アプリ、要求スコープ、サインインログを確認する必要がある |
| 推奨対応 | 例外運用を継続 | 新しい強制適用モデルへ移行し、必要な例外だけを限定的に残す |
この変更は、セキュリティ強化の観点では妥当です。User.Read などは低権限に見えますが、ユーザー情報やディレクトリ情報へのアクセスに関係します。認証時の基本情報取得で使われるスコープであっても、組織の条件付きアクセス方針から完全に外してよいとは限りません。
baseline scopes とは何か
Microsoft Learn では、baseline scopes を OIDC スコープと baseline directory scopes の総称として説明しています。対象となるスコープは次のとおりです。(Microsoft Learn)
| 種類 | 対象スコープ | 主な用途 |
|---|---|---|
| OIDC スコープ | email, offline_access, openid, profile | サインイン、IDトークン、基本プロフィール情報の取得 |
| baseline directory scopes | User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden | ユーザー情報、人物情報、グループメンバーシップなどの取得 |
実務上は、openid や profile はログイン処理でよく使われます。User.Read も「サインインしたユーザーの基本情報を取得するだけ」と考えられがちです。しかし、今回の更新では、こうしたスコープだけを要求するサインインも Conditional Access の観点で見直されます。
影響を受けるテナント
影響を受けるのは、次の条件をすべて満たすテナントです。
| 確認項目 | 影響の有無 |
|---|---|
| Conditional Access ポリシーで All resources を対象にしている | 該当する場合は確認が必要 |
| そのポリシーに 1つ以上のリソース除外がある | 該当する場合は影響を受ける可能性が高い |
| ユーザーが baseline scopes のみを要求するアプリでサインインしている | 該当アプリで MFA などが新たに発生する可能性がある |
一方で、All resources を対象にしていてもリソース除外がないポリシーは、この変更の影響を受けないとされています。また、Mail.Read や Files.Read など baseline scopes 以外のスコープを要求するアプリは、すでに該当リソースに基づいて Conditional Access の評価を受けているため、今回の変更による挙動差は基本的にありません。(Microsoft Learn)
影響が出やすいアプリの例
Microsoft Learn では、次のような例が挙げられています。(Microsoft Learn)
| アプリ・シナリオ | 要求スコープ例 | 変更後に起こり得ること |
|---|---|---|
| Visual Studio Code デスクトップクライアント | openid, profile | MFA などの Conditional Access チャレンジが表示される可能性 |
| Azure CLI | User.Read | 従来は通っていたサインインで MFA が必要になる可能性 |
| 除外対象にしている独自Webアプリ | User.Read, People.Read | 除外しているつもりでも、ディレクトリアクセスとして評価される可能性 |
Files.Read や Mail.Read なども要求するアプリ | baseline scopes 以外を含む | 既存のリソースベース評価が継続し、今回の変更による新たな差分は限定的 |
ここで重要なのは、Conditional Access は「クライアントアプリそのもの」ではなく、アクセス先のリソースに対して適用されるという点です。Microsoft Learn でも、パブリッククライアントアプリはアプリピッカーで直接選ぶ対象ではなく、クライアントが呼び出すサービスに基づいてポリシーが適用されると説明されています。(Microsoft Learn)
ロールアウト時期と移行期限の考え方
公式情報では、この baseline scopes enforcement のロールアウトは 2026年6月15日から開始され、数週間かけて段階的に展開されるとされています。ページ自体は 2026年7月1日に更新されています。(Microsoft Learn)
明確な「この日までに必ず移行完了」という固定期限が示されているわけではありません。ただし、何も設定を変更していないテナントでは、ロールアウトの一環として新しい強制適用モデルが自動的に有効になります。管理者が Disable enforcement または Customize behavior を選んでいる場合、その構成は継続され、ロールアウトによって上書きされないと説明されています。(Microsoft Learn)
実務上は、固定期限がないから後回しにするのではなく、段階的展開期間中に次の確認を終えることが重要です。
| 優先度 | 対応 | 理由 |
|---|---|---|
| 高 | All resources + リソース除外のポリシーを洗い出す | 影響条件に直接該当するため |
| 高 | baseline scopes のみを要求するアプリを特定する | MFA やデバイス準拠チェックの新規発生を予測するため |
| 高 | 業務影響があるアプリの所有者を確認する | 自社開発、部門管理、ISV製品で対応方法が異なるため |
| 中 | 例外が必要なポリシーを最小限に絞る | テナント全体の無効化を避けるため |
| 中 | ヘルプデスク向けに想定問い合わせを共有する | 「急に MFA が出る」「CLI ログインが失敗する」などに備えるため |
管理者が確認すべきポイント
All resources ポリシーと除外設定を棚卸しする
最初に確認すべきなのは、Conditional Access ポリシーの対象リソースです。
Microsoft Entra 管理センターで Conditional Access ポリシーを確認し、次の条件に当てはまるものを抽出します。
| 確認する場所 | 見るべき内容 |
|---|---|
| Assignments | Target resources が All resources になっているか |
| Exclude | 特定のリソースやアプリを除外しているか |
| Access controls | MFA、準拠済みデバイス、アプリ保護、ブロックなど何を要求しているか |
| Users | 全ユーザー、管理者、特定グループなど対象範囲はどこか |
| Conditions | デバイス、場所、クライアントアプリ条件などがあるか |
特に注意したいのは、「一部の業務アプリを除外するために All resources ポリシーへ除外を追加した」ケースです。運用上はよくある構成ですが、今回の変更ではこの構成が影響条件に入ります。
除外が本当に必要かを見直す
リソース除外は、便利な一方でセキュリティ上の穴になりやすい設定です。今回の更新では、除外そのものをすぐ廃止する必要はありませんが、少なくとも次の観点で見直すべきです。
| 判断基準 | 見直しのポイント |
|---|---|
| 除外理由が現在も有効か | 過去の障害回避や一時対応が残っていないか |
| 代替策があるか | アプリ側修正、OIDC スコープへの変更、ポリシー分割で対応できないか |
| 対象範囲が広すぎないか | 全ユーザーではなく特定グループに限定できないか |
| セキュリティ要件と矛盾しないか | 管理者、特権操作、外部ネットワークからのアクセスが過度に緩くないか |
| 所有者が明確か | アプリ担当者、ISV、運用責任者が分かるか |
「動かなくなると困るから除外する」だけでは、後から原因不明の抜け道になります。除外を残す場合も、対象アプリ、対象ユーザー、理由、見直し日を記録しておくことが重要です。
baseline scopes のみを要求するアプリを特定する
影響調査では、サインインログを使って baseline scopes のみを要求するアプリを確認します。公式ドキュメントでは、Baseline scopes settings でカスタムターゲットリソースを使い、サインインログの Conditional Access audience から影響アプリを確認する方法が案内されています。(Microsoft Learn)
Microsoft Graph のクエリ例は次のような形です。日付範囲と <your-custom-app-id> は、自社環境に合わせて変更します。
GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-07-01T00:00:00Z and createdDateTime lt 2026-07-02T00:00:00Z and conditionalAccessAudiences/any(a:a eq '<your-custom-app-id>')&$select=createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatus1日分だけでは、月次処理、開発者ツール、管理スクリプト、部門アプリを見落とす可能性があります。少なくとも数日から数週間分を確認し、平日、月末月初、定期バッチの実行日を含めて見ると、影響範囲を把握しやすくなります。
アプリが Conditional Access チャレンジを処理できるか確認する
自社開発アプリや古い業務アプリでは、MFA などの追加認証が求められたときに、アプリ側が適切に処理できない場合があります。
Microsoft の開発者向けガイダンスでは、アプリが Conditional Access ポリシーの対象サービスへアクセスすると、claims パラメーターを含むチャレンジが返ることがあり、アプリはそれを使って再認証や対話的なトークン取得を行う必要があると説明されています。(Microsoft Learn)
確認すべき観点は次のとおりです。
| 対象 | 確認内容 |
|---|---|
| デスクトップアプリ | MFA 要求時に対話的サインインへ誘導できるか |
| Webアプリ | サインイン途中で interaction_required が返った場合に再認証できるか |
| SPA | acquireTokenSilent() 失敗時に acquireTokenPopup() または acquireTokenRedirect() へフォールバックできるか |
| バックエンド連携 | on-behalf-of flow で返った claims challenge をクライアントへ戻せるか |
| CLI・自動化 | 非対話実行に依存していないか、管理者の運用手順に影響しないか |
特に、古い実装で「サイレントにトークンを取れること」を前提にしているアプリは注意が必要です。MFA やデバイス準拠の要求が追加されると、トークン取得に失敗し、ユーザーには単なるログインエラーとして見えることがあります。
設定変更の選択肢
Microsoft Learn では、baseline scopes の強制適用について、管理者が選べる設定として Enable enforcement、Customize behavior、Disable enforcement が説明されています。(Microsoft Learn)
| 選択肢 | 使う場面 | 注意点 |
|---|---|---|
| Enable enforcement | 新しい強制適用モデルをすぐ有効化したい場合 | 即時に動作が変わるため、まずテストテナントや影響調査が必要 |
| Customize behavior | 特定ポリシーだけ旧動作を残したい場合 | 例外を最小限にし、理由を明確にする |
| Disable enforcement | テナント全体で一時的に強制適用を無効化したい場合 | Microsoft は非推奨としており、Conditional Access のカバレッジにギャップが生じる可能性がある |
Enable enforcement を選ぶ場合
Enable enforcement は、改善された強制適用モデルを有効にする推奨設定です。Microsoft Learn では、テストテナントでアプリとユーザーへの影響を確認する用途にも触れています。設定には Conditional Access Administrator 以上の権限が必要です。(Microsoft Learn)
実施前には、少なくとも次の準備を済ませておきます。
| 事前準備 | 理由 |
|---|---|
| All resources + 除外ありのポリシーを把握する | 影響対象を特定するため |
| 開発者・管理者が使うツールを確認する | VS Code、Azure CLI などで影響が出やすいため |
| 主要アプリのサインインテストを行う | MFA やデバイス準拠チェックに耐えられるか確認するため |
| ヘルプデスクに想定事象を共有する | 問い合わせ増加に備えるため |
| ロールバック判断を決める | 問題発生時に Disable enforcement や Customize behavior を検討できるようにするため |
Customize behavior を選ぶ場合
Customize behavior は、テナント全体ではなく、特定のポリシーだけ旧動作を残すための選択肢です。Microsoft Learn では、カスタムアプリケーションを baseline scopes のターゲットリソースとして使い、そのアプリを該当ポリシーから除外することで、特定ポリシーに限って従来動作を維持する方法が説明されています。(Microsoft Learn)
この方法を使うべきなのは、次のような明確な業務要件がある場合に限るのが安全です。
| 例外が必要になりやすい場面 | 検討すべきこと |
|---|---|
| 準拠済みデバイスを要求するポリシーがあり、一部アプリを非管理デバイスから使う必要がある | 本当に非管理デバイスが必要か、対象ユーザーを限定できるか |
| Intune SDK に対応していないアプリでアプリ保護ポリシーを満たせない | アプリ更新、代替アプリ、対象範囲の分離を検討する |
| ブロックポリシーから特定アプリを除外する必要がある | ブロックの目的と例外理由が矛盾していないか確認する |
| パブリッククライアントを準拠済みデバイス要件から外す必要がある | 開発者・管理者ツールだけに限定できるか確認する |
Customize behavior は、例外を作るための機能です。恒久的な抜け道として使うのではなく、「どのアプリを、なぜ、いつまで例外にするか」を管理台帳に残すべきです。
Disable enforcement は最後の手段にする
Disable enforcement は、テナント全体で強制適用を無効にする選択肢です。ただし、Microsoft Learn では非推奨とされており、テナント全体の Conditional Access カバレッジにギャップを作る可能性があると説明されています。(Microsoft Learn)
一部のアプリだけが問題になっている場合、テナント全体を無効化するのは過剰対応です。まずは Customize behavior、アプリ修正、OIDC スコープへの変更、ポリシー分割などを検討した方が安全です。
アプリ所有者別の対応方針
影響調査では、アプリが自社所有か、ISV提供か、Microsoft 製クライアントかによって対応が変わります。
| アプリの種類 | 対応方針 |
|---|---|
| 自社開発のパブリッククライアント | Conditional Access チャレンジに対応できるか確認し、必要に応じて MSAL の対話的認証へフォールバックする |
| 自社開発の confidential client | User.Read などの directory scopes が本当に必要か見直し、基本情報取得だけなら OIDC スコープで代替できないか検討する |
| ISV製アプリ | baseline scopes のみを要求しているか、OIDC スコープへ変更可能か、Conditional Access チャレンジ対応済みかをベンダーに確認する |
| 開発者・管理者ツール | Azure CLI、VS Code などで MFA や準拠済みデバイス要求が出た場合の運用手順を整備する |
重要なのは、アプリごとに「除外を残す」のではなく、「なぜ baseline scopes のみなのか」「なぜ Conditional Access チャレンジに対応できないのか」を確認することです。不要な directory scopes を OIDC スコープへ置き換えられるなら、セキュリティとユーザー体験の両方を改善できます。
失敗しやすいポイント
リソース除外を「アプリ全体の完全除外」と誤解する
Conditional Access は基本的にリソースに対して評価されます。パブリッククライアントアプリ自体に直接ポリシーを適用するのではなく、そのクライアントが要求するリソースに基づいて評価されます。(Microsoft Learn)
そのため、「このアプリを除外しているから、関連するすべてのサインインが従来どおり」と考えるのは危険です。要求スコープやアクセス先リソースによって評価結果が変わります。
User.Read を軽く見すぎる
User.Read は多くのアプリで使われる基本的な権限ですが、ディレクトリ情報へのアクセスに関係します。今回の更新は、こうした低権限スコープも Conditional Access の保護対象として扱う方向への変更です。
「低権限だから無条件で許可してよい」ではなく、「組織のアクセス制御方針に照らして、どの条件で許可するか」を決める必要があります。
開発者ツールの影響を見落とす
Azure CLI や Visual Studio Code は、開発者や管理者の業務に直結します。ここで MFA やデバイス準拠チェックが新たに発生すると、CI/CD、スクリプト実行、緊急対応手順に影響する場合があります。
特に、手元の端末では問題なくても、踏み台端末、VDI、非管理端末、海外拠点の端末では条件が変わることがあります。管理者ロールを持つユーザーだけでなく、開発者、運用担当、委託先の利用パターンも確認すべきです。
テナント全体の Disable enforcement で急場をしのぐ
一部のアプリが失敗したときに、テナント全体で Disable enforcement を選ぶと、影響は止められてもセキュリティカバレッジに穴が残ります。
障害対応として一時的に検討する場合でも、次の条件を満たすべきです。
| 確認項目 | 内容 |
|---|---|
| 影響アプリが特定できているか | 不明なまま全体無効化しない |
| 代替策を検討したか | Customize behavior、アプリ修正、スコープ変更を比較する |
| 期限を決めたか | 無期限の例外にしない |
| 承認者を明確にしたか | セキュリティ責任者や運用責任者の判断を残す |
| 監視方法があるか | サインインログ、失敗ログ、問い合わせ件数を見る |
実務での確認手順
管理者は、次の順序で進めると影響を整理しやすくなります。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | Conditional Access ポリシーを棚卸しする | All resources + 除外ありのポリシー一覧 |
| 2 | 除外リソースを確認する | 除外理由、所有者、対象ユーザーの一覧 |
| 3 | baseline scopes のみを要求するアプリを調べる | 影響候補アプリの一覧 |
| 4 | 重要アプリをテストする | MFA、デバイス準拠、ブロックの発生有無 |
| 5 | アプリ所有者・ISVへ確認する | 改修可否、OIDC スコープ化可否、対応予定 |
| 6 | Enable / Customize / Disable を判断する | テナントまたはポリシー単位の設定方針 |
| 7 | ロールアウト後に監視する | サインイン失敗、MFA増加、問い合わせ傾向 |
最初から全アプリを完璧に調べようとすると時間がかかります。まずは、All resources ポリシーの除外設定に該当するアプリ、管理者・開発者が使うツール、認証エラーが業務停止につながるアプリから優先的に確認するのが現実的です。
まとめ：まずは「All resources + 除外」の棚卸しから始める
今回の Microsoft Entra Conditional Access の更新は、baseline scopes をディレクトリアクセスとしてより厳密に評価する変更です。対象はすべてのテナントではありませんが、All resources ポリシーにリソース除外を設定している組織では、サインイン時の MFA やデバイス準拠チェックが新たに発生する可能性があります。
管理者がすぐに行うべきことは、次の4つです。
- All resources を対象にし、リソース除外を含む Conditional Access ポリシーを洗い出す
openid、profile、User.Readなど baseline scopes のみを要求するアプリを特定する- 自社開発アプリや ISV製アプリが Conditional Access チャレンジに対応できるか確認する
- 原則は Enable enforcement を前提にし、必要な例外だけ Customize behavior で限定的に扱う
この変更は、単なる仕様変更ではなく、例外設定に埋もれていたディレクトリアクセスを可視化し、条件付きアクセスの防御範囲を整える機会です。まずはポリシーと除外の棚卸しを行い、影響アプリ、業務影響、例外方針を明確にしてから設定変更を進めるのが安全です。
コメント