【ITニュース解説】Conditional Access baseline for Entra ID: naming, pilot groups, report-only, Insights, break-glass and rollout waves

Conditional Access（条件付きアクセス、CA）は、Microsoft 365環境におけるセキュリティ設定の中でも特に強力な機能だが、設定を誤るとシステム全体が使えなくなる恐れがある。例えば、すべてのユーザーとすべてのクラウドアプリに適用されるポリシーを安易に有効にすると、多くのユーザーがOutlookにアクセスできなくなる事態が発生しかねない。このような問題は、設定そのものよりも、命名規則の欠如、パイロットグループの不使用、レポートオンリーモードの不適切な運用、緊急アクセス手段の不足など、展開プロセスに起因することが多い。この解説では、そうした事態を避けるためのConditional Access導入の基本手順と注意点を説明する。

Conditional Accessの主な役割は、クラウドアプリへのサインインを評価し、誰が、どのアプリに、どのデバイスから、どこから、どの程度の危険度でアクセスしようとしているかを判断することである。その評価に基づいて、アクセスを許可するか、多要素認証（MFA）や準拠デバイスの使用を要求するか、あるいはアクセスを完全にブロックするかを決定する。しかし、CAはデバイス自体の設定を行うわけではなく、Intuneなどの別のツールが管理するデバイスの準拠状態を「信号」として読み取るだけだ。また、MFA登録プロセスに問題がある場合でも、CAがそれを修正するのではなく、問題があることを明確にするだけである。オンプレミスのファイル共有など、Entra IDのサインインに関与しないものにはCAは適用されない点も理解しておく必要がある。例えば、準拠デバイスを要求するポリシーを導入するなら、まずIntuneでのデバイス準拠状態が正しく機能していることを確認しなければ、CAは単なるアクセス障害の原因となる。

Conditional Accessを設計する前に、いくつかの前提条件を確認する必要がある。まずライセンスだが、CAを利用するには、ポリシーの対象となるすべてのユーザーに対してMicrosoft Entra ID P1ライセンスが必要となる。これはMicrosoft 365 Business PremiumやE3/E5スイートに含まれている。サインインリスクやユーザーリスクに基づいた条件を利用するにはP2ライセンスが必要だが、基本ポリシーはP1で構築し、リスクベースのポリシーは後でアップグレードする形で問題ない。もし現在「セキュリティの既定値群」が有効になっている場合は、CAを使うためにそれを無効にする必要があるため、MFAを強制する代替ポリシーを事前に計画し、セキュリティの穴が生じないように注意が必要だ。次に、適切な管理ロールの割り当てが重要となる。日常的なCAポリシーの作成や編集作業には「条件付きアクセス管理者」ロールで十分であり、グローバル管理者の権限は必要ない。ポリシーの閲覧やログの確認には「セキュリティ閲覧者」または「グローバル閲覧者」で対応できる。ただし、緊急時の復旧作業に備えて、後述するブレークグラスアカウントにはグローバル管理者を割り当てておく。最後に、既存のCAポリシーを把握する棚卸しも不可欠だ。過去に設定されたポリシーやMicrosoftが提供する管理ポリシーなど、すでに稼働しているCAポリシーがないか確認し、その状態（オン、レポートオンリー、オフ）、適用対象、許可内容を記録する。これらの情報をCSV形式でエクスポートしておくと、変更管理の際に「変更前」の状態として役立つ。説明できない「オン」状態のポリシーがあれば、新しいポリシーを追加する前に内容を確認すべきだ。

複数のポリシーを効率的に管理するためには、明確な命名規則が不可欠である。インシデント発生時など緊急時に、何十ものポリシーの中から必要なものを見つけ出すためには、「MFA」「テスト」のような曖昧な名前では役に立たない。ポリシー名には「CA - <対象> - <制御内容> - <アプリ/範囲> - <フェーズ> - v<バージョン番号>」といった構造化された形式を採用すると良い。これにより、ポリシーの目的や状態が一目で分かり、フィルタリングやソートもしやすくなる。例えば「CA - AllUsers - Require MFA - O365 - ReportOnly - v1」のように、対象ユーザー、要求される制御、対象アプリ、現在のフェーズ、バージョンが明確にわかるようにする。また、Descriptionフィールドに所有者、チケット番号、最終確認日、注意事項などを記録することも有効だ。ポリシーの変更履歴を追跡しやすくするため、許可内容や適用範囲が変更された際にはバージョン番号を更新する習慣をつけることが推奨される。関連するグループ名も同様に「CA-Pilot-Wave0」のように命名し、特に除外グループには有効期限を名前に含めることで、忘れ去られることを防ぐ。

新しいポリシーを導入する際には、本番環境に全面適用する前に「パイロットグループ」で検証することが極めて重要だ。パイロットグループは、現実的なシナリオを反映できるよう、IT担当者だけでなく、経理担当者、営業担当者、役員秘書など、異なる役割や働き方を持つ5〜15人で構成することが望ましい。また、Windows、Mac、モバイルデバイスなど、様々な種類のデバイスを使用するメンバーを含め、意図的に非準拠デバイスも加えて失敗時の挙動を確認することも有効である。パイロットに参加するメンバーには、変更内容、スケジュール、問題発生時の連絡先を事前に伝える必要がある。ポリシーの適用範囲は、まずこのパイロットグループに限定し、ブレークグラスアカウントは常に除外する。準拠デバイスの要求やブロックといった厳しい制御は、最初から「すべてのクラウドアプリ」に適用せず、Office 365などの特定のアプリから開始し、後から徐々に範囲を広げることが安全な進め方だ。

「レポートオンリーモード」は、Conditional Accessの最も有用な機能の一つであり、その正しい使い方が成功の鍵を握る。このモードでは、ポリシーがサインインを評価し、結果をログに記録するが、実際のアクセスはブロックしたり追加認証を要求したりせず、何も強制しない。ログには「レポートオンリー: 成功」「レポートオンリー: 失敗」「レポートオンリー: ユーザー操作が必要」といった結果が記録される。ポリシーを「レポートオンリー」で作成したら、最低でも3〜5営業日、可能であれば月末処理が含まれる期間も加えて運用し、結果を毎日レビューする必要がある。レポートオンリーモードで記録された「失敗」は、ユーザーが実際にMFAを登録していない、デバイスが非準拠であるといった「期待通りの失敗」と、サービスアカウントが意図せずブロックされる、含まれるべきではないゲストがヒットするなど「バグによる失敗」に分類する。「期待通りの失敗」はユーザー側の準備不足を示しており、ポリシーを弱める理由にはならない。「バグによる失敗」であれば、ポリシーの割り当てを修正する必要がある。ポリシーを本番適用する前に、「パイロットユーザーの95%以上がMFAを登録済みであること」「3日間連続で説明不能なレポートオンリー失敗がゼロであること」といった明確な基準を設定し、その基準を満たしてから次のステップに進むべきだ。

ポリシーの動作を確認し、問題を特定するためには、複数のツールを活用する。まず「What If」ツールは、ポリシー変更の前後で特定のユーザーや状況をシミュレーションし、期待通りの結果が得られるかを確認するために使う。パイロットユーザーが特定のアプリにアクセスする場合、ブレークグラスアカウントの場合、パイロットグループ外のユーザーの場合など、様々なシナリオで「What If」を実行し、もし期待と異なる結果が出た場合は、さらに設定を進める前に割り当てを修正する必要がある。次に「サインインログ」は、特定のユーザーのサインイン履歴を詳細に確認できるツールだ。個別のサインインイベントを開くと、どのCAポリシーが評価され、それが適用されたか、どの制御が成功または失敗したかが表示される。これにより、「なぜこのユーザーはアクセスできなかったのか」といった具体的な状況を正確に把握できる。最後に「Insights and reporting」は、特定のポリシー、または複数のポリシーが、指定した期間にわたって全体としてどのような影響を与えたかを、ユーザー別、アプリ別、結果別に集計して表示する。この機能を利用するには、サインインログをLog Analyticsワークスペースに送信するための診断設定を事前に構成しておく必要がある。レポートオンリー期間中には、このツールで「失敗」や「ユーザー操作が必要」な項目に絞って確認し、異常なパターンがないかをチェックする。もしInsightsで通常業務で「ブロックされるだろう」という結果が多数表示される場合、レポートオンリー期間がどれだけ長くても、まだポリシーを強制する準備ができていないことを意味する。

CAやMFAの設定ミス、その他の問題で管理者がロックアウトされた場合に備え、「ブレークグラスアカウント（緊急アクセスアカウント）」を事前に設定しておくことが極めて重要だ。このアカウントは、通常の管理アカウントとは独立した、クラウド専用のユーザーアカウントであるべきだ。オンプレミスのActive Directoryと同期しない「*.onmicrosoft.com」ドメインのユーザーとして、少なくとも2つ作成し、恒久的に「グローバル管理者」ロールを割り当てる。PIM（Privileged Identity Management）の対象にはしない。そして、最も重要なのは、これらのブレークグラスアカウントをすべてのCAポリシーから常に「除外」することである。専用のグループを作成し、そのグループを各ポリシーの除外リストに加えるのが推奨される。認証方法にはFIDO2セキュリティキーのような強力でフィッシングに強いものを設定し、その資格情報はオフラインで、物理的に安全な場所に保管し、緊急時に複数人が協力してアクセスできるような手順を文書化しておく。ブレークグラスアカウントのサインインはすべてアラートを発生させ、インシデントとして扱われるべきであり、四半期ごとにサインインテストを実施して機能することを確認する。緊急時にCAポリシーを無効にする手順も明確に文書化し、いつでも実行できるようにしておく。ブレークグラスアカウント以外の一時的な除外は、必ず期限付きのグループとして管理し、期限が来たら削除する「除外の衛生管理」を徹底することが、ベースラインの保護を維持する上で不可欠だ。

Conditional Accessの導入を始める際の推奨される初期ポリシーセットがいくつかある。これらは、一つずつパイロット、レポートオンリー、そして強制というプロセスを経て展開するべきだ。まず「管理ロールに対するMFA要求」は、最も機密性の高いアカウントを保護するため、最初に行うべきだ。対象はディレクトリロールに限定し、ブレークグラスアカウントは除外する。次に「レガシー認証のブロック」は、MFAに対応できない古いプロトコルを無効にすることで、セキュリティバイパスを防ぐ。古いOutlookクライアントやIMAP/POPなどに影響が出る可能性がある。そして「すべてのユーザーに対するMFA要求」がセキュリティの中核となる制御であり、MFA登録の不備がないか注意し、未登録者には一時アクセスパスなどで対応する。さらに「ゲストに対するMFA要求」は、B2Bアカウントのセキュリティを強化するために重要だ。最後に「準拠デバイスの要求」は、管理された健全なデバイスからのみデータにアクセスさせるためのポリシーだが、これはIntuneの準拠状態に大きく依存するため、最も慎重に進める必要がある。特に、デバイス登録に必要なアプリまでこのポリシーの対象に含めてしまうと、新しいデバイスが準拠状態になれず、登録が完了できなくなる「循環依存性」の問題が発生する可能性があるため、Microsoftの最新ガイダンスに従い、登録関連アプリは除外する設定が重要だ。

ポリシーの展開は、一度にすべてのユーザーに適用するのではなく、「ウェーブ（段階的展開）」を通じて安全に進めるべきだ。パイロットグループでポリシーが問題なく運用できることを確認したら、次のステップとしてIT部門やセキュリティチームに適用し、その後、協力的で影響の少ない部署から順に、残りのスタッフ、そしてゲストやベンダーへと段階的に適用範囲を広げていく。この際、「すべてのユーザー」にポリシーを適用してそこから除外するのではなく、各ウェーブの対象グループをポリシーの「含める」リストに追加していく形が推奨される。各ウェーブの前に、対象ユーザーに「何が変更されるか」「何が見られるか」「ブロックされた場合の対応」を簡潔に通知する。各ウェーブの適用後には、ヘルプデスクの問い合わせ状況とInsightsのデータを少なくとも48時間監視し、問題がないか確認する。緊急時には、事前に合意したロールバック基準（例: 1時間以内に5件以上のロックアウトチケットが発生した場合、そのウェーブグループを削除する）に基づいて、迅速に対応できるよう準備しておく。展開作業は金曜日や祝日前、月末処理期間を避けて行うことが賢明だ。

CAの展開中や運用後には、様々なトラブルシューティングが必要になる。緊急事態が発生しても、組織全体でCAを無効にするのは最終手段とし、まずは影響を受けるユーザーやグループに限定して対応する。問題解決の基本的な手順は、まずエラーメッセージ（特に相関IDやリクエストID）を取得し、そのユーザーのサインインログを開いて「Conditional Access」タブを確認する。どのポリシーが「失敗」しているかを特定し、What Ifツールで状況を再現して原因を特定し、修正を行う。例えば、「詳細情報が必要」といったMFA登録に関するエラーは、ユーザーに有効なMFA方法が設定されていないか、登録がポリシーによってブロックされている可能性が高い。この場合は、一時アクセスパスを発行したり、信頼できるネットワークから登録を完了させたりする。デバイスが準拠していないためにアクセスできない場合は、Intuneのデバイスレコードで準拠状態や最終チェックインを確認し、デバイスの同期を促したり、設定の問題を修正したりする。一時的に緊急性が高い場合は、期限付きの除外グループを適用することも考えられる。Intuneでは準拠しているのにCAでブロックされる場合は、デバイスIDの不一致や、ブラウザがデバイス情報を正しく渡せていない可能性がある。古いOutlookクライアントやIMAP/POPなどのアプリが使えない場合は、レガシー認証がブロックされていることが原因で、モダン認証対応のクライアントへ移行を促すか、一時的な例外グループで対応する。新規デバイスが登録プロセス中にスタックする場合は、準拠デバイスポリシーがデバイス登録に必要なアプリをブロックしている可能性があり、Microsoftのガイダンスに従って登録アプリを除外する必要がある。管理者自身がポータルにロックアウトされた場合は、別の管理者がポリシーをレポートオンリーに変更するか、期限付きの除外を追加し、それができない場合はブレークグラスアカウントで対応する。

Conditional Accessベースラインは一度設定したら終わりではなく、その健全性を維持するための継続的な運用が不可欠である。毎週、InsightsでCAの失敗ログを確認し、レポートオンリーモードで運用中のポリシーに新たな失敗がないかをチェックする。毎月、すべてのポリシーをCSV形式でエクスポートし、前月と比較して意図しない変更がないかを確認する。また、除外グループに期限切れのエントリがないかをレビューし、不要な除外を削除する。四半期ごとには、ブレークグラスアカウントでのサインインテストを実施し、緊急時の無効化手順が機能するかをシミュレーションして確認する。IntuneやID管理に大きな変更があった場合は、影響を受けるデバイスベースのポリシーを短期間レポートオンリーモードに戻して再確認することが推奨される。新しいポリシーを本番環境に「オン」にする前には、命名規則とDescriptionが適切か、適用範囲がパイロットまたはウェーブグループに限定されブレークグラスアカウントが除外されているか、レポートオンリーでの検証とInsightsレビューが完了しているか、What Ifツールでのシミュレーションが検証されているか、問題があれば修正チケットがクローズされているか、ロールバック計画が明確であるかなど、最終チェックリストを必ず確認することが重要である。この継続的な管理と確認のサイクルを通じて、Conditional Accessは組織のセキュリティを確実に保護し続けることができる。