Azure AD条件付きアクセス設計のベストプラクティス

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure AD条件付きアクセス設計のベストプラクティス

Azure AD（現Microsoft Entra ID）の条件付きアクセス（Conditional Access, CA）は、Microsoft Entra IDに接続されたアプリケーションへのアクセスを制御するための強力なツールです。ユーザー、デバイス、場所、アプリケーションなどの条件に基づいて、多要素認証（MFA）の要求、デバイスの準拠、セッションの制限などのアクセス制御を適用できます。本記事では、条件付きアクセス設計のアーキテクチャから設定手順、運用監視、セキュリティ、コスト、そして一般的な落とし穴まで、包括的なベストプラクティスを解説します。

1. アーキテクチャ

Azure AD条件付きアクセスは、Microsoft Entra IDのセキュリティフレームワークの中核をなし、ゼロトラスト原則を実装するための重要な要素です。アクセス要求のたびにリアルタイムでポリシーが評価され、設定された条件に基づいてアクセスを許可、制限、またはブロックします。

1.1. 条件付きアクセスの仕組み

条件付きアクセスは以下の主要な要素で構成されます[1]:

  • ユーザーとグループ: ポリシーの適用対象となるユーザーやグループ。緊急アクセスアカウントは常に除外することを強く推奨します。

  • クラウドアプリまたはアクション: ポリシーが適用されるアプリケーション（例: Microsoft 365, Azure Portal, Salesforce）またはユーザーアクション（例: ユーザー登録時のMFA要求）。

  • 条件: アクセス要求の状況を評価する要素。

    • デバイスプラットフォーム: iOS, Android, Windowsなど。

    • 場所: 特定のIPアドレス範囲、国/地域。

    • クライアントアプリ: ブラウザ、モバイルアプリ、デスクトップクライアントなど。

    • サインインリスク: Microsoft Entra ID Identity Protectionによって検出されるリスクレベル（P2ライセンスが必要）。

    • デバイスの状態: Microsoft Entraハイブリッド参加済みまたは準拠デバイス。

  • 付与制御: 条件が満たされた場合に適用される制御。

    • MFAの要求: 多要素認証を必須とする。

    • デバイスを準拠としてマーク済みであることの要求: Intuneなどによるデバイス準拠を必須とする。

    • Microsoft Entraハイブリッド参加済みデバイスの要求: ドメイン参加済みデバイスからのアクセスを必須とする。

    • 承認済みクライアントアプリの要求: 特定の信頼されたクライアントアプリからのアクセスを必須とする。

  • セッション制御: サインイン後に適用される制御。

    • アプリ強制制限: Microsoft Defender for Cloud Appsとの連携。

    • サインイン頻度: ユーザーが認証情報を再入力する頻度を決定。

    • 永続的なブラウザー セッション: ブラウザーを閉じた後のセッション継続を許可するか否か。

1.2. ライセンス要件

条件付きアクセス機能を利用するには、Microsoft Entra ID P1またはP2ライセンスが必要です[4]。

  • P1: 基本的な条件付きアクセス機能を提供。場所、デバイスプラットフォーム、クライアントアプリなどに基づくポリシー。

  • P2: P1の機能に加えて、Microsoft Entra ID Identity Protectionの機能（ユーザーリスク、サインインリスク）に基づく条件付きアクセスポリシーが利用可能。これにより、より高度なリスクベースのアクセス制御が可能になります。

1.3. 条件付きアクセス ポリシーの評価フロー

以下に、条件付きアクセス ポリシーの評価フローをMermaidのフローチャートで示します。

flowchart TD
    User["ユーザー"] -->|サインイン要求| EntraID["Microsoft Entra ID"]
    EntraID -->|ポリシー評価| CAPolicy{"条件付きアクセス ポリシー"}
    CAPolicy -- ポリシー有効 --> Conditions{"条件一致?"}
    CAPolicy -- ポリシー無効または除外 --> AccessGrant["アクセス許可"]

    Conditions -- 条件一致 (はい) --> GrantControls["付与制御の適用"]
    Conditions -- 条件一致 (いいえ) --> AccessDeny["アクセス拒否"]

    GrantControls -->|すべての制御を満たす?| SessionControls{"セッション制御の適用"}
    GrantControls -- 満たさない --> AccessDeny

    SessionControls -->|制御を適用| AccessGrant
    SessionControls -- 制御なし --> AccessGrant

  • User: アクセスを試みるユーザーです。

  • EntraID: Microsoft Entra ID（旧Azure AD）が認証要求を受け取ります。

  • CAPolicy: 設定された条件付きアクセス ポリシーが評価されます。ポリシーが有効で、対象ユーザー/アプリに適用される場合、条件評価に進みます。ポリシーが無効な場合や、ユーザーがポリシーの適用から除外されている場合は、そのままアクセスが許可されます。

  • Conditions: デバイス、場所、リスクなどの条件が評価されます。条件が一致しない場合、アクセスは拒否されます。

  • GrantControls: 条件が一致した場合、MFAの要求や準拠デバイスの要求などの付与制御が適用されます。すべての付与制御を満たさない場合、アクセスは拒否されます。

  • SessionControls: 付与制御を満たした後、セッション制御（サインイン頻度、アプリ強制制限など）が適用されます。

  • AccessGrant: すべてのポリシーをクリアした場合、アクセスが許可されます。

  • AccessDeny: ポリシーのどこかの段階で要件を満たさなかった場合、アクセスは拒否されます。

2. 設定手順

条件付きアクセスの設計では、まず組織のセキュリティ要件を明確にし、最も影響の少ないポリシーから段階的に導入することが重要です[2]。

2.1. 緊急アクセスアカウントの除外

いかなる条件付きアクセス ポリシーも、最低2つの「緊急アクセスアカウント」または「ブレイクグラスアカウント」を適用から除外する必要があります。これにより、誤ったポリシー設定やシステム障害が発生した場合でも、管理者がEntra IDにサインインできるパスを確保できます[2]。

2.2. レポート専用モードでのテスト

新しいポリシーを有効にする前に、必ず「レポート専用モード」で展開し、影響を評価してください。このモードでは、ポリシーが適用された場合に何が起こるかをログに記録しますが、実際のアクセスはブロックしません[5]。

2.3. PowerShellでのMFA要求ポリシー作成例

以下のPowerShellスクリプトは、特定の管理者グループに対して、すべてのクラウドアプリへのアクセス時にMFAを要求する条件付きアクセス ポリシーを作成する例です。ポリシーはまず「レポート専用モード」で作成されます。

# スクリプトを実行する前に、Microsoft Graph PowerShell SDKがインストールされていることを確認してください。


# Install-Module -Name Microsoft.Graph -Scope CurrentUser

# 管理者権限でConnect-MgGraphを実行し、必要なスコープを付与してください。


# Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# 変数の定義

$policyName = "Require MFA for Admin Group Access"

# 対象となる管理者グループのオブジェクトIDを置き換えてください。


# Get-MgGroup -DisplayName "Your Admin Group Name" | Select-Object Id で取得可能

$adminGroupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 

# 条件付きアクセス ポリシーの構成

$conditions = @{
    users = @{

        # 対象グループを指定

        includeGroups = @($adminGroupId)

        # 緊急アクセスアカウントなどを除外する場合 (例: $emergencyAccessGroupId は別途定義)


        # excludeGroups = @($emergencyAccessGroupId) 

    }
    applications = @{

        # すべてのクラウドアプリを対象

        includeApplications = @("All")
    }
    clientAppTypes = @{

        # すべてのクライアントアプリタイプを対象

        includeClientAppTypes = @("all")
    }

    # 他の条件（場所、デバイスなど）もここに追加可能


    # locations = @{


    #     includeLocations = @("AnyLocation")


    # }

}

$grantControls = @{

    # OR または AND で複数の制御を組み合わせる

    operator = "OR" 
    builtInControls = @("mfa") # MFAの要求
}

# セッション制御が必要ない場合は null を指定

$sessionControls = $null

# 条件付きアクセス ポリシーオブジェクトの作成

$conditionalAccessPolicy = @{
    displayName = $policyName

    # 初期状態は「レポート専用モード」に設定

    state = "reportOnly" 
    conditions = $conditions
    grantControls = $grantControls
    sessionControls = $sessionControls
}

# ポリシーをMicrosoft Entra IDに作成

try {
    Write-Host "Creating Conditional Access policy '$policyName' in Report-only mode..."
    $createdPolicy = New-MgIdentityConditionalAccessPolicy -BodyParameter $conditionalAccessPolicy
    Write-Host "Policy created successfully. ID: $($createdPolicy.Id)"
    Write-Host "Please test this policy thoroughly in Report-only mode before enabling it."
}
catch {
    Write-Error "Failed to create Conditional Access policy: $($_.Exception.Message)"
}

前提: Microsoft Graph PowerShell SDKがインストールされ、Policy.ReadWrite.ConditionalAccess スコープで接続されている必要があります。 出力: 新しく作成された条件付きアクセス ポリシーのIDが表示されます。 注意事項: $adminGroupId は、対象となるMicrosoft Entra IDグループのオブジェクトIDに置き換えてください。

3. 運用監視

条件付きアクセス ポリシーの効果的な運用には、継続的な監視とレビューが不可欠です。

3.1. サインインログと監査ログ

Microsoft Entra IDのサインインログと監査ログは、条件付きアクセス ポリシーがどのように適用されたかを理解するための主要な情報源です[5]。

  • サインインログ: 各サインインイベントの詳細（ユーザー、アプリ、デバイス、場所、IPアドレス）と、適用された条件付きアクセス ポリシーの結果（許可、ブロック、MFA要求など）を確認できます。

  • 監査ログ: 条件付きアクセス ポリシーの作成、変更、削除などの管理操作が記録されます。

これらのログは、Azure MonitorのLog Analyticsワークスペースに転送し、Kustoクエリを使用して詳細な分析やダッシュボード作成を行うことが推奨されます。

3.2. What Ifツール

Microsoft Entra管理センターの条件付きアクセスブレードにある「What If」ツールは、ポリシーを有効にする前に、特定のユーザーと条件の組み合わせに対してどのポリシーが適用されるかをシミュレートするのに役立ちます[5]。これにより、予期しないアクセスのブロックを防ぎ、設計を検証できます。

3.3. レポート専用モード

上記の設定手順でも触れたように、レポート専用モードはポリシーの影響を把握するために不可欠です。展開後も、既存のポリシーの変更や新しいポリシーの追加時には、このモードを活用して影響を評価してください。

3.4. アラートと自動化

Log Analyticsに転送されたログデータに基づいて、異常なサインイン試行や条件付きアクセス ポリシーの繰り返しブロックなどに対するアラートを設定できます。Azure Sentinelと連携することで、より高度な脅威検出と自動応答が可能になります。

4. セキュリティ

条件付きアクセスは、Microsoft Entra IDのセキュリティ体制を強化し、ゼロトラストアーキテクチャを実現するための中心的な要素です。

4.1. ゼロトラスト原則との連携

「決して信頼せず、常に検証する」というゼロトラスト原則に基づき、条件付きアクセスはすべてのアクセス要求を検証します。デバイスの健全性、ユーザーのリスクレベル、場所など、複数の属性を考慮してリアルタイムでアクセス判断を行います。

4.2. Identity Protectionとの連携（Entra ID P2）

Microsoft Entra ID P2ライセンスで提供されるIdentity Protectionは、ユーザーとサインインのリスクを継続的に評価し、条件付きアクセスと連携して、これらのリスクシグナルに基づいてポリシーを適用できます[4]。例えば、高リスクのサインインと判断された場合にMFAを強制したり、アクセスをブロックしたりできます。

4.3. リスクベースポリシーの導入

Identity Protectionを活用し、サインインリスクやユーザーリスクのレベルに応じて異なるアクセス要件を課すリスクベースポリシーを導入します。これにより、セキュリティとユーザビリティのバランスを取りながら、脅威に対する防御を強化できます。

4.4. 定期的なレビューと更新

組織のセキュリティ要件、アプリケーションの変更、新たな脅威に対応するため、条件付きアクセス ポリシーは定期的にレビューし、更新する必要があります。少なくとも四半期に一度は主要なポリシーを見直し、その有効性を確認してください。

5. コスト

条件付きアクセスに関連する主なコストは、Microsoft Entra IDのライセンス費用と、ログの保存および分析にかかる費用です。

5.1. Microsoft Entra ID ライセンス

  • Microsoft Entra ID P1: 条件付きアクセスの基本的な機能を提供します。通常、ユーザーあたりの月額費用がかかります。

  • Microsoft Entra ID P2: P1の機能に加えて、Identity Protectionによるリスクベースの条件付きアクセスを利用できます。P1よりも高価ですが、より高度なセキュリティ機能を提供します[4]。組織のセキュリティ要件と予算に基づいて適切なライセンスを選択してください。

5.2. ログと監視のコスト

Microsoft Entra IDのログは、Log Analyticsワークスペースに転送して長期保存や詳細分析を行うことが推奨されます。Log Analyticsの費用は、取り込まれるデータ量とデータの保持期間に基づいて発生します。

  • データ取り込み: GB単位で課金されます。ポリシーの数やユーザーアクティビティが多いほど、取り込み量が増加します。

  • データ保持: ログを長期間保持する場合、追加の費用が発生します。コンプライアンス要件に応じて保持期間を調整し、不要なデータを保持しないことでコストを最適化できます。

6. 落とし穴

条件付きアクセス設計でよくある落とし穴と、それらを回避するためのヒントを説明します。

  • 緊急アクセスアカウントのロックアウト: 最も重大な落とし穴の一つです。ポリシーから緊急アクセスアカウントを除外することを怠ると、管理者自身がテナントにサインインできなくなり、最悪の場合、サービス全体の運用が停止する可能性があります[2]。

  • 過剰なポリシーまたは広すぎる適用範囲: 「すべてのユーザー」と「すべてのクラウドアプリ」に適用されるポリシーは強力ですが、意図しないユーザーへの影響やアクセスのブロックを引き起こす可能性があります。最初は特定のグループとアプリケーションに限定して展開し、徐々に拡大することを推奨します[2]。

  • テスト不足: 新しいポリシーをレポート専用モードで十分にテストしないと、予期せぬアクセス拒否やユーザーエクスペリエンスの低下を招きます。本番環境に適用する前に、様々なシナリオで影響を確認してください。

  • デバイス状態の誤解: 「準拠デバイスを要求する」などのポリシーを使用する場合、IntuneなどのMAM/MDMソリューションでデバイスが正しく管理・登録され、準拠状態が報告されていることを確認する必要があります。

  • ポリシーの複雑化: 多数のポリシーが互いに影響し合うことで、管理が困難になり、トラブルシューティングが複雑になります。シンプルで明確なポリシー設計を心がけ、ポリシー数を最小限に保ちます。

7. まとめ

Azure AD条件付きアクセスは、現代のクラウド環境における強力なセキュリティ制御メカニズムです。ゼロトラスト原則に基づき、リアルタイムでのアクセス評価を可能にし、組織のデジタル資産を保護します。効果的な設計には、緊急アクセスアカウントの除外、レポート専用モードでの徹底的なテスト、そして段階的な展開が不可欠です。Microsoft Entra ID P2ライセンスとIdentity Protectionを組み合わせることで、リスクベースの高度なセキュリティを実現できます。運用段階では、サインインログやWhat Ifツールを活用した継続的な監視と、定期的なポリシーの見直しがセキュリティ体制維持のために重要です。適切なライセンス選択とログ管理の最適化により、コスト効率の良いセキュリティ運用を目指しましょう。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました