Azure AD条件付きアクセス（Microsoft Entra ID Conditional Access）設計とMFAの実践

Tech

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

Azure AD条件付きアクセス（Microsoft Entra ID Conditional Access）設計とMFAの実践

クラウド環境におけるセキュリティの根幹をなすのが、適切なアイデンティティとアクセス管理です。Microsoft Entra ID（旧Azure AD）の条件付きアクセス（Conditional Access: CA）は、Zero Trustの原則に基づき、特定の条件が満たされた場合にのみリソースへのアクセスを許可する強力な機能です。本記事では、クラウドアーキテクトの視点から、Microsoft Entra IDにおけるCAポリシーと多要素認証（MFA）の設計、実装、運用について実践的なアプローチを解説します。

1. アーキテクチャの概要

Microsoft Entra IDの条件付きアクセスは、ユーザー、デバイス、場所、アプリケーション、リスクレベルなどの多様なシグナル（条件）に基づいて、リソースへのアクセスを許可または拒否するアクセス制御ポリシーエンジンです。これにより、組織はセキュリティ体制を強化し、規制要件に準拠することができます。MFAは、CAポリシーの最も一般的なアクセス制御の一つであり、ユーザー認証の強度を大幅に向上させます。

条件付きアクセスフローの概念図

ユーザーがMicrosoft Entra IDで保護されたアプリケーションにアクセスしようとすると、Entra IDは設定されたCAポリシーを評価します。この評価は、以下のようなフローで実行されます。

graph TD
    A["ユーザー/デバイス"] --> |1. アクセス要求| B("Microsoft Entra ID")
    B --> |2. 認証実行| C{"認証情報提示"}
    C --> |3. ポリシー評価シグナル収集| D("条件付きアクセス ポリシーエンジン")
    D --> |4. 条件評価| E{"ポリシーの条件に一致?"}
    E -- "Yes" --> F{"アクセス制御の適用"}
    F -- "MFA要求" --> G["MFAプロンプト"]
    G --> |5. MFA成功| H["アクセス許可"]
    F -- "アクセスブロック" --> I["アクセス拒否"]
    E -- "No" --> H
    H --> J["対象アプリケーション"]
    I --> J

図1：条件付きアクセスの概要フロー

このフローでは、ユーザーからのアクセス要求に対し、Microsoft Entra IDはCAポリシーエンジンを通じて、ユーザー、デバイス、場所などのシグナルを収集し、定義された条件に照らし合わせてアクセス制御（MFA要求、アクセスブロックなど）を適用します。

アイデンティティと権限境界

  • Microsoft Entra ID: アイデンティティプロバイダーとして、ユーザーアカウント、グループ、アプリケーションを管理します。CAポリシーの評価と強制の中核を担います。

  • ロール: Microsoft Entra IDには、グローバル管理者、条件付きアクセス管理者などの組み込みロールがあります。CAポリシーの管理には、「条件付きアクセス管理者」ロールが推奨されます。

  • 条件付きアクセス (CA): アクセス要求が特定の条件を満たす場合に、MFAの強制、デバイスの準拠、セッション制御などの追加要件を課すためのポリシー定義層です。

  • Microsoft Defender for Cloud Apps (MDCA): CAポリシーと連携し、リアルタイムのセッション制御や異常検出を提供し、クラウドアプリケーションへのアクセスをさらに保護します。

2. 設定手順

ここでは、Graph APIを用いてMFAを要求するシンプルな条件付きアクセスポリシーを作成する手順を示します。このポリシーは、特定のグループのユーザーがクラウドアプリケーションにアクセスする際にMFAを強制するものです。

前提条件

  • Microsoft Entra ID P1またはP2ライセンス

  • Microsoft Graph PowerShell SDKのインストール

    Install-Module Microsoft.Graph -Scope CurrentUser

  • 適切な権限を持つアカウントでの認証（例: 条件付きアクセス管理者ロール）

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

CAポリシーの作成 (Graph API)

MFAを強制するCAポリシーを作成するには、以下のPowerShellスクリプトを実行します。この例では、「営業部」グループのメンバーが「すべてのクラウドアプリ」にアクセスする際にMFAを要求します。

# ポリシーに含めるユーザーグループのオブジェクトIDを取得（例として「営業部」グループ）


# 実際の環境に合わせてオブジェクトIDを調査してください。

$groupId = (Get-MgGroup -Filter "DisplayName eq '営業部'").Id

# 条件付きアクセスポリシー定義のJSONボディ

$policyJson = @'
{
    "displayName": "営業部MFA強制ポリシー",
    "state": "enabled", # または "enabledForReportingButNotEnforced" でレポート専用モード
    "conditions": {
        "users": {
            "includeGroups": ["{groupId}"],
            "excludeUsers": [
                "a1b2c3d4-e5f6-7890-1234-567890abcdef" # 例: 緊急アクセスアカウントの除外
            ]
        },
        "applications": {
            "includeApplications": ["All"]
        },
        "clientAppTypes": {
            "includeClientAppTypes": ["all"]
        },
        "locations": {
            "includeLocations": ["All"]
        }
    },
    "grantControls": {
        "operator": "OR",
        "builtInControls": ["mfa"]
    }
}
'@

# グループIDをJSON文字列に埋め込む

$policyBody = $policyJson.Replace("{groupId}", $groupId) | ConvertFrom-Json

# Graph APIを使用して条件付きアクセスポリシーを作成

try {
    New-MgIdentityConditionalAccessPolicy -BodyParameter $policyBody | Format-List
    Write-Host "条件付きアクセスポリシー '営業部MFA強制ポリシー' が正常に作成されました。"
} catch {
    Write-Host "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}

# MFAの認証方法ポリシーの確認/設定（ユーザーがMFAを登録できるようにする）


# これはCAポリシーとは別に設定します。

Write-Host "MFA認証方法ポリシーの確認と設定は、Microsoft Entra管理センターの [保護] > [認証方法] > [ポリシー] で行います。"
Write-Host "または、Graph APIの 'beta' エンドポイントで構成可能です。"

コメント:

  • 前提条件: Microsoft Entra ID P1/P2ライセンスとGraph SDKのインストール、適切な認証スコープが必要です。

  • 入力: $groupId にはMFAを強制したいユーザーグループのオブジェクトIDを指定します。

  • 出力: 作成されたポリシーの詳細が出力されます。エラー時にはエラーメッセージが表示されます。

  • 計算量: API呼び出し1回（O(1)）。

  • メモリ条件: 小規模なJSONボディとAPIレスポンスを処理するため、特段のメモリ要件はありません。

state を enabledForReportingButNotEnforced に設定することで、ポリシーを運用環境に展開する前に、影響をレポートで確認する「レポート専用モード」でテストできます。これにより、意図しないアクセスブロックを防げます。

3. 運用監視

条件付きアクセスとMFAの運用監視は、セキュリティ体制の維持と問題発生時の迅速な対応に不可欠です。

可観測性

  • サインインログ: Microsoft Entra IDは、すべての認証試行の詳細なログを記録します。CAポリシーがどのように評価され、MFAが要求されたか、アクセスが許可または拒否されたかを確認できます。

    • 管理センター: Microsoft Entra 管理センター > Identity > 監視と正常性 > サインインログ

    • ログエントリには、ユーザー、アプリケーション、場所、デバイスの状態、ポリシーの結果などが含まれます。

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

    • 管理センター: Microsoft Entra 管理センター > Identity > 監視と正常性 > 監査ログ

ログの出力と分析

これらのログは、Log Analyticsワークスペースに診断設定として転送することで、高度なクエリ（KQL）やアラート設定が可能になります。

# Microsoft Entra サインインログと監査ログをLog Analyticsワークスペースに転送する診断設定の例


# 事前にLog Analyticsワークスペースを作成しておく必要があります。

$workspaceId = "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroup}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}" # ワークスペースIDを指定

$resourceId = "/providers/Microsoft.Aadiam/diagnosticSettings/serviceLogs"

New-AzDiagnosticSetting -Name "EntraID-Logs-to-LogAnalytics" `
    -ResourceId "/providers/Microsoft.Aadiam/diagnosticSettings/serviceLogs" ` # Entra IDの特定のリソースID
    -WorkspaceId $workspaceId `
    -Categories "SignInLogs", "AuditLogs" ` # 転送するログカテゴリ
    -MetricCategory "AllMetrics" `
    -Enabled $true

Write-Host "Microsoft Entra IDのサインインログと監査ログの診断設定が完了しました。"

コメント:

  • 前提条件: Azureサブスクリプション、Log Analyticsワークスペース、Az.Monitorモジュール（Install-Module Az.Monitor）。

  • 入力: $workspaceId にLog AnalyticsワークスペースのリソースIDを正確に指定する必要があります。resourceIdはMicrosoft Entra IDの診断設定における特殊なIDです。

  • 出力: 診断設定の成功メッセージ。

  • 計算量: API呼び出し1回（O(1)）。

KQLクエリ例（過去24時間でMFAが要求され、かつ失敗したサインインを検索）:

SigninLogs
| where TimeGenerated > ago(24h)
| where ConditionalAccessPolicies has "MFA was required"
| where Status.errorCode != 0
| project TimeGenerated, UserDisplayName, UserPrincipalName, AppDisplayName, Status, ConditionalAccessPolicies, Location
| sort by TimeGenerated desc

SLA/バックアップ/DR

  • SLA: Microsoft Entra IDは、Microsoftによって高可用性とパフォーマンスのSLAが提供されています（通常99.9%）。条件付きアクセスを含むサービス全体がこのSLAの対象です。

  • バックアップ/DR: Entra IDのデータ（ユーザー、グループ、ポリシーなど）のバックアップと災害復旧はMicrosoftによって管理されており、顧客側での具体的なバックアップ操作は不要です。ポリシー設定の変更は監査ログに記録され、以前の設定に戻すことは可能ですが、定期的なポリシー設定のコード化（IaC）がベストプラクティスです。

4. セキュリティ強化

条件付きアクセスとMFAは、エンタープライズセキュリティにおいて不可欠な要素です。

  • Zero Trust原則の実現: 「決して信頼せず、常に検証する」というZero Trustの考え方をCAポリシーで具現化します。すべてのアクセス要求を明示的に検証し、最小特権の原則を適用します。

  • レガシー認証のブロック: CAポリシーを使用してExchange ActiveSyncなどのレガシー認証プロトコルをブロックすることで、MFAを回避されるリスクを低減できます。これは一般的な攻撃ベクトルです。

  • リスクベース条件付きアクセス: Microsoft Entra Identity Protectionと連携し、ユーザーやサインインのリスクレベルに基づいてMFAを要求したり、パスワード変更を強制したりするポリシーを適用できます。

  • Microsoft Defender for Cloud Apps (MDCA) との連携: CAポリシーでMDCAをセッション制御プロバイダーとして利用することで、アクセス後にセッションを監視し、機密情報のダウンロードブロックや特定の操作の制限を行うことができます。

5. コスト最適化

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

  • ライセンスモデル:

    • Microsoft Entra ID P1: 条件付きアクセス、MFA（Microsoft Authenticatorアプリなど）、Self-Service Password Reset (SSPR) などの基本的なアイデンティティ管理機能を提供します。

    • Microsoft Entra ID P2: P1の全機能に加え、Microsoft Entra Identity Protection（リスクベースCA、リスクイベント検出）、Privileged Identity Management (PIM) などの高度なアイデンティティセキュリティ機能が含まれます。

  • コスト最適化のポイント:

    1. 適切なSKUの選択: 必要な機能に応じてP1またはP2を選択します。リスクベースCAやPIMが不要であれば、P1で十分な場合があります。

    2. ライセンスの割り当て: CAポリシーの対象となるユーザーのみにP1/P2ライセンスを割り当てます。すべてのユーザーにP2を割り当てる必要がないか検討します。

    3. 不要なライセンスの棚卸し: 定期的に使用されていないP1/P2ライセンスを棚卸しし、割り当てを解除することで無駄なコストを削減します。

MFA自体には追加コストは発生しませんが、MFAを強制するためのCAポリシー機能はP1/P2ライセンスが必要です。JST {{jst_today}}現在、P1ライセンスはユーザーあたり月額約800円、P2ライセンスは約1,300円です。正確な価格はMicrosoftの公式価格ページでご確認ください[1]。

6. 落とし穴と対策

CAポリシーの設計と導入には、注意すべき落とし穴がいくつか存在します。

  • 緊急アクセスアカウントの除外忘れ: すべてのCAポリシーから、最低2つの緊急アクセスアカウント（グローバル管理者など）を必ず除外してください。これにより、ポリシー設定ミスやIDプロバイダーの障害発生時にシステムからロックアウトされる事態を防ぎます。これらのアカウントは厳重に管理し、使用頻度を監視してください。

  • 広すぎるスコープの初期適用: 最初から「すべてのユーザー」と「すべてのクラウドアプリ」にCAポリシーを適用すると、大規模なロックアウトを引き起こす可能性があります。最初は小規模なテストグループと特定のアプリケーションから開始し、段階的に適用範囲を拡大してください。

  • ポリシー競合と評価順序: 複数のCAポリシーが存在する場合、評価順序によって意図しない結果が生じることがあります。Microsoft Entra管理センターの「What If」ツールを使用して、特定のユーザーと条件下でどのポリシーが適用され、最終的なアクセス結果がどうなるかをシミュレーションすることが重要です。

  • レガシー認証プロトコル: 一部のアプリケーションやクライアント（古いバージョンのOfficeクライアントなど）は、MFAに対応していないレガシー認証プロトコルを使用する場合があります。これらの認証をブロックしないと、CAポリシーの効果が半減します。CAポリシーでレガシー認証をブロックするルールを早期に導入し、影響を受けるユーザーにはモダン認証への移行を促す必要があります。

  • ユーザーエクスペリエンスの考慮: MFA要求が多すぎるとユーザーの生産性を損ない、MFA疲労を引き起こす可能性があります。信頼できるデバイスや場所からのアクセスではMFA頻度を下げるなど、バランスの取れた設計を検討してください。

7. まとめ

Microsoft Entra IDの条件付きアクセスとMFAは、現代のクラウド環境におけるセキュリティの要石です。適切なアーキテクチャ設計、Graph APIを活用した自動化された設定、詳細な運用監視、そして潜在的な落とし穴への対策を講じることで、組織は強固なセキュリティ体制を確立し、Zero Trust原則を実践できます。継続的な評価と改善を通じて、変化する脅威に対応し、より安全なデジタル環境を構築しましょう。

[1] Microsoft Entra ID の料金: https://azure.microsoft.com/ja-jp/pricing/details/active-directory/ (JST {{jst_today}} 確認)

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

コメント

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