2026.08.21 18:04 (更新: 2026.08.21)

【Entra ID】優先順位がないなら、どう組むか｜後編・条件付きアクセスを要件レイヤーで重ねる

Kaito Yanagihara

クラウドセキュリティアーキテクト

はじめに

こんにちは！Identityチームのkaitoです。先日、人生で初めてプロテイン1kgを最後まで飲み切ることができました。最近のプロテインは美味しいものが増えましたね。ちなみにこの記事は前編の続きとなります！

前編では、Entra ID の条件付きアクセスを GPO とファイアウォールの ACL に読み替えると、どこが同じでどこがズレるかを整理しました。要点だけ振り返ると、こうです。

条件付きアクセスに GPO の last-writer-wins（後勝ち）はない。優先順位という概念そのものがなく、該当したポリシーの制御は全部乗る（ブロックが1つでもあれば即停止）
ACL のような暗黙の deny もない。条件に当てはまらなければ、そのポリシーでは何も起きず素通りする
だから、末尾を締めるのは自分の仕事。「任意のデバイスで受けてブロックする」ポリシーを自分で作る

今回はその続きなので、「優先順位もなく、上書きも起きない。じゃあどうポリシーを切り分けるのか」という設計の話と、実際に触って引っかかったポイントを書きます。

優先順位がないなら、要件レイヤーで重ねる

ここが前編を書いていて一番モヤッとしたところでした。優先順位で調整できないなら、どうやって「この人にはここまで、あの人にはもっと強く」を作るんだろう、と。

答えは逆で、優先順位がないことをそのまま活かす組み方でした。アプリごとに1本ずつポリシーを作るのではなく、要件の種類ごとにポリシーを切り出して、重ね合わせで必要な強度に到達させます。

ここでいう「要件レイヤー」はMicrosoftの公式用語ではなく、条件付きアクセスポリシーを目的別に整理するための、この記事独自の呼び方です。

レイヤー	主な対象	制御	主な注意点
① ベースライン	全社員・全アプリ	MFAを要求（種類は問わない）	緊急アクセス用アカウントを除外する
② ロール要件	特権ロール	高強度MFAを要求	Microsoft管理ポリシーで不足するロールを補う
③ アプリ要件	重要アプリのグループ	パスキーを要求	対象アプリを要件ごとにグループ化する
④ デバイス要件	Microsoft Entra参加済みデバイス	フィッシング耐性MFAを要求	認証強度とデバイス信頼を混同しない
⑤ ロックダウン	通したくない認証経路やプラットフォーム	レガシ認証、未サポート／未想定のプラットフォーム、デバイスコードフローをブロック	他の層と重ならず、当たれば即停止する。例外と影響範囲をレポート専用で確認する

一番下のロックダウン層に当たれば即停止。当たらなければ、ベースラインの上にロール要件・アプリ要件・デバイス要件のうち該当したものがANDで重なる

この形が効くのは、まさに優先順位がなく上書きも起きないからです。ベースラインの MFA と、アプリ要件のパスキーは競合しません。両方を満たす必要があるものとして素直に重なります。GPO のように「下位で上書きして緩める」ことはできないので、緩めたい対象は最初から割り当てで除外しておくしかない、という点だけ気をつければ設計はむしろシンプルでした。

表に挙げた5つのうち、①・④・⑤には先に知っておきたい前提があります。順に補足します。

まず①ベースラインは、自分で作る前に確認しておきたいことがあります。前編で触れたMicrosoft 管理の条件付きアクセスポリシーには「すべてのユーザーへの MFA 要求」が含まれるので、このポリシーが入っているテナントでは、①を自作すると同じ要求のポリシーが2本になります。管理ポリシーはレポート専用のままの場合、テナントへ導入されてから30日以内に有効になります。有効化の約2週間前にはメールとメッセージセンターで通知され、ケースによっては30日より前に有効化される場合もあります。通知や導入日を確認していないと、自分で作った覚えのない MFA 要求が後から効いてくることになります。表の②ロール要件に書いた「Microsoft 管理ポリシーで不足する分を補う」という考え方は、①にもそのまま当てはまります。

次に④デバイス要件は、読み方を間違えると逆になるので補足しておきます。認証強度が縛るのは認証方法であって、デバイスの信頼ではありません。Windows Hello for Business や各プラットフォーム資格情報には、方式ごとに対応 OS、登録、管理方式などの前提があります。一方、FIDO2 セキュリティキーと証明書ベース認証（多要素）は未管理のデバイスでも利用できます。

つまり④は「Microsoft Entra 参加済みデバイスから来たサインインに、強い認証方法を要求する」層であって、デバイス側の信頼を担保する層ではありません。未登録のデバイスから来たサインインは④の割り当てに該当しませんが、②ロール要件や③アプリ要件など、ほかの該当ポリシーは引き続き適用されます。デバイスそのものを条件にしたいなら、「準拠デバイスを要求」や「Microsoft Entra ハイブリッド参加済みデバイスを要求」を別のレイヤーとして足す必要があります。実際の設定では、条件の「デバイスのフィルター」で trustType や isCompliant を使って対象を絞ります。旧「デバイスの状態」条件は非推奨で、デバイスのフィルターとは併用できません。

最後に⑤ロックダウンは、前編で書いた any で受けて例外を切る層です。図では一番下に敷いています。前編で「末尾を締めるのは自分の仕事」と書いたのが、この層です。レガシ認証・未サポート／未想定のプラットフォーム・デバイスコードフローのように「そもそも通したくない経路」は、要件レイヤーとは別に、塞ぐ専用のポリシーとして独立させておきます。暗黙の deny がない仕組みで ACL 的な安心感を作るなら、この層を自分で用意するしかありません。

⑤でブロックする3つは、使う条件がそれぞれ違います。レガシ認証はクライアントアプリの条件、未サポート／未想定のプラットフォームはデバイスプラットフォームの条件で、対象に「任意のデバイス」、対象外に自組織で使う OS（Android / iOS / Windows / macOS / Linux から選ぶ）を並べてブロックします。ここで判定できるのはプラットフォームの種類までで、OS のバージョンや更新状態は見ていません。サポートが切れたバージョンを止めたいという話になると、この条件ではなく Intune のデバイスコンプライアンスポリシー側で評価することになります。デバイスコードフローは「認証フロー」の条件です。こちらは公式のブロック手順があり、まずレポート専用で影響を見てから有効にする流れが案内されています。なお、デバイス登録にデバイスコードフローを使っている場合は、「すべてのリソース」を対象にすると登録まで止まるため、利用実態を確認したうえで Device Registration Service の除外を検討します。

レイヤーを立てるうえで、公式ドキュメントを読んで知った注意点が2つありました。

ひとつは、②ロール要件のレイヤーで指定できるロールが限られていることです。公式ドキュメントに警告として書かれていて、管理単位（administrative unit）スコープのロールやカスタムロールなど、その他のロールの種類はサポートされていませんとあります。つまり、ポリシーの割り当て対象として選べるのは組み込みロールだけです。「特権ロールを守る」つもりでカスタムロールを対象にしようとしても、そのロールは選択肢に出てこないということです。なお、カスタムロールを持つユーザー自身は、ユーザーやグループを指定したポリシーの対象にはなります。

もうひとつ、Microsoft 管理の条件付きアクセスポリシーの「管理者への MFA 要求」は、対象となる14の組み込みロールがMicrosoft管理ポータルへアクセスする際にMFAを要求するポリシーです。全体管理者、アプリケーション管理者、認証管理者、課金管理者、クラウドアプリケーション管理者、条件付きアクセス管理者、Exchange 管理者、ヘルプデスク管理者、パスワード管理者、特権認証管理者、特権ロール管理者、セキュリティ管理者、SharePoint 管理者、ユーザー管理者。この14ロールに Intune 管理者は入っていません。組織によって守りたいロールは違うので、足りない分は自分でポリシーを足す必要がある、というのはこういう話でした。

アプリごとに1本ずつ作らないのには、もうひとつ実務的な理由があります。ポリシー数の上限は1テナントあたり240個（レポート専用・オン・オフを問わず全状態を含む）です。同じページに「アプリを分析し、同じユーザーに対して同じリソース要件を持つアプリをグループ化する」という推奨もあります。ファイアウォールのルールが増えすぎて誰も触れなくなる、あの光景と同じ話ですね。

新しいアプリが増えたときに1本足すのではなく、「これはどの要件レイヤーの話か？」から入る。この癖をつけたいと思いました。

実際に触るなら「レポート専用モード」から

では実機でどう確かめるか。ここで本当にありがたいのがレポート専用モードです。

レポート専用モードは、ほとんどの条件付きアクセスポリシーを有効にする前にテストできるポリシー状態です。サインイン時にポリシーは評価されますが、適用はされません。結果はサインインログの詳細の「条件付きアクセス」タブと「レポート専用」タブに記録されます。ユーザーが MFA を求められることも、ブロックされることもありません。

ただし公式には警告がひとつ添えられていて、準拠デバイスを要求するレポート専用ポリシーは、macOS / iOS / Android のユーザーにデバイス証明書の選択プロンプトを出すことがあります（デバイスコンプライアンスは適用されていないのに、です）。しかもこのプロンプトはデバイスが準拠になるまで繰り返される可能性があるとのこと。回避するには、該当のデバイスプラットフォームをレポート専用ポリシーから除外します。「評価だけ」と油断せず、ここは押さえておきたいところです。

インフラ時代、ファイアウォールのルール変更は結局「入れてみて、通らなくなったら怒られる」という緊張感のある作業でした。それに対して、適用せずに評価結果だけ先に見られるのは正直かなり羨ましい仕組みです。

サインインログの結果は、有効ポリシーとレポート専用ポリシーで意味が異なります。

有効ポリシーの結果

成功：ポリシーが適用され、要件が満たされ、そのポリシーとしてはサインインの続行が許可された。ただし、別のポリシーによってブロックされる可能性はあります
失敗：ポリシーが適用され、要件が満たされなかったため、サインインがブロックされた
未適用：ユーザーが除外されたなどの理由で、ポリシーが適用されなかった

レポート専用ポリシーの結果

レポート専用の結果は、ポリシーを有効化した場合の想定評価です。レポート専用ポリシー自体がサインインをブロックするわけではありません。

レポート専用: 成功：ポリシーを有効化しても、要件を満たしてサインインを続行できる想定
レポート専用: 失敗：ポリシーを有効化すると、要件を満たせずブロックされる想定
レポート専用: ユーザー操作が必要：ポリシーを有効化すると、MFA登録などの追加操作が必要になる想定
レポート専用: 未適用：構成されたポリシー条件をすべて満たしておらず、適用対象にならない想定

「未適用」や「レポート専用: 未適用」がどれくらい出ているかをながめるだけでも、自分が思っていたスコープと実際のスコープのズレが見えてきます。前編で書いた「素通り」を、数字で確かめられるということですね。

なお、レポート専用モードにも制限があり、「ユーザーアクション」スコープに含まれるものは評価できないとされています。

もうひとつ心強いのが、戻す手段が用意されていることです。公式のロールバック手順として、ポリシーの無効化、特定ユーザー／グループの除外、不要なら削除が挙げられています。削除済みポリシーはMicrosoft Learnの手順に沿って、削除から30日以内であれば復元できます。復元ダイアログではレポート専用の状態に戻すことができ、公式もまずその状態で影響を確認することを推奨しています。オンプレの構成変更で「戻すには再起動と数十分」だった経験があるので、トグルひとつで止められるのは素直にありがたいです。ただし逆に言えば即座に効いてしまうということでもあるので、レポート専用モードの価値がより際立ちます。

つまずきそうなポイント

触りながら「これは知らないと引っかかる」と思ったものを挙げておきます。

1. クライアントアプリの条件は、未設定でも「全部」に効く

新しく作成した条件付きアクセスポリシーは、クライアントアプリの条件を構成していなくても、すべてのクライアントアプリの種類に適用されるとドキュメントに明記されています。「設定していない＝効いていない」ではないので、レガシ認証まで巻き込む前提で影響範囲を考える必要があります。

2. グループに入れてもすぐには効かない

ロールまたはグループを対象とするポリシーは、トークンが発行された場合にのみ評価されるという仕様です。そのため、グループに新しく追加されたユーザーは新しいトークンを取得するまでポリシーの対象になりませんし、すでに有効なトークンを持っていた場合は遡及して適用されません。AD でグループを変えて gpupdate /force や再ログオンで反映させていた感覚とは、また少し違う挙動です。

公式には、PIM（Privileged Identity Management）でロールやグループメンバーシップをアクティブ化するタイミングで条件付きアクセスの評価をトリガーするのがベストプラクティス、と書かれていました。

3. デバイスプラットフォームの判定は「確定情報」ではない

前編で「any で受ける」話をしましたが、そもそもプラットフォームの判定自体も過信できません。デバイスプラットフォームの特定に使われる情報は、変更可能なユーザーエージェント文字列など、未確認のソースから取得されるとドキュメントに明記されています。公式も、この条件は Intune のデバイスコンプライアンスポリシーと組み合わせるか、ブロック文の一部として使うように、と書いています。単独で「iOS だけ許可」のような制御の根拠にはしない、ということですね。

4. 「MFA を要求」と「認証強度を要求」は同じポリシーに同居できない

これは知らずに設定しようとして引っかかりました。許可コントロールの「多要素認証を要求」と「認証強度を要求」は、同一のポリシー内で併用できません。理由は明快で、組み込みの「多要素認証」強度が「多要素認証を要求」と等価だから、と公式に説明されています。

認証強度には、多要素認証、パスワードレス MFA、フィッシング耐性 MFA の3種類が組み込みで用意されています。フィッシング耐性 MFA 強度が許可する組み合わせは、Windows Hello for Business（またはプラットフォーム資格情報）、FIDO2 セキュリティキー、証明書ベース認証（多要素）です。さらにカスタムの認証強度も作れて、たとえば「パスキー（FIDO2）だけ」といった指定もできます。要件レイヤーの③④で「パスキーを要求」「フィッシング耐性 MFA を要求」と書いたのは、この認証強度のことです。ここで気をつけたいのが、③で許可する方式が④で許可する方式の部分集合になっている点です。フィッシング耐性 MFA 強度は上の3つの組み合わせを許可しますが、カスタム強度で「パスキー（FIDO2）だけ」に絞れば許可されるのは1つだけです。そのため、③と④の両方に該当したサインインの実効要件はパスキーだけになります。ただし、これは一般に③が④より強いという意味ではありません。許可方式の集合が重ならない複数の認証強度ポリシーが該当する場合は、すべてを満たすために複数の方式でのサインインが必要になることがあります。レイヤーの重複は「どの割り当てに効くか」だけでなく、「どの認証方式の集合を要求しているか」まで点検したほうが確実でした。

ひとつ注意点として、認証強度も第1段階認証そのものは制限しません。フィッシング耐性 MFA 強度を設定していても、ユーザーはパスワードを入力できます。ただしその先に進むにはフィッシング耐性の方法でサインインする必要がある、という挙動です。前編で書いた「条件付きアクセスは第1段階認証の後に適用される」がここにも効いてきます。

5. 緊急アクセス用アカウント（ブレークグラス）の除外を忘れない

これは絶対に外せない話です。公式ガイドでは、組織内に2つ以上の緊急アクセスアカウントを作り、オンプレから同期・フェデレーションされていない .onmicrosoft.com のクラウド専用アカウントにすることが推奨されています。そして、サインインをブロックまたは制限する条件付きアクセスポリシーからは、これらのアカウントを除外します。理由は明快で、MFA や準拠デバイスを要求するポリシーの対象になっていると、まさに緊急時にそのアカウントが使えなくなる可能性があるからです。

ちなみに、レポート専用ポリシーはアクセスをブロックしないため除外は不要とも書かれています。それから、少なくとも90日ごとにアカウントが実際にサインインして管理タスクを実行できるか検証することが推奨されています。「非常用の鍵が本当に回るか、定期的に確かめる」——これはオンプレの世界でも同じですね。

関連して、公式ドキュメントには「ブロック」と「すべてのリソース」を1つのポリシーで組み合わせるときは注意という警告もあります。この組み合わせは管理者を締め出す可能性があり、しかも Microsoft Graph のような重要なエンドポイントには除外を構成できないとのこと。「全部を対象にして全部止める」は、思っているより危険な操作でした。

6. ライセンス要件

条件付きアクセスの利用には Microsoft Entra ID P1 ライセンスが必要です。Microsoft 365 Business Premium ライセンスを持っている場合も条件付きアクセス機能を使えるとされています。また、サインインリスクやユーザーリスクを使うリスクベースのポリシーは、P2 の機能である Microsoft Entra ID Protection が必要です。要件レイヤーを設計する前に、ここは確認しておきたいところです。

（※ライセンス体系や画面の項目は変わりやすいので、実際に設計・構築される際は必ず最新の公式ドキュメントをご確認ください。）

さいごに

これから触る方へ、ひとつだけ。ここまで「自分でポリシーを組む」前提で書いてきましたが、公式にはポリシーテンプレートが用意されていて、Entra 管理センターのテンプレートから作成を始められます。ゼロトラストの ID とデバイスアクセス構成のガイダンスもあり、保護レベル（開始点／エンタープライズ／特殊なセキュリティ）ごとに推奨構成が示されています。

要件から白紙でポリシーを設計するのではなく、テンプレートを起点に足し引きしていくほうが、初学者にはずっと安全そうです。私も次はここから始めます。

前編と後編を通して書いてみて、条件付きアクセスは「if-then が並んでいるだけ」に見えて、実はインフラの常識が2か所ひっくり返っている仕組みでした。優先順位がないこと、暗黙の deny がないこと。この2つを掴んでからは、むしろ設計の見通しが良くなった気がします。

ここまで読んでくださった方、ありがとうございました。

よければクラウドネイティブ公式Xもチェックしてみてください。これからよろしくお願いいたします！

参考リンク

タグ