ゼロトラストセキュリティにおいて、認証は「誰であるか」を確認するだけでは十分ではありません。同じユーザーであっても、アクセス元のデバイス、ネットワーク、リスクレベルによって許可するアクセス範囲を動的に制御する必要があります。この「コンテキストに基づく動的なアクセス制御」を実現するのが条件付きアクセスポリシーです。

本記事では、条件付きアクセスポリシーについて以下の内容を解説します。

  • 条件付きアクセスの基本概念とゼロトラストにおける位置づけ
  • アクセス制御で評価するシグナル（条件）の種類
  • ポリシー設計のパターンとベストプラクティス
  • Microsoft Entra Conditional Accessでの実装例
  • Google BeyondCorpによるコンテキストアウェアアクセス

この記事を読むことで、リスクベースのアクセス制御を設計し、条件付きアクセスポリシーを実装できるようになります。

前提知識

本記事を理解するために、以下の知識があることを前提としています。

  • ゼロトラストの基本原則を把握している
  • IAMとIdPの基本的な役割を知っている
  • MFAの仕組みを理解している

アイデンティティ管理の基礎についてはゼロトラストにおけるアイデンティティ管理 - IAMとIdPの基礎を、MFAについては多要素認証（MFA）とパスワードレス認証の導入ガイドを先に読むことをお勧めします。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

  1. 条件付きアクセスの仕組みとゼロトラストにおける役割を説明できる
  2. アクセス判断に使用する主要なシグナルを理解できる
  3. 組織に適した条件付きアクセスポリシーを設計できる
  4. Microsoft Entra Conditional Accessの基本設定を理解できる
  5. Google BeyondCorpによるコンテキストアウェアアクセスの概要を把握できる

条件付きアクセスとは

条件付きアクセス（Conditional Access）は、アクセス要求のコンテキスト（状況・条件）を評価し、動的にアクセス制御を行う仕組みです。単純な「認証済みならアクセス許可」ではなく、「認証済みかつ条件を満たしていればアクセス許可」という形でアクセス判断を行います。

if-thenステートメントとしての条件付きアクセス

条件付きアクセスポリシーは、本質的にif-thenステートメントです。

flowchart LR
    subgraph condition["条件（if）"]
        user["ユーザー/グループ"]
        app["対象アプリケーション"]
        context["コンテキスト条件"]
    end
    
    subgraph action["アクション（then）"]
        grant["アクセス許可"]
        block["アクセスブロック"]
        require["追加要件を要求"]
    end
    
    condition -->|"条件に一致"| action

ポリシーの構造例

条件（if） アクション（then）
すべてのユーザーが、社外ネットワークから、機密アプリにアクセスする場合 MFAを要求する
管理者が、任意の場所から、Azure管理ポータルにアクセスする場合 MFAと準拠デバイスを要求する
ゲストユーザーが、非準拠デバイスから、SharePointにアクセスする場合 アクセスをブロックする

ゼロトラストにおける条件付きアクセスの役割

条件付きアクセスは、ゼロトラストアーキテクチャにおけるPolicy Decision Point（PDP）の中核機能を担います。NIST SP 800-207で定義されるゼロトラストの論理コンポーネントとの対応関係は以下の通りです。

flowchart TB
    subgraph request["アクセス要求"]
        user["ユーザー"]
        device["デバイス"]
        network["ネットワーク"]
    end
    
    subgraph pdp["Policy Decision Point<br/>（条件付きアクセス）"]
        pe["Policy Engine<br/>ポリシー評価"]
        pa["Policy Administrator<br/>セッション管理"]
    end
    
    subgraph signals["シグナル入力"]
        idp["Identity Provider<br/>認証情報"]
        mdm["MDM/UEM<br/>デバイス状態"]
        threat["Threat Intelligence<br/>脅威情報"]
        siem["SIEM<br/>行動分析"]
    end
    
    subgraph pep["Policy Enforcement Point"]
        app["アプリケーション"]
        data["データ"]
    end
    
    user --> pe
    device --> pe
    network --> pe
    
    idp --> pe
    mdm --> pe
    threat --> pe
    siem --> pe
    
    pe --> pa
    pa -->|"許可/拒否"| pep

条件付きアクセスは、複数のシグナルソースから情報を収集し、それらを統合的に評価してアクセス判断を行います。これにより、「Never Trust, Always Verify」の原則を動的かつコンテキストに応じた形で実現します。

アクセス判断に使用するシグナル

条件付きアクセスでは、様々なシグナル（条件）を組み合わせてアクセス判断を行います。主要なシグナルカテゴリを以下に解説します。

ユーザーとグループ

アクセスを要求しているユーザーの属性に基づく条件です。

シグナル 説明 使用例
特定のユーザー 個別のユーザーアカウント テスト用アカウントの除外
グループメンバーシップ セキュリティグループ、Microsoft 365グループ 部門別ポリシー適用
ディレクトリロール 管理者ロール 管理者への厳格なポリシー
外部ユーザー ゲスト、B2Bコラボレーション ゲストアクセスの制限
ワークロードID サービスプリンシパル、マネージドID APIアクセスの制御

設計のポイント

  • グループベースの割り当てを使用し、個別ユーザー指定は最小限にする
  • 管理者アカウントには常に厳格なポリシーを適用する
  • 緊急アクセスアカウント（Break Glass Account）は必ず除外する

対象アプリケーション

アクセス先のアプリケーションやリソースに基づく条件です。

シグナル 説明 使用例
クラウドアプリ Microsoft 365、SaaSアプリ アプリごとの要件設定
ユーザーアクション セキュリティ情報登録、デバイス登録 登録フローの保護
認証コンテキスト 機密度ラベルとの連携 機密データアクセス時の追加認証

設計のポイント

  • 機密性の高いアプリケーションには強固なアクセス要件を設定する
  • 「すべてのクラウドアプリ」を対象にするベースラインポリシーを作成する
  • 認証コンテキストを活用し、同一アプリ内でも機密データには追加保護を適用する

ネットワーク条件

アクセス元のネットワーク環境に基づく条件です。

シグナル 説明 使用例
IPアドレス範囲 特定のIP範囲（社内ネットワーク等） 社外アクセスへのMFA要求
国/地域 IPジオロケーション 特定国からのアクセスブロック
信頼された場所 管理者が定義した信頼できるネットワーク 信頼された場所からのMFA免除
準拠ネットワーク Global Secure Access経由の接続 VPN不要のセキュアアクセス

設計のポイント

  • 「信頼された場所」の定義は厳密に行い、定期的に見直す
  • 国/地域ベースのブロックは回避可能なため、唯一の防御策にしない
  • ネットワーク条件だけでアクセス許可せず、他の条件と組み合わせる

デバイス条件

アクセス元デバイスの状態に基づく条件です。

シグナル 説明 使用例
デバイスプラットフォーム Windows、macOS、iOS、Android、Linux OS別ポリシー
デバイスの準拠状態 MDM/UEMのコンプライアンスポリシー準拠 準拠デバイスのみアクセス許可
Hybrid Azure AD参加 オンプレミスADとEntra IDの両方に参加 社内管理デバイスの識別
デバイスフィルター デバイス属性に基づくフィルタリング 特権アクセスワークステーション

設計のポイント

  • デバイスの準拠状態チェックには、MDM/UEM（Intune等）の導入が前提
  • BYOD環境では、アプリ保護ポリシーとの組み合わせを検討する
  • デバイスプラットフォーム情報はユーザーエージェントから取得するため、完全には信頼できない

リスク条件

リアルタイムのリスク評価に基づく条件です。Microsoft Entra ID Protectionとの連携により使用可能になります。

シグナル 説明 使用例
サインインリスク 認証試行のリスクレベル（低/中/高） 高リスク時のMFA強制
ユーザーリスク ユーザーアカウントの侵害可能性 高リスクユーザーのパスワード変更要求

リスク検出の例

サインインリスクとして検出される異常行動の例：

  • 通常と異なる場所からのサインイン
  • 匿名IPアドレス（Tor等）からのアクセス
  • 不可能なトラベル（物理的に移動不可能な時間での場所変更）
  • マルウェアにリンクしたIPアドレス
  • パスワードスプレー攻撃パターン
flowchart LR
    subgraph detection["リスク検出"]
        signin["サインイン行動"]
        ml["機械学習分析"]
        threat["脅威インテリジェンス"]
    end
    
    subgraph risk["リスクレベル"]
        low["低リスク"]
        medium["中リスク"]
        high["高リスク"]
    end
    
    subgraph response["対応アクション"]
        allow["アクセス許可"]
        mfa["MFA要求"]
        block["アクセスブロック"]
        pwchange["パスワード変更要求"]
    end
    
    detection --> risk
    low --> allow
    medium --> mfa
    high --> block
    high --> pwchange

アクセス制御のオプション

条件が一致した場合に適用できるアクセス制御には、「許可コントロール」と「セッションコントロール」の2種類があります。

許可コントロール（Grant Controls）

アクセスを許可する際に満たすべき要件を定義します。

コントロール 説明
アクセスをブロック 条件に一致するアクセスを完全にブロック
多要素認証を要求 MFAの完了を必須とする
認証強度を要求 特定の認証方法（FIDO2等）を必須とする
デバイスの準拠を要求 Intuneポリシー準拠デバイスのみ許可
Hybrid Azure AD参加を要求 ドメイン参加デバイスのみ許可
承認されたクライアントアプリを要求 特定のアプリ（Outlook等）からのみ許可
アプリ保護ポリシーを要求 MAMポリシー適用アプリからのみ許可
パスワード変更を要求 パスワードの即座の変更を強制
利用規約への同意を要求 利用規約への同意を必須とする

複数のコントロールを組み合わせる場合、「すべてを要求（AND）」または「いずれかを要求（OR）」を選択できます。

セッションコントロール（Session Controls）

アクセス許可後のセッション動作を制御します。

コントロール 説明
アプリの条件付きアクセス制御 Microsoft Defender for Cloud Appsと連携したセッション制御
サインイン頻度 再認証を要求する間隔を指定
永続的ブラウザセッション ブラウザを閉じた後もセッションを維持するか制御
継続的アクセス評価 リアルタイムでのセッション取り消しを有効化

サインイン頻度の設計ガイドライン

シナリオ 推奨頻度
一般的な業務アプリ 24時間〜7日
機密性の高いアプリ 1〜8時間
特権管理操作 毎回認証（0時間）
信頼されたデバイス 90日まで延長可

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

段階的なポリシー展開

条件付きアクセスポリシーは強力なツールですが、誤った設定は業務に深刻な影響を与える可能性があります。以下の手順で段階的に展開することを推奨します。

flowchart LR
    subgraph phase1["フェーズ1"]
        design["ポリシー設計"]
        report["レポート専用モード"]
    end
    
    subgraph phase2["フェーズ2"]
        pilot["パイロットグループ<br/>で有効化"]
        monitor["影響監視"]
    end
    
    subgraph phase3["フェーズ3"]
        expand["対象拡大"]
        tune["調整"]
    end
    
    subgraph phase4["フェーズ4"]
        full["全ユーザーに<br/>展開"]
    end
    
    phase1 --> phase2 --> phase3 --> phase4

レポート専用モードの活用

Microsoft Entra Conditional Accessでは、ポリシーを「レポート専用」モードで作成できます。このモードでは、ポリシーは実際には適用されませんが、サインインログにポリシーが適用された場合の結果が記録されます。これにより、本番適用前に影響範囲を把握できます。

推奨されるベースラインポリシー

組織のセキュリティベースラインとして、以下のポリシーを検討してください。

セキュリティ基盤ポリシー

ポリシー 対象 制御
管理者にMFAを要求 すべての管理者ロール MFA必須
すべてのユーザーにMFAを要求 すべてのユーザー MFA必須（段階的展開）
レガシ認証をブロック すべてのユーザー レガシプロトコルをブロック
セキュリティ情報登録の保護 すべてのユーザー MFA登録時に信頼された場所またはMFAを要求
高リスクサインインへの対応 すべてのユーザー 高リスク時にMFAまたはブロック

追加の保護ポリシー

ポリシー 対象 制御
Azure管理へのMFA要求 Azure管理者 Azure Portal/CLI/PowerShellアクセス時にMFA
機密アプリへのアクセス制限 指定アプリにアクセスするユーザー 準拠デバイス＋MFA
ゲストアクセスの制限 外部ユーザー MFA＋利用規約への同意
特定国からのアクセスブロック すべてのユーザー 許可国以外からのブロック

緊急アクセスアカウントの保護

条件付きアクセスポリシーの設定ミスにより、すべての管理者がロックアウトされるリスクがあります。これを防ぐため、緊急アクセスアカウント（Break Glass Account）を用意し、ポリシーから除外することが重要です。

緊急アクセスアカウントの要件

  • クラウド専用アカウント（オンプレミスADに依存しない）
  • 少なくとも2つのアカウントを作成
  • 長く複雑なパスワードを使用
  • パスワードは安全な場所に保管（金庫等）
  • すべての条件付きアクセスポリシーから除外
  • 使用時にアラートを発報する監視を設定
  • 定期的に動作確認を実施

Microsoft Entra Conditional Accessでの実装

Microsoft Entra Conditional Access（旧Azure AD条件付きアクセス）は、Microsoft 365やAzureサービスへのアクセス制御を提供するクラウドサービスです。

ライセンス要件

条件付きアクセスを使用するには、以下のいずれかのライセンスが必要です。

  • Microsoft Entra ID P1以上
  • Microsoft 365 Business Premium
  • Microsoft 365 E3/E5

リスクベースの条件付きアクセス（サインインリスク、ユーザーリスク）を使用するには、Microsoft Entra ID P2が必要です。

ポリシー作成の基本手順

Microsoft Entra管理センターでの条件付きアクセスポリシー作成手順を解説します。

1. 管理センターへのアクセス

Microsoft Entra管理センター（https://entra.microsoft.com）にサインインし、「保護」>「条件付きアクセス」>「ポリシー」に移動します。

2. 新しいポリシーの作成

「新しいポリシー」を選択し、以下の項目を設定します。

割り当て（Assignments）

名前: 管理者にMFAを要求

ユーザーまたはワークロードID:
  - 対象: ディレクトリロール > グローバル管理者、特権認証管理者...
  - 除外: 緊急アクセスアカウント

ターゲットリソース:
  - 対象: すべてのクラウドアプリ

条件:
  - ネットワーク: すべてのネットワーク

アクセス制御（Access Controls）

許可:
  - アクセスを許可する
  - 多要素認証を要求する

セッション:
  - サインインの頻度: 4時間

ポリシーの有効化

ポリシーの有効化: レポート専用（テスト時）
                 オン（本番適用時）

What Ifツールによるテスト

What Ifツールを使用すると、特定のユーザーやシナリオでポリシーがどのように評価されるかをシミュレーションできます。

テスト手順

  1. 「条件付きアクセス」>「What If」に移動
  2. テストするユーザー、アプリ、条件を指定
  3. 「What If」をクリックして結果を確認
  4. 適用されるポリシーと適用されないポリシーが表示される

本番環境に影響を与えることなくポリシーの動作を確認できるため、新規ポリシー作成時や変更時には必ず実施することを推奨します。

サインインログでの確認

ポリシーの実際の動作は、サインインログで確認できます。

確認項目

項目 説明
条件付きアクセス 適用されたポリシーの一覧
許可の制御 要求された制御と結果
セッションの制御 適用されたセッション制御
レポート専用 レポート専用モードでの評価結果

Google BeyondCorpによるコンテキストアウェアアクセス

Google BeyondCorpは、Googleが自社で実装したゼロトラストモデルを製品化したものです。VPNを使用せずに、ユーザーとデバイスのコンテキストに基づいてアクセス制御を行います。

BeyondCorpの基本原則

BeyondCorpは以下の原則に基づいています。

  • 接続しているネットワークによって、サービスへのアクセス可否が左右されない
  • サービスへのアクセス権は、ユーザーとデバイスからのコンテキスト情報に基づいて付与される
  • サービスへのアクセスは認証、認可、暗号化される

Chrome Enterprise Premiumによる実装

Google BeyondCorp Enterpriseは、Chrome Enterprise Premiumとして提供されています。主要な機能は以下の通りです。

コンテキストアウェアアクセス

以下のシグナルを評価してアクセス制御を行います。

シグナル 説明
ユーザーID Cloud Identityによる認証
デバイスの状態 エンドポイント検証による評価
デバイスのセキュリティ状態 OSバージョン、暗号化状態、パスワード設定等
IPアドレス/地理的位置 アクセス元のネットワーク情報
アクセス先アプリケーション Google Workspace、その他のWebアプリ

Identity-Aware Proxy（IAP）

IAPは、アプリケーションの手前でアクセス制御を行うリバースプロキシです。アプリケーションを変更することなく、コンテキストアウェアアクセスを適用できます。

flowchart LR
    user["ユーザー"] --> iap["Identity-Aware<br/>Proxy"]
    iap --> |"認証・認可"| context["コンテキスト評価<br/>- ユーザーID<br/>- デバイス状態<br/>- ネットワーク"]
    context -->|"許可"| app["アプリケーション<br/>（GCP/オンプレミス）"]
    context -->|"拒否"| block["アクセス拒否"]

Microsoft Entra IDとの比較

項目 Microsoft Entra ID Google BeyondCorp
主な対象 Microsoft 365、Azure、SaaS Google Workspace、GCP、Webアプリ
デバイス管理連携 Intune Endpoint Verification
リスク評価 Entra ID Protection Google Security Operations
オンプレミスアプリ Application Proxy Identity-Aware Proxy
ブラウザ保護 Edge連携 Chrome Enterprise

条件付きアクセスの運用

定期的なレビュー

条件付きアクセスポリシーは、一度設定して終わりではありません。以下の観点で定期的にレビューを行います。

レビュー項目

項目 頻度 確認内容
ポリシーの有効性 月次 サインインログでの適用状況
除外アカウント 四半期 除外の妥当性、緊急アカウントの動作確認
信頼された場所 四半期 IP範囲の最新性、不要な場所の削除
新規アプリケーション 随時 新しいアプリへのポリシー適用
セキュリティインシデント 随時 インシデント発生時のポリシー見直し

トラブルシューティング

条件付きアクセスに関する問題が発生した場合の確認手順です。

1. サインインログの確認

  • 失敗したサインインを特定
  • 適用されたポリシーを確認
  • 失敗の理由（MFA未完了、デバイス非準拠等）を特定

2. What Ifツールでの再現

  • 問題のユーザー、条件で評価
  • 想定通りのポリシーが適用されるか確認

3. よくある問題と対処

問題 原因 対処
予期しないMFA要求 信頼された場所の設定漏れ ネットワーク条件を確認
アクセスブロック ポリシーの条件設定ミス What Ifで評価、ポリシー修正
準拠デバイス判定失敗 Intuneとの同期遅延 デバイス側で同期実行
ゲストユーザーの問題 外部ユーザー設定の不備 外部コラボレーション設定を確認

まとめ

条件付きアクセスポリシーは、ゼロトラストセキュリティを実現するための中核機能です。本記事で解説した内容を以下にまとめます。

条件付きアクセスの本質

  • if-thenステートメントによる動的アクセス制御
  • 複数のシグナルを統合的に評価してアクセス判断
  • ゼロトラストのPolicy Decision Point（PDP）として機能

主要なシグナル

  • ユーザーとグループ（誰が）
  • 対象アプリケーション（何に）
  • ネットワーク条件（どこから）
  • デバイス条件（何で）
  • リスク条件（どのような状況で）

設計のポイント

  • レポート専用モードで十分にテストしてから本番適用
  • 緊急アクセスアカウントは必ずポリシーから除外
  • ベースラインポリシーを基盤として段階的に展開
  • 定期的なレビューと継続的な改善

条件付きアクセスを適切に設計・運用することで、ユーザーの利便性を損なうことなく、組織のセキュリティを大幅に向上させることができます。まずはベースラインポリシーから始め、組織の要件に応じて段階的に拡張していくことをお勧めします。

参考リンク