2026.08.07 17:52 (更新: 2026.08.07)

【Entra ID】GPO・ACL の知識は、どこまで通じるか｜前編・条件付きアクセスを並べて読み替える

はじめに

こんにちは！Identityチームのkaitoです。

入社エントリーでも書きましたが、私は前職までインフラ／サーバーエンジニアとして、Windows・Linux等の仮想環境のサーバー構築や、DNS／AD／LDAP まわりの移行を担当してきました。今は Okta / Entra ID / PingOne といったアイデンティティ領域を勉強中の身です。

そんな私が Entra ID の条件付きアクセスを触りはじめて、最初に思ったのがこれでした。

「これ、GPO とファイアウォールの ACL を混ぜたやつじゃないか？」

結論から言うと、この直感は半分当たっていて、半分は思い込みでした。しかもそのズレは、放っておくと本番でヒヤッとする種類のズレです。

書いているうちに思ったより長くなったので、2回に分けます。前編は「インフラの知識で読み替えると、どこが同じでどこがズレるか」。後編は「じゃあ実際どうポリシーを組むのか」です。

同じようにオンプレからクラウドに来た方の遠回りを、少しでも減らせたらと思っています！

そもそも条件付きアクセスとは（超ざっくり）

Microsoft Entra 条件付きアクセスとは、ユーザー・デバイス・場所などのシグナルに基づいて、クラウドリソースへのアクセスを許可・制限する Microsoft Entra ID のアクセス制御機能です。

Microsoft の公式ドキュメントでは、条件付きアクセスは「割り当て」と「アクセス制御」の if-then ステートメントと説明されています。つまり、

もし（誰が・何に・どこから・どんな状態で）アクセスするなら → こうする（ブロックする／MFA を要求するなど）

という一文の集まりです。ポリシーの骨組みは、ポリシー名・割り当て（ユーザーまたはグループ＋対象リソース）・アクセス制御（許可またはブロック）・有効化状態の4つです。有効化状態は「オフ」「レポート専用」「オン」から選びます。画面を開くと項目がたくさん並んでいて怯みますが、骨組みはこれだけです。

そしてもうひとつ、押さえておきたい重要な前提があります。公式ドキュメントには、条件付きアクセスポリシーは第 1 段階認証が完了した後に適用される、とはっきり書かれています。つまり「まず本人であることを確かめてから、その先を条件で絞る」という順番です。同じ資料には「DoS 攻撃などに対する組織の最前線の防御を意図したものではない」とも書かれています（ただし、そうしたイベントからのシグナルをアクセス判断に使うことはできる、とも続いています）。ここを取り違えると、条件付きアクセスに期待する役割そのものがズレてしまいます。

対比その1：GPO に似ている、でも「後勝ち」ではない

「特定のユーザーやグループをスコープにして、設定を強制する。ただし一部のアカウントは除外する」。この構造は、AD の GPO をやっていた人ならすんなり入ってきます。条件付きアクセスの「割り当て」はまさにこのスコープ指定で、除外もできます。私も最初は「OU に GPO をリンクして、管理者アカウントだけ除外していたのと同じだな」と理解しました。

除外の強さも直感どおりでした。公式ドキュメントには、対象と対象外の両方に同じユーザーやグループが入っている場合、そのユーザーは除外されるとあり、除外の動作がポリシー内の包含の動作を上書きする仕様だと説明されています。「すべてのユーザー」を対象にしつつ特定のグループを対象外にすれば、そのグループは抜ける。ここは迷わなくて済みます。

ですが、複数のポリシーが重なったときの挙動が根本的に違います。先に結論を図にしておきます。

GPOは後に適用されたものが上書きするが、条件付きアクセスは全ポリシーを評価しブロックが1つでもあれば停止する

GPO は、ローカル → サイト → ドメイン → OU（LSDOU）の順に処理されます。公式ドキュメントにも、後続の各ポリシー適用がそれ以前のポリシーで適用された設定を上書きしうるため、処理順序が重要だと書かれています。さらに競合解決の仕組みには "last-writer-wins"（最後に書いたものが勝つ）という名前まで付いていて、同じ会議室を同時に予約しようとした2人のうち最後の予約だけが通る、という例えで説明されています。だから通常は、一番深い OU にリンクされた GPO が最終的に勝ちます。「後勝ち」です。

（厳密には、リンクの Enforced（強制）や継承のブロック、同一コンテナに複数リンクした場合のリンク順でこの前後関係は覆ります。ここは「既定の挙動」として捉えてください。）

一方の条件付きアクセスは、上書きという概念がありません。公式ドキュメントの説明では、ある時点で個々のユーザーに複数のポリシーが適用されうる場合、該当するすべてのポリシーが満たされている必要があります。例として挙げられているのが分かりやすくて、あるポリシーが MFA を要求し、別のポリシーが準拠デバイスを要求している場合、ユーザーは MFA を完了し、かつ準拠デバイスを使う必要がある、と。

さらに評価は2つのフェーズに分かれています。フェーズ1でセッションの詳細（ネットワークの場所やデバイス ID など）を収集し、フェーズ2で適用。このフェーズ2で、ブロックが構成されたポリシーがひとつでもあれば、そこで適用が停止してユーザーはブロックされます。

つまり条件付きアクセスには "last-writer-wins" が存在せず、「後から作ったポリシーで前のポリシーを緩める」ということができません。GPO のリンク順にあたる優先順位という概念そのものがなく、「このポリシーを先に評価する」といった制御はできない。有効なポリシーが100個あって、そのサインインが100個すべてに該当するなら、100個ぶんの制御が組み合わされて適用されます（レポート専用のポリシーは評価だけされて、制御は強制されません。ただし準拠デバイスを要求するレポート専用ポリシーは、評価中に macOS・iOS・Android でデバイス証明書の選択を求めることがあります）。ここは GPO の感覚のまま設計すると事故る、と個人的に一番肝に銘じたところです。

なお、許可コントロールが複数必要な場合、ユーザーに求められる順序はドキュメントで定義されていて、多要素認証 → 準拠としてマークされたデバイス → Microsoft Entra ハイブリッド参加済みデバイス → 承認済みクライアントアプリ → アプリ保護ポリシー → パスワードの変更 → 利用規約 → カスタムコントロール、の順です。

対比その2：ACL に似ている、でも「暗黙の deny」がない

「許可／拒否のルールを並べて、条件に一致したら制御する」という見た目も、ACL に本当にそっくりです。ブロックのアクセス制御について、公式ドキュメントは「このコントロールは強力であり、効果的に使用するには適切な知識が必要です」と警告していて、この緊張感も ACL を書いていたときの感覚に近いものがあります。

でも、デフォルトの挙動が真逆です。

Cisco IOS の IP ACL をはじめ、多くの順序評価型 ACL には末尾に暗黙の deny があります。どのルールにも一致しなかったパケットは落ちるため、「明示的に許可されていないものは通らない」が前提です。インフラ屋の身体に染み付いている考え方です。

条件付きアクセスにはこれがありません。ポリシーの割り当て条件に当てはまらなかったサインインは、そのポリシーからは何も制御を受けず、そのまま進みます。実際、サインインログの評価結果には「未適用（ユーザーが除外された、など、ポリシーが適用されなかったサインインイベント）」という結果が定義されています。

これは考えてみれば当たり前で、条件付きアクセスは「条件に当てはまったものに制御をかける」仕組みであって、「許可リストに載っていないものを落とす」仕組みではないということです。頭では分かっても、ACL の癖で「とりあえず全部絞られているはず」と無意識に思い込んでしまうのが怖いところでした。

（なお、対象となるテナント（ライセンスと機能の適格性で決まります）に既定で入ってくる保護は別途あります。Microsoft 管理の条件付きアクセスポリシーという仕組みがあり、「すべてのユーザーへの MFA 要求」「管理ポータルにアクセスする管理者への MFA 要求」「レガシ認証のブロック」「デバイスコードフローのブロック」などが Microsoft 側から提供・管理されます。管理者は状態の切り替えと除外の設定はできますが、名前の変更や削除はできない、という代物です。レポート専用の状態のまま放置すると、原則として導入から45日で自動的に有効になります（それより早く有効になる場合もあります）。ここで言っているのはあくまで「自分が作ったポリシーの割り当て範囲外は、そのポリシーでは何も起きない」という意味です。）

だからこそ、公式が挙げている一般的なポリシーの例に「レガシ認証プロトコルを使用しようとするユーザーのサインインをブロックする」があるように、塞ぎたい穴は自分で明示的にブロックしにいく必要があるわけです。ちなみにこのレガシ認証ブロックがなぜ最優先で推奨されるかというと、Microsoft の分析ではパスワードスプレー攻撃の99%以上、クレデンシャルスタッフィング攻撃の97%以上がレガシ認証を使っているとのこと。レガシ認証は MFA を実行できないので、条件付きアクセスの MFA 要求がそのサインインに届いていれば、普通は要件を満たせずブロックされます。怖いのは、そこから漏れた経路です。MFA ポリシーの対象範囲外に残ったレガシ認証は、パスワードだけで叩けてしまう。だから MFA 要求とは別に、レガシ認証そのものを明示的に塞いでおく必要があるわけです。

「明示列挙すると穴が開く」のは ACL と同じだった

この「素通り」がいちばん怖い形で出るのが、デバイスプラットフォームの指定です。

たとえばこんなポリシーを2つ作ったとします。

ポリシー1：iOS と Android には準拠デバイスを要求する
ポリシー2：Windows にはハイブリッド参加済みデバイスを要求する

一見、スマホと PC を両方カバーできていそうに見えます。ですが条件付きアクセスがサポートするデバイスプラットフォームはAndroid / iOS / Windows / macOS / Linux の5つです。つまり上の2つでは、macOS と Linux がどのポリシーにも当てはまらないまま素通りします。ACL 的に言えば、許可したいものを明示列挙したのに末尾の deny を書き忘れた状態です。

公式ドキュメントもここは明確に推奨を示していて、未サポート／未想定のプラットフォームをブロックするポリシーを別途作ることとされています。作り方も具体的で、デバイスプラットフォーム条件の対象に「任意のデバイス」を選び、対象外に自組織で使うプラットフォームを列挙して、アクセス制御はブロックにする。

文字だけだと「除外したOSをブロックするの？」と取り違えそうなので、図にします。除外したOSはこのポリシーの対象から外れるため、この条件でそれ以外のプラットフォームとして検出されたサインインがブロック対象になります。

使うOSだけを列挙するとmacOSとLinuxが対象外になる。任意のデバイスを対象にして利用OSを除外すると、それ以外として検出されたプラットフォームをブロックできる

使う OS を個別に列挙するのではなく、any で受けて、使う OS だけをブロック対象から外す。

FW ルールで言えば、通したい通信の許可を手前に並べ、末尾の deny any で残りを落とす定石に対応する考え方でした。条件付きアクセスには暗黙の deny がないぶん、対象範囲を広く取って、除外する例外を明示する形を自分で設計する必要がある。ここが今回いちばん腹に落ちたポイントでした。

ただ、この条件が見ているのは「検出されたプラットフォーム」であって、端末の真正性ではありません。特に未登録デバイスではユーザーエージェントなどの情報に依存します。端末そのものを効かせたいなら、準拠デバイスや Microsoft Entra ハイブリッド参加済みデバイス、アプリ保護ポリシーと組み合わせる必要があります。

なお、抜け漏れを後から見つけるための道具もあります。Entra 管理センターの Conditional Access gap analyzer というブックで、「どのポリシーも適用されなかったサインイン」を洗い出せるとのこと。

対比その3：Okta の認証ポリシーは、むしろ ACL の感覚に近い

ここまで「条件付きアクセスは ACL に似ているけど暗黙の deny がない」と書いてきましたが、同じ IDaaS でも Okta は考え方が真逆に近いという話でした。

Okta の認証ポリシー（ここではアプリごとの認証要件を決める「アプリサインインポリシー」の話です）は、ルールを優先順位の順に上から評価して、最初に一致したルールで判定が確定する（first match）という仕組みです。そして各ポリシーには Catch-All（キャッチオール）ルールがあり、どのルールにも一致しなかったアクセスはここで処理されます。なお、この first match は1つのポリシー内のルール評価の話です。Okta でもサインイン全体では、グローバルセッションポリシーとアプリサインインポリシー双方の要件を満たす必要があります。

ここで私は最初、大きな勘違いをしていました。「末尾に Catch-All があるなら ACL と同じで安心だな」と思ったのですが、Catch-All の既定は拒否でなく、許可寄りでした。Okta の公式ヘルプには「アプリサインインポリシーを作成すると、任意の2つのファクタータイプですべての要求にアクセスを許可する Catch-All ルールが1つだけある状態から始まる」と書かれています。Okta の脅威インテリジェンス責任者のブログも同じことを言っていて、既定で許可になっているのは、組織の設定中に正当な管理者やユーザーをロックアウトさせないためだと説明されていました。そして「運用が立ち上がったら deny by default にすべき」と推奨されています。なお、既定の Catch-All が編集できないケースもあるため、その場合は拒否ルールを自作して上位に置く、とも書かれていました。

並べてみると、こうなります。

	Entra ID 条件付きアクセス	Okta アプリサインインポリシー	FW の ACL
評価の仕方	該当するポリシーをすべて評価（順序の概念なし）	（ポリシー内の）ルールを優先順位順に上から評価	上から順に評価
一致したあと	該当したものはすべて適用（ブロックがあれば即停止）	最初に一致した1つで確定	最初に一致した1つで確定
優先順位	概念そのものがない	ある（ルール順）	ある（ルール順）
一致しなかったとき	そのポリシーでは何も起きない（素通り）	Catch-All で処理（一般的な新規アプリポリシーでは、任意の2種類のファクタータイプによる認証を要求して許可）	暗黙の deny（最初から拒否）

つまり「ルール順＋末尾で受け止める」という ACL の骨格を持っているのは Okta のほうで、条件付きアクセスは同じ if-then でも設計思想が別物、ということでした。

ただし、これは「Okta のほうが安全」という話では全くありません。Catch-All は無条件の許可ではないけれど、どのルールにも一致しなかった要求を自動で拒否してくれる仕組みでもない。だからこそ Okta 自身のセキュリティチームが、運用が立ち上がったら deny by default にすべき（Catch-All を拒否に変える。編集できないなら拒否ルールを上位に自作する）と書いているわけです。

前編のまとめ：末尾を締めるのは、どちらでも自分の仕事

インフラの知識は、アイデンティティを学ぶうえで確かに足場になります。「スコープを決めて設定を強制する」「条件で通信を制御する」という発想そのものは、そのまま使えます。

ただ今回いちばん学びになったのは、似ている仕組みほど、違うところが危ないということでした。GPO の「後勝ち」と条件付きアクセスの「ブロックがあれば即停止」、ACL の「暗黙の deny」と条件付きアクセスの「当てはまらなければ素通り」。どちらも、比喩に頼りすぎると設計を間違える箇所です。

そして3つ並べてみて、結論はむしろ共通していると思いました。

末尾を締めるのは、どちらでも自分の仕事。

条件付きアクセスなら、対象範囲を広く取って、必要な例外と制御を明示する。Okta なら、Catch-All を拒否側に寄せる（編集できないなら拒否ルールを上位に自作する）。今回並べた3つの中で、暗黙の deny が最初から用意されているのは ACL だけで、クラウドの ID 側では末尾を誰かが書いてくれるわけではない、というのが前編の収穫でした。

一方で、違いを正しく掴めたときには、インフラの定石がそのまま武器になるとも思いました。デバイスプラットフォームを「任意のデバイスで受けて、使う OS を除外する」形にするのは、まさに FW ルールの書き方そのものでした。

つまり比喩は、捨てるものではなく「どこがズレるか」を知って使うものなんだな、と。これからも遠慮なく使っていきますが、毎回ちゃんと突き合わせて確かめる癖はつけていきたいです。

後編では、「じゃあ優先順位もなく上書きも起きないなら、どうポリシーを切り分けるのか」という設計の話と、レポート専用モードでの慣らし方、緊急アクセスアカウントという逃げ道の作り方、それに実際に触って引っかかったポイントを書きます。

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

今回は「比喩がどこでズレるか」という話でしたが、実際の現場では、このズレがそのまま設定の穴になります。クラウドネイティブでは、Okta や Entra ID といった製品を特定のベンダーに寄らずに選ぶところから、導入後のポリシーのチューニングまでを、お客様と一緒に伴走しています。最後はお客様自身で運用しきれる状態にしてお返しするのが会社の方針で、私もそこを目指して勉強しているところです。

「うちの条件付きアクセス、穴が開いていないか一度見てほしい」といったご相談も歓迎ですので、気軽に声をかけていただけたらと思います。

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

参考リンク

タグ

柳原海士