Microsoft 環境を保護するために Defender のシグナルを Conditional Access で活用する方法

By Mirko Peters · 2026-04-26

Microsoft Entra の Conditional Access は、玄関の用心棒のような存在です。誰を入れるか、どのリソースへのアクセスを許可するか、どの条件で許可するかを判断します。Microsoft Defender からのシグナルを取り込むことで、ID を確認するだけでなく、リスクのあるものを持ち込んでいないかも確認します。この緊密な統合により、組織は古いルールに基づいて盲目的に判断するのではなく、リスクが顕在化した時点でリアルタイムに対応できるようになります。

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

Microsoft Entra の Conditional Access は、玄関の用心棒のような存在です。誰を入れるか、どのリソースへのアクセスを許可するか、どの条件で許可するかを判断します。Microsoft Defender からのシグナルを取り込むことで、ID を確認するだけでなく、リスクのあるものを持ち込んでいないかも確認します。この緊密な統合により、組織は古いルールに基づいて盲目的に判断するのではなく、リスクが顕在化した時点でリアルタイムに対応できるようになります。

Entra の Conditional Access と Defender が連携すると、ユーザー ID、デバイスの正常性、リアルタイムの脅威インテリジェンスから情報を収集します。これらのシグナルを組み合わせて、ユーザーやデバイスがどのリソースと対話できるかを決定します。これはゼロトラストの重要な要素です。一度サインインできたからといって、無条件に信頼されるわけではありません。サインインとセッションのすべてが確認されます。このガイドでは、脅威が変化し続ける中でも、この動的なアプローチによって環境を安全に保つ方法を紹介します。

Microsoft Entra の Conditional Access と Defender シグナルの統合について理解する

現代のクラウドセキュリティは、壁を築くことではなく、状況全体が信頼できると判断できた場合にのみ開く、賢いゲートを設けることです。Entra の Conditional Access ポリシーと Defender のシグナルを統合すると、それが実現します。画一的で硬直したルールではなく、ユーザー、デバイス、場所、そして現在の脅威インテリジェンスのライブデータを使って、アクセスの判断をリアルタイムで調整します。攻撃者はブロックしつつ、正規のユーザーは支障なく作業できるようにする。これが基本的な考え方です。

このモデルは、重要な変化を常に監視しています。たとえば、Defender for Endpoint がマルウェアや危険な動作を検出すると、そのシグナルは Conditional Access の判断プロセスに直接送られます。数分前には安全に見えたリクエストも、問題を起こす前に即座に遮断されます。このシグナルから判断、そして適用へと続くワークフローこそが、動的で効果的であり、今日の脅威やコンプライアンス要件に対応できる仕組みを実現しています。

この記事全体を通して、Conditional Access がこれらのシグナルを使って、より賢いゲートキーピングを実現し、不審なアクティビティを遮断し、適応型のゼロトラストセキュリティを支える実践的な方法を紹介します。クラウドアクセスを安全かつ業務に支障のない形にするには何が必要なのか、疑問に思ったことがあるなら、ここがその答えの集約点です。信頼のギャップへの対処や、スムーズな展開に向けたポリシーの調整について詳しく知りたい場合は、Conditional Access ポリシーの信頼に関する問題についてのこちらのガイドをご覧ください。または、Entra ID とセキュリティループについてのこちらのポッドキャストで、専門家によるID リスクの議論をお聴きいただけます。

Entra Conditional Access とは何か、そしてどのように機能するのか?

Entra Conditional Access は、アプリケーションやデータに賢いセキュリティのガードレールを設けるための Microsoft の仕組みです。中核となるのはポリシー駆動型のシステムで、誰がサインインしているか、どのデバイスから、どのような条件でアクセスしているかといったシグナルに基づいて、ユーザーのアクセスを許可、ブロック、または追加認証の対象とするかを判断します。

仕組みは次のとおりです。すべてのアクセス試行は「シグナル → 判断 → 適用」のワークフローで評価されます。シグナルは、ユーザー ID、デバイスのコンプライアンス、脅威の検出から得られます。ポリシーがこれらのシグナルを解釈してリアルタイムでアクセスを判断し、Microsoft 365、Azure AD、または接続されたアプリ全体でそれを適用します。これにより、ビジネスにとって最も重要なリソースに到達できるのは、正当で、健全で、承認されたユーザーだけになります。

Microsoft Defender が Conditional Access にリスクシグナルを提供する仕組み

Microsoft Defender は、Conditional Access にとっての早期警戒システムの役割を果たします。Defender for Endpoint と Defender for Cloud Apps は、デバイスの正常性、アクティブな脅威、不審な動作に関するリアルタイムのリスクシグナルを、Conditional Access エンジンへ直接送信します。

たとえば Defender は、マルウェアの検出によってデバイスが侵害されている可能性があると判断したり、乗っ取られたセッションを示唆する不審なユーザーの動作を検知したりします。これらのシグナルは即座にアクセス ポリシーに反映され、条件付きアクセスによって高リスクのセッションをブロックしたり、追加の検証を求めたり、セッションの制限を適用したりできます。Defender を使えば、アクセスの判断は昨日の状態ではなく、現在のセキュリティ状況と常に同期されたままになります。継続的なコンプライアンスと実用的なリスクに関するインサイトについては、Defender for Cloud がリアルタイム監視をどのように支援するかをご覧ください。

条件付きアクセスの判断を左右する主要なシグナル

すべては、条件付きアクセスに「知性」を与えるリアルタイムのデータポイントであるシグナルから始まります。これらがなければ、アクセス制御は時代遅れのままになり、悪意のある攻撃者の侵入を許したり、煩雑で過剰な規則でユーザーを悩ませたりしてしまいます。では、これらの判断を実際に動かしているものは何でしょうか。それは、デバイスのコンプライアンス情報、サインインに基づくID リスク、脅威インテリジェンス、そして利用中のアプリケーションやセッションのコンテキストが組み合わさったものです。

デバイスのコンプライアンスは、「ウイルス対策ソフトが入っているか」を確認するだけのものではありません。エンドポイントが正常な状態にあり、ポリシーに準拠し、不審な動作をしていないかを確認します。一方、ID と脅威のシグナルは、ユーザーのサインインのパターン、漏えいしたパスワードの検出、通常と異なる場所からのアクセスなどから得られます。アカウントに侵害の兆候が見られる場合、それはシステムにとって重大な警告になります。

これらのシグナルが組み合わさったとき、真価が発揮されます。これにより、アクセス制御をその場で柔軟に調整できます。セッションの途中でデバイスが侵害されたり、Defender が途中でマルウェアを検出したりした場合には、アクセスを変更する必要があります。このように状況に応じて変化することで、モデルは動的なものになります。次のセクションでは、これらのシグナルがポリシーの判断にどのように組み込まれるかを詳しく見ていきます。どのシグナルが堅牢でコンテキストを考慮したアクセス制御に不可欠なのかを確認してください。

デバイスのコンプライアンス シグナルがアクセス制御に与える影響

デバイスのコンプライアンス シグナルは、Microsoft 環境で安全にアクセスするための基本です。Microsoft Intune によって生成されるこれらのシグナルは、暗号化、パッチのレベル、マルウェア対策など、組織のセキュリティ要件をデバイスが満たしているかどうかを反映します。

ユーザーがサインインすると、条件付きアクセスはリアルタイムでこれらのコンプライアンス シグナルを確認します。コンプライアンス準拠と判定されたデバイスだけが機密データやアプリケーションにアクセスできるため、侵害された、古い、または管理されていないエンドポイントを確実に遮断できます。デバイスのコンプライアンスを徹底することで、リスクは大幅に減り、セキュリティが確保されたポリシーに準拠したデバイスだけが重要なワークロードを扱うようになります。

Microsoft Defender のID シグナルと脅威シグナルの活用

Microsoft Defender は、悪意のある動作を鋭く見抜きます。危険なサインイン、漏えいした資格情報、さらには同意フィッシングやエンドポイントへのマルウェアのインストールといった不審なアクティビティも検出します。これらのシグナルは Entra ID と条件付きアクセス ポリシーへ直接送られます。

Defender が漏えいした資格情報を持つアカウントを検出した場合、ユーザーには追加の認証が求められるか、リスクが解消されるまでブロックされる可能性があります。セッションの途中でリスクが生じた場合（たとえばマルウェアが出現したり、トークンが乗っ取られたように見えたりする場合）、条件付きアクセスは直ちにセッション制御を適用したり、強制的にサインアウトさせたりできます。これは理論だけの話ではありません。この実際の Microsoft 365 攻撃の解説で詳しく取り上げられているような最新の攻撃パターンを見れば、トークンの窃取や現代的な脅威に対抗するには、動的でリスクベースのポリシー設計が不可欠であることがわかります。

Defender 連携による堅牢な条件付きアクセス ポリシーの構築

優れたポリシーは、明確な計画から始まります。実際のユーザーが業務を進められるようにしつつ、不審なトラフィックはしっかり止める計画です。ポイントは、Defender のシグナルと Intune のコンプライアンス情報を条件付きアクセスに統合することです。そうすれば静的なルールを作るだけでなく、現在起きていることに反応する、賢く多層的な防御を構築できます。

適切なアプローチは、複数の手法を組み合わせることです。多要素認証を使って ID の脅威に対処し、デバイスが信頼されていて、かつコンプライアンスに準拠していることを求め、すべてのチェックポイントをクリアした場合にのみアプリへのアクセスを許可します。こうすることで、セキュリティを強化しつつ、社員が業務を遂行する妨げにならないようにできます。

データ保護を強化しつつユーザーからの不満を抑えたい場合は、最初からポリシーを正しく構成することが非常に重要です。ユーザーの負担を増やさずにセキュリティを強化する実例については、ironclad M365 security configurations(堅牢な M365 セキュリティ構成)に関するこちらのガイドをご覧ください。次に、主要なポリシーとその重要性を整理し、Defender との統合によって保護をさらに一段引き上げる方法を解説します。

Azure 条件付きアクセスの主要なポリシー

1. レガシ認証のブロック: IMAP や POP などの古いプロトコルは MFA をサポートしておらず、攻撃者に狙われやすい経路です。これらのレガシ認証方式をブロックするポリシーを適用し、環境における主要なリスク経路を減らしてください。これは、安全な Microsoft 365 および Azure 環境すべてにおける基本的な出発点です。
2. ユーザーと管理者への MFA の要求: 多要素認証は、資格情報の窃取の大半を食い止めます。すべてのユーザーに MFA を適用し、特権の高い操作やリスクの高いシナリオでは、ステップアップ認証(可能であればフィッシング耐性のある方式)を要求してください。これにより、侵害発生時の横方向への移動を防げます。
3. デバイスが準拠済みとマークされていることを要求: Intune のデバイス コンプライアンス ポリシーで管理された、正常な状態のエンドポイントだけが Exchange Online や SharePoint などの機密性の高いアプリにアクセスできるようにします。リモート ワークの環境で、感染した端末や管理されていない端末からデータが持ち出されるのを防ぎます。
4. アクセス場所の制御を適用: 信頼されたネットワークの場所に基づいて重要なアプリへのアクセスを制限し、通常とは異なる場所からのサインインでは追加の認証を要求します。これはゼロトラストの原則とよく合致します。ユーザー名とパスワードが正しいからといって、信頼してはいけません。
5. アプリ制御とセッション ポリシーの利用: Defender for Cloud Apps を通じてセッション制御を設定し、サインイン後にユーザーができる操作を管理します。ダウンロードを制限したり、情報の持ち出しをスキャンしたり、リスクのある操作をブロックしたりできます。管理されていないエンドポイントでは、読み取り専用のアクセスのみを許可するといった運用も可能です。

ゼロトラストへの移行を進めるなら、Zero Trust by Design に関するこちらのポッドキャストで強調されているように、ポリシー設計を連携させることが重要です。このポッドキャストでは、Microsoft 365 と Dynamics 365 全体にわたる適応型アクセス ポリシーと継続的評価について取り上げています。

ユーザーに対する MFA とフィッシング耐性のある認証の適用

• すべてのユーザーに MFA を適用: 管理者だけでなく、すべてのアカウントに対して MFA を既定の状態にします。迅速に開始するには、組み込みの条件付きアクセス ポリシーを使用してください。
• フィッシング耐性のあるオプション: 主要な認証要素として FIDO2 セキュリティ キーと Windows Hello for Business の導入を推進してください。フィッシングやトークン再利用攻撃のリスクを下げられます。
• 管理者およびリスクの高いグループ: 管理者アカウントや機密性の高いアプリにアクセスするユーザーには、常にステップアップ認証を要求してください。これらは攻撃者の主要な標的だからです。
• 緊急時用アカウント: 緊急時の復旧に備えて、安全で監視された例外アカウントを用意しておきます。ただし、不正使用を防ぐために利用を厳しく制限し、監査を徹底してください。

アクセス要件としての信頼済みデバイスと準拠デバイス

• 準拠デバイスの要求: Intune で準拠と判定され、ポリシーに沿ったデバイスだけに、機密性の高い業務データへのアクセスを許可します。
• ハイブリッド参加または Entra ID 参加の強制: 高度なシナリオでは、ハイブリッド Microsoft Entra 参加済み、または Entra ID に完全に登録されたデバイスからのアクセスのみを許可します。これもまた、ID との結び付きを強化する手段です。
• デバイスとユーザーのリスクを組み合わせる: デバイスのコンプライアンスとユーザーのリスク シグナルを重ね合わせます。関連付けられたユーザーやセッションが急に疑わしく見えた場合は、準拠デバイスであってもブロックできるようにします。

条件付きアクセスの展開におけるベスト プラクティスとよくある間違い

条件付きアクセスは、その展開方法次第で効果が決まります。厳しすぎれば全員がロックアウトされ、緩すぎれば至る所に穴が開きます。ポイントは、段階的に安全に展開することと、業務を中断させたり、巧妙な攻撃者に付け入る隙を与えたりする初歩的なミスを避けることです。

多くの頭痛の種は、過度なブロック（厳しすぎるポリシー）、MFA設定の誤り、あるいはポリシー同士の衝突から生じます。その結果、攻撃者に侵入の隙を与えたり、さらに悪いことに、日常的に利用するユーザーを困らせたりします。ツールだけの問題ではありません。強固なガバナンス、明確なオーナーシップ、ポリシーのライフサイクル管理が、IDの境界を安定させ、予測可能な状態に保つうえで重要な役割を果たします。

作業を始める前に、前提条件、ライセンス要件、そして細かな技術的な注意点（特に、複雑なユーザー基盤を持つハイブリッド環境やマルチクラウド環境）を確認しておいてください。また、監視も軽視しないでください。ポリシーのドリフトや新たな脆弱性を監視する担当者がいなければ、自動化だけでは限界があります。大規模な Microsoft 365 環境でこうした落とし穴を正しく理解するには、一般的なガバナンスの失敗に関するこの概要をご覧ください。コラボレーション基盤の問題については、ガバナンスに焦点を当てたこちらのガイドをお読みください。

条件付きアクセスでよくある間違いと競合を回避する方法

1. 本格展開の前にポリシーをテストする: 「レポートのみ」モードやパイロットグループを使用して、実際の影響を確認してください。組織全体に適用する前に変更をテストすれば、想定外の事態を防げます。
2. ポリシーの競合に注意する: 重複するポリシーは、予期しないアクセスのブロックや、意図した以上の権限の付与につながることがあります。特に複数の管理者が関わっている場合は、競合するルールを避けるため、条件付きアクセスのマトリックスを定期的に見直してください。
3. MFAの調整は慎重に行う: MFAの設定を誤ると、正当なユーザー（管理者であっても）がロックアウトされたり、レガシープロトコルが通過してセキュリティの抜け穴が生じたりすることがあります。安全で監視された「緊急時用（ブレークグラス）」アカウントを、必ず安全策として用意してください。
4. 継続的な監視と監査を行う: ライブログやユーザーからのフィードバックを監視し、状況に応じて柔軟に調整する準備をしておいてください。自動監視と明確なインシデント対応を組み合わせることで、問題が拡大する前に検知できます。

アプリやプラットフォーム全体でセキュリティ戦略を統合し、従来型の失敗を避けるという別の視点については、Microsoft Power Platform における DLP とセキュリティガバナンスを掘り下げたこちらの解説をぜひお聴きください。

デプロイの前提条件とサービスの制限事項

1. 管理者ロール: 条件付きアクセスポリシーを作成・管理するには、通常、Entra ID のグローバル管理者またはセキュリティ管理者として十分な権限が必要です。
2. ライセンス要件: ほとんどの条件付きアクセス機能には、少なくとも Microsoft Entra ID P1 または P2 のライセンスが必要です。Defender との統合には、さらに上位のライセンスが必要になる場合があるため、最初から計画に含めてください。
3. インフラストラクチャの前提条件: デバイスが Intune に登録されていること、IDに重複や古いアカウントがないこと、そしてディレクトリが同期と監視に対応していることを確認してください。
4. サービスの制限事項: すべてのレガシーアプリやサードパーティアプリが条件付きアクセスの適用に対応しているわけではありません。また、サービスアカウントやマネージド ID には特別な扱いが必要になることがよくあります。見落としがないよう、ドキュメントを注意深く確認してください。

高度な制御とセキュリティツールの統合

条件付きアクセスの基本が安定して機能するようになったら、次の段階として、セッション制御やトークン保護の追加、そして他のセキュリティプラットフォームとの統合に取り組みます。ここで「最小特権」の原則を細かく適用します。ユーザーが入口を通過した後でも、何ができるかを制御し、トークンが盗まれて別の場所で再利用されないようにします。

Microsoft Intune、Defender、その他のサードパーティ製セキュリティ製品との深い統合により、状況を把握できないまま運用する事態を避けられます。統合されたテレメトリがリアルタイムのフィードバックを提供するため、脅威の検知と対応は、遅れて行う受動的なプロセスではなく、継続的に機能する仕組みになります。これは、機密性の高いワークロードを保護し、コンプライアンスを維持するうえで極めて重要です。特に規制の厳しい業界では欠かせません。

継続的な監視と適応型コントロールは、Defender for Cloud や Power BI などのツールを活用することで、コンプライアンスの逸脱を防ぐのにも役立ちます。継続的なコンプライアンスの自動化と統合された可視化に関する実践的な戦略については、実際の Defender for Cloud 監視ガイドをご覧ください。それでは、セキュリティとユーザー エクスペリエンスの両方を最大化するための主要なコントロールと統合戦略を詳しく見ていきましょう。

マネージド デバイスでのセッション コントロールとトークン保護の利用

• サインイン頻度: ユーザーが再認証を求められる頻度を設定します。機密性の高いアプリでは間隔を短くすることで、トークンが盗まれた場合のリスクの期間を減らせます。
• アプリ保護ポリシー: モバイルや準拠していないエンドポイントからデータにアクセスする場合、コピー/貼り付け、名前を付けて保存、共有などの操作を制限し、機密データが外部に漏えいするのを防ぎます。
• トークン保護: 認証トークンを特定の検証済みデバイスに紐付けます。これにより、トークンが盗まれた場合でも、攻撃者が別のマシンでトークンを再利用することを防げます。
• 利便性のバランス: 実際のユーザーでコントロールをテストし、過度な負担をかけないようにします。推測ではなく、必要性とリスクに基づいて段階的に強化してください。

セキュリティ ツールの統合とアプリ クライアントに関する考慮事項

• Microsoft Intune の統合: デバイス管理を条件付きアクセスと直接連携させ、最新のコンプライアンスとエンドポイントの正常性のシグナルを取得します。
• Defender for Endpoint/Cloud Apps: Defender を使用して脅威とセッションのシグナルを送信し、条件付きアクセスがリアルタイムの適応型ポリシーとして利用できるようにします。
• サードパーティ製セキュリティ ツール: 必要に応じて SIEM、CASB、エンドポイント管理ソリューションを統合しますが、互換性は慎重に検証してください。
• アプリとクライアントのサポート: 特にレガシー アプリやモバイル アプリのクライアントが、条件付きアクセスの適用とテレメトリ レポートを完全にサポートしていることを確認し、監視の死角を防いでください。

Microsoft Power Platform のセキュリティとコネクタのリスク管理について詳しくは、こちらの Power Platform ガバナンスのベスト プラクティスをご覧ください。

Defender シグナルによるリアルタイムの脅威への対応

クラウドにおけるセキュリティは、もはやポリシーを設定して結果を祈るだけのものではありません。条件付きアクセスと統合された Microsoft Defender のシグナルにより、数日後ではなくリアルタイムで動的な脅威対応が可能になります。Defender for Endpoint がマルウェアの活動や進行中の攻撃を検出すると、条件付きアクセスは即座に状況を切り替え、セッションを取り消したり、その場で認証を厳格化したりできます。

この自動化により、攻撃者の滞留時間が大幅に短縮され、横方向への移動を遮断してデータ損失を最小限に抑えられます。手作業で行う必要はありません。Defender が生成するテレメトリは Entra ID のリスク評価に直接取り込まれ、ユーザー、デバイス、セッションのリスクレベルが調整されます。その結果、インシデント対応が向上し、セキュリティ チームの作業負荷が減り、攻撃者にとって突破がはるかに困難な環境になります。すべてのセッションとコンテキストが重要となるゼロトラストの原則のもとでは、特にこの点が重要です。

以降のセクションでは、動的なポリシー調整が実際にどのように行われるか、また Defender のインテリジェンスがリスク スコアリングをどのように強化し、よりスマートでコンテキストに応じた条件付きアクセスの対応を可能にするかを詳しく解説します。適応型セキュリティは単なる流行語ではありません。ここから実際に測定可能な価値が得られます。

Defender for Endpoint を使用した動的なポリシー調整

1. マルウェア検出によるアクセス変更: Defender for Endpoint がデバイス上でマルウェアを検出すると、条件付きアクセスはそのデバイスからすべての企業リソースへのアクセスを直ちにブロックするか、ユーザーに追加の認証を要求できます。
2. 不審なプロセスや脅威: 既知の脆弱性攻撃やランサムウェアの動作などの危険なプロセスの活動が確認されると、そのシグナルによってデバイスのリスクが引き上げられます。条件付きアクセスは、状況が修復されるまで、アクティブなセッションを取り消すか、より厳格なコントロールを適用して対応します。
3. 自動化されたセッションの取り消し: 管理者が問題に気付くのを待つのではなく、Defender のリアルタイムのアラートにより、隔離、サインアウト、またはユーザー アクセスの読み取り専用への切り替えなどのポリシーが遅延なく自動的に適用されます。
4. 即時かつ統合された対応: これらの機能によりインシデント対応が大幅に迅速化され、攻撃者をリアルタイムで遮断し、被害の拡大やデータ漏えいのリスクを最小限に抑えます。

Defender のインテリジェンスで Identity Protection のリスクレベルを強化する

Defender は、エンドポイントの警告を上げるだけではありません。デバイスのリスク、セッションの異常、脅威シグナルを Entra Identity Protection のリスクスコアリングエンジンに取り込みます。すべてのサインインとセッションには、Defender for Endpoint と Defender for Cloud Apps のリアルタイムのテレメトリに基づいて、最新のリスクレベルが割り当てられます。

この強化されたモデルにより、条件付きアクセスは真にリスクベースのアクセス制御を実現できます。静的なルールだけでなく実際のリスクが求める場合に、自動的にブロックしたり、ステップアップ認証を適用したりできます。その結果、ゼロトラストポリシーは変化の速いリスクに適応し続け、攻撃者が被害を与える前に遮断する効果が大幅に高まります。