Microsoft Entra ID の条件付きアクセスを使いこなす: ゼロトラスト境界の構築

By Mirko Peters · 2026-08-27

ポッドキャストへようこそ。今回は、現代のクラウドセキュリティの土台ともいえるテーマ、Microsoft Entra ID の条件付きアクセスを掘り下げます。

Automatically translated with AI from the original post. Read the English original

ポッドキャストへようこそ。今回は、現代のクラウドセキュリティの土台ともいえるテーマ、Microsoft Entra ID の条件付きアクセスを掘り下げます。前回のエピソードをお聴きいただいた方はご存じのとおり、従来のネットワーク境界はもう通用しないという点について、1時間ほどかけて解説しました。社内のファイアウォールの内側にあるものを無条件に信頼できた時代は過ぎました。リモートワーク、ハイブリッド環境、そしてあらゆる場所に広がるクラウドアプリケーションの時代において、境界はもはや物理的な場所ではなく、ID そのものです。

Microsoft Entra ID の条件付きアクセスは、この新しい境界を支える仕組みです。組織にとって、スマートで自動化されたセキュリティガードのような役割を果たします。アクセス要求のひとつひとつについて文脈を評価し、アクセスを許可するか、ブロックするか、あるいは追加の検証を求めるかを判断します。本記事では、条件付きアクセスポリシーの中核となる構成要素を詳しく見ていきます。サインイン シグナルの評価方法、強力な認証の適用方法、そして生産性を損なうことなく組織を守る、堅牢なゼロトラストのセキュリティ態勢の構築方法を解説します。

条件付きアクセスとゼロトラストの概要

条件付きアクセスを本当に使いこなすには、まずゼロトラストの原則に考え方を合わせる必要があります。ゼロトラストの中核となる考え方は、「決して信頼せず、常に検証する」という3語に集約できます。従来、多くの組織は城と堀の戦略に頼ってきました。ユーザーがいったん城壁を突破してしまえば、オフィスのイーサネットに接続した場合でも、企業 VPN で認証に成功した場合でも、ネットワーク内を横方向に移動することがほぼ許されていました。これまで数え切れないほどのサイバー攻撃を見てきたとおり、このアプローチには根本的な欠陥があります。

ゼロトラストは、侵害されている前提に立ち、すべてのアクセス要求を信頼されていないネットワークからのものとして検証します。アクセスが許可される前に、すべての要求で認証、認可、暗号化が行われなければなりません。ただし、検証だけでは十分ではありません。検証のプロセスは、賢く、文脈を理解したものでなければなりません。

ここで登場するのが Microsoft Entra ID の条件付きアクセスです。条件付きアクセスは、if-then ステートメントのエンジンと考えるとわかりやすいでしょう。特定の条件セットが満たされたら、特定のコントロールを適用する、という仕組みです。誰がサインインしようとしているのか、どこからアクセスしているのか、どのデバイスを使っているのか、そして挙動が不審かどうかといった、さまざまなソースからのシグナルを分析することで、条件付きアクセスはセキュリティとユーザー エクスペリエンスのバランスを取りながら、自動化されたリアルタイムの判断を下します。適切なユーザーが、適切なリソースに、適切な条件のもとでアクセスできるようにするのが目的です。

ポリシーの構造: 割り当てと条件

効果的な条件付きアクセスポリシーを構築するには、その構造を十分に理解することが欠かせません。Microsoft Entra ID のポリシーはすべて、基本的に「割り当て」と「アクセス制御」という2つの主要なフェーズに分かれています。割り当てのフェーズでは、ポリシーの適用対象となるユーザーと、そのユーザーがアクセスしようとしているリソースを定義します。これらの基本要素を順に見ていきましょう。

まず、ユーザーとグループです。ここでポリシーの適用範囲を指定します。組織全体のすべてのユーザーに適用したいのか、財務部門や IT 管理者などの特定の部門を対象にしたいのか、を決めます。一般的なベストプラクティスとしては、ポリシーを広く展開する前にパイロット グループから始めることが推奨されます。ただし、最終的には、重要なセキュリティの基準はすべてのユーザーを対象とすべきです。

次に、クラウド アプリまたは操作です。ここでは、ポリシーで保護するリソースを定義します。Microsoft Exchange Online、SharePoint、あるいは Entra ID と統合されたカスタム エンタープライズ アプリケーションなど、特定のアプリケーションを対象にできます。すべてのクラウド アプリにポリシーを適用することもでき、これは組織が利用するすべての SaaS アプリケーションに共通のセキュリティ基準を適用する強力な方法です。

誰を、何を、に加えて、条件について見ていきます。条件を使うと、文脈に応じたトリガーに基づいてポリシーの適用範囲を絞り込めます。主な条件は次のとおりです。

ユーザーのリスクとサインインのリスク

Microsoft の膨大な脅威インテリジェンスネットワークを活用し、Entra ID はユーザー アカウントが侵害されている可能性（ユーザー リスク）と、特定の認証要求が攻撃者からのものである可能性（サインイン リスク）を継続的に算出します。条件では、中または高のリスクが検出された場合にのみポリシーを発動させることができます。

デバイス プラットフォーム

使用しているデバイスの OS に基づいてポリシーの対象を指定できます。Windows、macOS、iOS、Android、Linux のいずれも対象にできます。これにより、デバイスの種類に応じて異なるセキュリティ要件を適用できます。

場所

条件付きアクセスでは、信頼できる IP アドレス範囲（社内オフィスのネットワークなど）を定義したり、国コードに基づく名前付きの場所と連携させたりできます。これらの場所のシグナルを使用して、リスクの高い国からのアクセスをブロックしたり、信頼できる社内の境界の外からユーザーが接続している場合にのみ多要素認証を要求したりできます。

リアルタイムのシグナルの評価: 場所、リスク、デバイスのコンプライアンス

条件付きアクセスの真価は、リアルタイムのシグナルを評価できる点にあります。従来の IT 環境では、セキュリティ ポリシーは静的なものでした。正しいユーザー名とパスワードがあれば、管理対象の社用ノート PC からニューヨークでサインインしていても、午前 3 時に海外の信頼できない公共端末からサインインしていても、アクセスが許可されていました。条件付きアクセスは、認証を継続的なリスク評価へと変えることで、この状況を根本から変えます。

たとえばデバイスの状態を見てみましょう。Microsoft Intune またはサポートされているサードパーティの モバイル デバイス管理 (MDM) ソリューションと統合することで、条件付きアクセスはデバイスが組織のセキュリティ基準に準拠しているかを確認できます。OS は最新の状態か。ディスクの暗号化は有効か。デバイスは組織によって管理されているか、それとも管理されていない個人所有デバイス (BYOD: Bring Your Own Device) か。デバイスの状態をリアルタイムで評価することで、企業データが安全な正常なエンドポイントにのみ流れるようにできます。

リスク評価はさらに一歩進みます。Microsoft Entra ID Protection は、毎日数兆件のシグナルを分析し、不可能な移動（インポッシブル トラベル）、通常と異なるサインインの頻度、漏えいした資格情報、匿名 IP アドレスなどを確認します。ユーザーがサインインを試みると、Entra ID はこれらのシグナルを即座に評価します。ユーザーが通常はロンドンからサインインしているのに、10 分後に別の半球にある不審な IP アドレスからリソースへアクセスしようとした場合、サインインのリスクは高と判定されます。その後、条件付きアクセス ポリシーがこの要求を傍受し、データが流出する前に、検証要件を強化するか、アクセス試行そのものをブロックできます。

場所ベースのシグナルは、コンテキストをさらに加えます。ネットワークの境界がもはやセキュリティのすべてではないとしても、地理的なコンテキストは依然として非常に有用です。事業上の正当な拠点がない国からのアクセスを全面的にブロックするポリシーを構成でき、既知の脅威アクターの温床から発生する自動化された資格情報スタッフィング攻撃に対する攻撃対象領域を大幅に減らせます。

セキュリティの適用: 付与制御と認証強度

ポリシーが割り当てとリアルタイムの条件を評価した後、適用フェーズに入ります。これが付与制御です。ポリシーは、クラウド アプリケーションへのアクセスが正式に許可される前に何が必要かを規定します。

管理者には付与制御でいくつかの選択肢があります。アクセスを完全にブロックすることもできます。これはリスクの高いシナリオや未承認のデバイス状態に有効です。または、特定の要件を満たした場合にのみアクセスを許可することもできます。これらの要件には次のものが含まれます。

• 多要素認証 (MFA) を要求する
• デバイスがコンプライアンス準拠としてマークされていることを要求する
• Microsoft Entra ハイブリッド参加デバイスであることを要求する
• 承認済みのクライアント アプリケーションであることを要求する
• アプリ保護ポリシー (モバイル アプリケーション管理) を要求する
• リスクの高いユーザーにパスワードの変更を要求する

Microsoft が導入した特に強力な機能が認証強度です。従来、MFA は「実施するか、しないか」の二択として扱われることが多くありました。しかし、認証方法がすべて同じレベルのセキュリティを備えているわけではありません。フィッシング攻撃は、高度な AiTM (Adversary-in-the-Middle) 攻撃によって、従来の SMS、音声通話、さらには基本的なプッシュ通知さえも回避するように進化しています。

認証の強度（Authentication Strengths）を使うと、重要な資産や高リスクのシナリオに対して、許可する認証方法を細かく指定できます。たとえば、FIDO2セキュリティキーや Windows Hello for Business などのフィッシング耐性のある MFA を必須とし、SMS や従来の電話による認証などの安全性が低い方法は制限するポリシーを作成できます。これにより、日常的に使うアプリでは標準の MFA を許可する一方、管理ポータルや機密性の高い金融システムではフィッシング耐性のある資格情報を求める、リスクに応じた段階的な認証モデルを実現できます。

ポリシーの設計とテストのベストプラクティス

条件付きアクセスを導入するとセキュリティ態勢を大きく引き上げられますが、設定を誤ると、グローバル管理者を含む組織全体がサインインできなくなる恐れもあります。「大いなる力には大いなる責任が伴う」という言葉があるとおりです。自ら招く障害を避けるために、条件付きアクセス ポリシーの設計、テスト、管理に関する重要なベストプラクティスを順に見ていきましょう。

まず何よりも、自分自身を締め出さないことです。緊急時用のアカウント（強力かつ安全に保管されたパスワードを持つ、クラウドのみの緊急用管理者アカウント）を、必ず少なくとも 1 つ、中核となる条件付きアクセス ポリシーの対象から除外してください。また、管理者アカウントは厳格にテストし、十分な監視を行う一方で、ポリシーが誤動作した場合でも常に復旧できるような安全策を用意しておいてください。

次に、段階的な展開の方法を採用してください。制限の厳しいポリシーを作成して、すぐにすべてのユーザーに適用するのは避けてください。代わりに「レポート専用」モードを使用します。レポート専用モードでは、ポリシーを実際に適用せずに影響を評価できます。Entra ID は、ポリシーが仮にアクセスをブロックしたか許可したかをサインイン ログに記録するため、ポリシーを本番運用する前に、ユーザーの作業への支障や業務フローの中断を把握できます。

適用する準備ができたら、まずは IT 部門や協力的な事業部門などのパイロット グループを対象にしてください。そのグループのサインイン ログを監視し、フィードバックを集め、条件を調整してから、対象範囲を段階的に広げて組織全体をカバーするようにします。

最後に、ポリシーを明確に文書化し、定期的に見直してください。業務要件は変わり、従業員は役割を変え、セキュリティの脅威も進化します。2 年前には妥当だったポリシーも、今では制限が厳しすぎたり、危険なほど古くなっていたりするかもしれません。条件付きアクセスの状態を定期的に確認する仕組みを作ることで、ゼロトラストの境界を堅牢で効果的な状態に保ち、組織の目標に沿った状態を維持できます。

お聴きいただき、そして記事をお読みいただきありがとうございます。条件付きアクセスの習得は長い道のりですが、ここで紹介したステップを実践すれば、Microsoft Entra ID 上で堅牢なゼロトラストのセキュリティ境界を構築する大きな一歩になるはずです。クラウド セキュリティに関するさらに深い解説は、ぜひポッドキャストを購読してください。次のエピソードでお会いしましょう。