Azure Entra ID 条件付きアクセス ポリシー設計の原則と実践

Tech

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

Azure Entra ID 条件付きアクセス ポリシー設計の原則と実践

Azure Entra ID（旧 Azure AD）の条件付きアクセス（Conditional Access: CA）は、ゼロトラストアーキテクチャを実現するための重要なツールです。適切なポリシー設計は、セキュリティ体制を強化し、ユーザーエクスペリエンスを最適化する上で不可欠です。本稿では、クラウドアーキテクトの視点から、条件付きアクセス ポリシーの設計原則、具体的な設定、運用、セキュリティ、コスト、および注意すべき落とし穴について解説します。

1. アーキテクチャ

1.1. 条件付きアクセスの役割

条件付きアクセスは、Entra IDにおける認証後のアクセス決定を制御するポリシーエンジンです。ユーザーのサインイン試行時に、場所、デバイスの状態、アプリケーション、リスクレベルなどの条件に基づいて、多要素認証（MFA）の要求、デバイス準拠の要求、アクセスブロックなどの制御を適用します。これにより、適切な状況でのみ適切なアクセスを許可し、リスクベースのセキュリティを実現します[1]。

1.2. Entra IDとの連携

条件付きアクセスはEntra IDのコア機能として組み込まれており、Entra IDに登録されたユーザー、グループ、アプリケーション、デバイス、リスクシグナルと密接に連携します。アイデンティティはEntra IDで管理され、認証プロトコル（OAuth 2.0、SAMLなど）を通じてアクセス要求が行われる際に、CAポリシーが評価されます。Entra IDの監査ログやサインインログは、CAポリシーの評価結果を詳細に記録し、運用監視に利用されます[7]。

1.3. フローチャート：ユーザー認証とポリシー評価

以下のフローチャートは、ユーザーがクラウドアプリケーションにアクセスする際の条件付きアクセス ポリシーの評価プロセスを示します。

graph TD
    A["ユーザーがクラウドアプリにアクセスを試行"] --> B{"Entra IDによる認証開始"};
    B --> C{"条件付きアクセス ポリシーを評価"};
    C --|ポリシーの条件に一致| D{"アクセス制御の適用"};
    C --|ポリシーの条件に一致しない| F{"アクセス許可"};
    D --|多要素認証 (MFA) を要求| E1["MFAの実施"];
    D --|デバイス準拠を要求| E2["デバイス準拠の確認"];
    D --|ハイブリッド Azure AD 参加デバイスを要求| E3["ハイブリッドAD参加の確認"];
    D --|セッション制御を適用| E4["Defender for Cloud Appsによるセッション制御"];
    E1 --> G{"アクセス決定"};
    E2 --> G;
    E3 --> G;
    E4 --> G;
    F --> G;
    G --|許可| H["アプリにアクセス"];
    G --|拒否| I["アクセス拒否"];

2. 設定手順

2.1. 前提条件と管理者ロール

条件付きアクセス機能を利用するには、Azure Entra ID P1 または P2 ライセンスが必要です[1]。P2ライセンスは、Identity ProtectionによるリスクベースのCAポリシーなど、より高度な機能を提供します。ポリシーを管理するユーザーには、条件付きアクセス管理者、セキュリティ管理者、または全体管理者のEntra IDロールが付与されている必要があります。

2.2. ポリシー設計の段階的アプローチ

条件付きアクセス ポリシーの設計は、以下の段階で進めることが推奨されます[3]。

  1. 要件定義: 保護対象のリソース、ユーザーグループ、アクセスシナリオ、セキュリティ要件（例: MFA必須化、信頼済みデバイスからのアクセスのみ許可）を明確にする。

  2. ベースラインポリシーの策定: すべてのユーザーに適用される一般的なセキュリティ要件（例: すべての管理者アカウントにMFAを要求）を定義する。

  3. 特定のシナリオポリシー: 高リスクユーザー、機密性の高いアプリケーション、特定の場所からのアクセスなど、個別のシナリオに対応するポリシーを作成する。

  4. 「レポートのみ」モードでのテスト: 新しいポリシーはまず「レポートのみ」モードでデプロイし、影響範囲を監視する。Entra IDサインインログで影響を確認し、必要に応じて調整する。

  5. 段階的デプロイ: 小規模なユーザーグループから適用を開始し、問題がないことを確認しながら段階的に展開範囲を広げる。

2.3. PowerShellを用いたポリシーデプロイ例

ここでは、PowerShellとMicrosoft Graph API (Microsoft.Graphモジュール) を使用して、特定のユーザーが信頼できない場所から特定のクラウドアプリケーションにアクセスする場合にMFAを要求する条件付きアクセス ポリシーを作成する例を示します。このスクリプトは、ポリシーを「レポートのみ」モードで作成します。

# PowerShellスクリプト: 条件付きアクセス ポリシーの作成

# 前提条件: Microsoft.Graphモジュールのインストール


# Install-Module Microsoft.Graph -Scope CurrentUser

# Microsoft Graphへの接続 (必要なアクセス許可: Policy.ReadWrite.ConditionalAccess)


# 接続時にブラウザが開き、認証が求められます。

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

# ポリシーの詳細を定義

$policyName = "MFARequired_UntrustedLocations_ForSpecificUsers"
$policyDescription = "特定のユーザーが信頼されていない場所から指定アプリにアクセスする場合にMFAを要求"

# ポリシーを適用するユーザー/グループの定義


# 注意: 実際のユーザーUPNまたはグループIDに置き換えてください。


# ここでは例として特定のユーザーとグループを設定していますが、


# "All" を指定してすべてのユーザーに適用することも可能です。

$includedUsers = @(
    "user1@contoso.com", # ターゲットユーザーのUPN
    "user2@contoso.com"
)

# $includedGroups = @("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx") # ターゲットグループのID

# ポリシーから除外するユーザー/グループ (オプション)


# 緊急アクセスアカウントなどはここに追加することが強く推奨されます。

$excludedUsers = @()
$excludedGroups = @()

# ポリシーを適用するクラウドアプリケーションの定義


# "All" はすべてのクラウドアプリに適用。特定のアプリIDを指定することも可能。


# 例: "00000003-0000-0000-c000-000000000000" は Microsoft Graph

$includedApps = @("All")
$excludedApps = @() # 除外するアプリ (例: 内部ツールなど)

# ポリシーを適用する場所の定義


# "All" はすべての場所。特定の「名前付き場所」のIDを指定可能。


# 「名前付き場所」は信頼できるIP範囲や国を定義するために使用されます。


# ここではすべての場所を含み、信頼できる場所を除外することで「信頼できない場所」を表現します。

$includedLocations = @("All")

# 以下は例: 事前に設定した信頼できるネットワークを表す「名前付き場所」のIDに置き換える

$excludedLocations = @("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx") # 信頼できる場所のID

# ポリシーの条件を構築

$conditions = @{
    users = @{
        includeUsers = if ($includedUsers.Count -gt 0) {$includedUsers} else {$null}

        # includeGroups = if ($includedGroups.Count -gt 0) {$includedGroups} else {$null}

        excludeUsers = if ($excludedUsers.Count -gt 0) {$excludedUsers} else {$null}
        excludeGroups = if ($excludedGroups.Count -gt 0) {$excludedGroups} else {$null}
    }
    applications = @{
        includeApplications = $includedApps
        excludeApplications = $excludedApps
    }
    locations = @{
        includeLocations = $includedLocations
        excludeLocations = $excludedLocations
    }

    # 他の条件 (deviceStates, clientAppTypes, signInRiskLevelsなど) を追加可能

}

# アクセス制御の定義 (何を要求するか)


# builtInControls: mfa, compliantDevice, domainJoinedDevice, approveApplication, termsOfUse

$grantControls = @{
    operator = "OR" # AND: すべての制御を要求, OR: いずれかの制御を要求
    builtInControls = @("mfa") # 多要素認証を要求
}

# ポリシー本体を構築

$policyBody = @{
    displayName = $policyName
    description = $policyDescription

    # 初期状態は「レポートのみ」に設定し、テスト後に「enabled」に変更することを推奨

    state = "enabledForReportingButNotEnforced" # "enabled", "disabled", "enabledForReportingButNotEnforced"
    conditions = $conditions
    grantControls = $grantControls
}

Write-Host "条件付きアクセス ポリシー '$policyName' の作成を開始します..."

try {
    $createdPolicy = New-MgConditionalAccessPolicy -BodyParameter $policyBody
    Write-Host "ポリシーが正常に作成されました。ID: $($createdPolicy.Id)"
    Write-Host "状態: $($createdPolicy.State)"
}
catch {
    Write-Error "ポリシーの作成に失敗しました: $($_.Exception.Message)"
}

# Microsoft Graphから切断

Disconnect-MgGraph

3. 運用監視

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

条件付きアクセスの運用監視には、Entra IDのサインインログと監査ログが不可欠です。

  • サインインログ: 各サインイン試行の詳細（ユーザー、IPアドレス、デバイス、アプリケーション、適用されたCAポリシー、結果）を確認できます。これにより、ポリシーが意図通りに機能しているか、または予期せぬアクセスブロックが発生していないかを検証できます[7]。

  • 監査ログ: 管理者によるCAポリシーの作成、変更、削除などの操作が記録されます。

これらのログは、Azure Portal (portal.azure.com) の「Azure Entra ID」->「監視と正常性」->「サインインログ」または「監査ログ」からアクセスできます。

3.2. 条件付きアクセス レポートと「What If」ツール

  • 条件付きアクセス レポート: Azure Portalの「Azure Entra ID」->「保護」->「条件付きアクセス」->「概要」で、適用されたポリシーの概要と傾向を確認できます。

  • 「What If」ツール: 新しいポリシーをデプロイする前や、既存のポリシーが特定のユーザーやシナリオにどのように影響するかをシミュレーションするために使用します[3]。ユーザー、クラウドアプリ、デバイス情報などの条件を入力することで、どのポリシーが適用され、どのような制御が課されるかを事前に確認できます。これは、誤った設定によるロックアウトを避けるために極めて重要です。

3.3. Azure Monitorとの連携

Entra IDのログは、Azure MonitorのLog Analyticsワークスペースに送信し、カスタムダッシュボードやアラートを作成できます。例えば、特定のCAポリシーによってアクセスがブロックされたイベントの急増を検知した場合に、アラートを送信するよう設定することで、インシデントに迅速に対応できます。

3.4. SLAとDR戦略

Azure Entra ID自体は、Microsoftが提供するグローバルなサービスであり、高い可用性と回復性（SLA 99.99%）を備えています。ユーザー側で直接バックアップやDR戦略を講じる必要は通常ありません。ただし、ポリシー設定の誤りによるアクセス不能状態は、ビジネス継続性に大きな影響を与えます。そのため、ポリシー設計とデプロイのプロセスには、緊急アクセスアカウントの保護（後述）や、段階的なデプロイ、ロールバック計画を含めることが重要です。

4. セキュリティ

4.1. ゼロトラストと最小特権の原則

条件付きアクセスは、ゼロトラストモデルの「決して信頼せず、常に検証する (Never Trust, Always Verify)」を具現化します。ユーザーがどこからアクセスし、どのデバイスを使用し、どのようなリスクがあるかを常に評価し、必要な最小限のアクセス権限を付与（最小特権の原則）します。これにより、多層防御の一部として、不正アクセスやデータ漏洩のリスクを大幅に低減します。

4.2. Microsoft Defender for Cloud Appsとの連携

Azure Entra ID P2ライセンスを保有している場合、条件付きアクセスはMicrosoft Defender for Cloud Apps (旧 MCAS) と連携し、セッション制御を提供できます[5]。これにより、ユーザーがクラウドアプリケーションにアクセスした後も、セッションの監視やリアルタイムでの制御（例: 機密ファイルのダウンロードブロック、特定のアクションの読み取り専用化）が可能になります。これは、シャドーITの検出やデータ漏洩防止において強力なセキュリティ層を提供します。

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

非常に重要: 全体管理者アカウントなど、全ての条件付きアクセス ポリシーから少なくとも2つの緊急アクセスアカウントを常に除外してください。これにより、ポリシーの誤設定や、Entra IDの不具合によって通常の管理者アカウントがロックアウトされた場合でも、システムにアクセスし、問題を修正する手段を確保できます。これらのアカウントは厳重に管理し、利用をログに記録し、定期的に資格情報を更新する必要があります。

5. コスト最適化

5.1. Entra ID P1/P2 ライセンスの理解

条件付きアクセス機能は、Azure Entra ID P1またはP2ライセンスに含まれます[1]。組織の規模、必要な機能（例: Identity ProtectionベースのリスクベースCAが必要な場合はP2）、およびセキュリティ要件に基づいて適切なライセンスを選択することが、コスト最適化の第一歩です。

  • Entra ID Free/Microsoft 365 Free: 条件付きアクセスは利用できません。

  • Entra ID P1/Microsoft 365 Business Premium: 基本的な条件付きアクセス機能が利用可能です。

  • Entra ID P2/Microsoft 365 E5: リスクベースの条件付きアクセス、Identity Protectionなどの高度なセキュリティ機能が利用可能です。

不必要なP2ライセンスを割り当てないように、ユーザーごとの要件を正確に評価することが重要です。

5.2. ポリシー設計と管理コスト

ポリシーが複雑になりすぎると、管理コストが増大し、予期せぬ動作や競合のリスクが高まります。

  • ポリシーの統合と簡素化: 類似の条件や制御を持つポリシーは統合を検討し、ポリシーの数を最小限に保ちます。

  • 標準化: 可能な限り標準的なポリシーテンプレート（例: すべての管理者アカウントにMFAを要求、すべてのユーザーにリスクベースのMFAを要求など）を採用し、一貫性のあるセキュリティポリシーを維持します[2]。

  • 「レポートのみ」モードの活用: 新規ポリシー導入前に影響を正確に把握することで、運用中のトラブルシューティングにかかる時間とコストを削減できます。

6. よくある落とし穴と対策

6.1. 過度な制限とロックアウト

最も一般的な落とし穴は、誤ったポリシー設定により、正当なユーザーや管理者自身がアクセスできなくなる「ロックアウト」です。

  • 対策:

    • 緊急アクセスアカウントの除外は絶対不可欠です。

    • 「レポートのみ」モードで徹底的にテストし、影響を評価します。

    • 少数のテストユーザーから段階的にデプロイします。

    • 信頼できるIPアドレス範囲からのアクセスを許可する「名前付き場所」を定義し、管理者のアクセスを保証します。

6.2. ポリシーの競合と評価順序

複数のポリシーが適用される場合、その評価順序や競合の解決方法を理解していないと、意図しない結果を招く可能性があります。

  • 対策:

    • 条件付きアクセスは、すべてのポリシーを評価し、拒否条件が最も優先されます。次に、許可条件が評価され、AND条件の場合はすべての条件を満たす必要があります。

    • ポリシーは可能な限り明確にし、重複や競合を避けるように設計します。

    • 「What If」ツールを使用して、特定のシナリオでどのポリシーが適用され、最終的なアクセス決定がどうなるかを事前に確認します。

6.3. ゲストユーザーと外部連携

外部連携（B2B Collaboration）で招待されたゲストユーザーに対する条件付きアクセス ポリシーの適用を見落としがちです。

  • 対策:

    • ゲストユーザーにも組織のセキュリティ要件を適用するため、専用のポリシーグループを作成するか、既存ポリシーにゲストユーザーを含めることを検討します。

    • 外部連携の設定で、ゲストユーザーにMFAを必須化するなど、Entra IDレベルでのセキュリティ制御も併用します。

7. まとめ

Azure Entra IDの条件付きアクセスは、現代の複雑なクラウド環境におけるセキュリティの要石です。適切なポリシー設計は、組織のセキュリティ体制を大幅に強化し、同時にユーザーの生産性を維持するための鍵となります。本稿で紹介したアーキテクチャ、設定手順、運用監視、セキュリティの考慮事項、コスト最適化、そしてよくある落とし穴とその対策を参考に、組織のニーズに合致した堅牢かつ柔軟な条件付きアクセス ポリシーを設計・運用してください。特に、「レポートのみ」モードでの徹底的なテストと緊急アクセスアカウントの保護は、常に最優先事項として考慮すべきです。

参照元 [1] Microsoft. (2024年7月22日 JST). Azure AD 条件付きアクセスとは. Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview [2] Microsoft. (2024年7月18日 JST). 条件付きアクセスの一般的なポリシー. Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/howto-conditional-access-policy-common [3] Microsoft. (2024年7月15日 JST). 条件付きアクセスの計画とテスト. Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/plan-conditional-access [4] Microsoft. (2024年6月28日 JST). Microsoft Graph を使用して条件付きアクセス ポリシーを管理する. Microsoft Learn. https://learn.microsoft.com/ja-jp/graph/api/resources/conditionalaccesspolicy-overview?view=graph-rest-1.0 [5] Microsoft. (2024年6月20日 JST). Azure AD 条件付きアクセスにおけるセッション制御. Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-conditional-access-session [6] Microsoft. (2024年5月30日 JST). Azure AD Connect 同期エラーのトラブルシューティング. Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/tshoot-connect-sso [7] Microsoft. (2024年7月10日 JST). Azure AD の運用と監視. Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/active-directory/fundamentals/active-directory-monitor-health

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

コメント

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