Azure AD: 条件付きアクセスとMFA

Tech

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

Azure AD: 条件付きアクセスとMFA

Microsoft Entra ID（旧称 Azure Active Directory）における条件付きアクセス（Conditional Access: CA）と多要素認証（Multi-Factor Authentication: MFA）は、現代のサイバーセキュリティにおいて不可欠な要素です。これらを組み合わせることで、ユーザーの生産性を損なうことなく、強力なアクセス制御とセキュリティ態勢を確立できます。本記事では、この二つの機能がどのように連携し、組織のアイデンティティとリソースを保護するかについて、アーキテクチャ、設定、運用監視、セキュリティ、コスト、そして一般的な落とし穴の観点から解説します。

アーキテクチャ

Microsoft Entra IDの条件付きアクセスは、組織のリソースへのアクセスを決定するための中心的なポリシーエンジンとして機能します。ユーザーがアプリケーションやサービスへのサインインを試行する際に、そのユーザー、アクセス元のデバイス、場所、アプリケーション、リアルタイムのリスクシグナルなどの様々な「条件」を評価し、「許可」または「ブロック」といった「付与コントロール」を適用します。MFAは、この付与コントロールの一つとして最も頻繁に利用されます。

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

Microsoft Entra ID環境におけるアイデンティティと権限境界は、条件付きアクセスによって詳細に定義されます。

  • Entra ID: すべてのユーザー、グループ、デバイス、アプリケーションのアイデンティティを一元管理するクラウドベースのアイデンティティプロバイダーです。

  • ロール: Entra IDの組み込みロール（グローバル管理者、ユーザー管理者など）やカスタムロールに基づき、特定の管理タスクを実行できるユーザーを制限します。条件付きアクセスは、特定のロールを持つユーザーに対してのみMFAを強制するなど、ロールベースのアクセス制御を強化できます。

  • 条件付きアクセス: アクセス要求のコンテキスト（誰が、どこから、何を、どのデバイスで）に基づいて、リアルタイムにアクセスを許可または拒否するポリシーエンジンです。

  • Microsoft Defender for Identity / Defender for Cloud Apps: これらのセキュリティソリューションが生成するリスクシグナル（例: 異常な場所からのサインイン、感染したデバイスからのアクセス）は、条件付きアクセスに連携され、高リスクなアクセス試行に対してMFAの強制やアクセスブロックといった動的なポリシー適用を可能にします。これにより、権限の境界が脅威の状況に応じて動的に調整されます。

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

Mermaidによる条件付きアクセスのポリシー評価フローを以下に示します。

flowchart TD
    A["ユーザーがサインインを試行"] --> B{"サインイン要求の捕捉"};
    B --> C{"条件付きアクセスポリシー評価開始"};
    C -- 評価するポリシーを特定 --> D{"ポリシー条件との照合"};
    D -- 条件に一致 |条件と一致| --> E{"付与コントロールの適用"};
    D -- 除外されたユーザー/アプリ/条件 |除外対象| --> G["アクセス許可"];
    E -- MFAを要求 |MFA| --> F["MFAチャレンジ"];
    F -- MFA成功 |成功| --> G;
    E -- デバイス準拠を要求 |デバイス準拠| --> H["デバイスの準拠確認"];
    H -- 準拠済み |準拠| --> G;
    E -- アクセスをブロック |ブロック| --> I["アクセス拒否"];
    G["アクセス許可"] --> J["リソースへのアクセス"];
    style C fill:#f9f,stroke:#333,stroke-width:2px
    style E fill:#f9f,stroke:#333,stroke-width:2px

設定手順

条件付きアクセスポリシーの作成は、Azure portalまたはMicrosoft Graph APIを介して行えます。ここでは、Azure CLIとMicrosoft Graph APIを組み合わせた一般的なポリシー（すべてのユーザーにMFAを要求するが、緊急アクセスアカウントを除く）の作成例をPowershellで示します。

PowerShellによる条件付きアクセスポリシーの作成例

この例では、Microsoft.Graph PowerShellモジュールを使用して、グローバル管理者を除くすべてのユーザーに対してMFAを必須とするポリシーを作成します。

# Microsoft Graph PowerShell SDKのインストール（未インストールの場合は実行）


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

# Graph APIに接続（Conditional Access Policy管理に必要な権限で認証）


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

# 例: 緊急アクセスアカウントのObjectID (実際のものに置き換えてください)

$emergencyAccessAccountObjectId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# 例: グローバル管理者ロールのObjectID (固定値)

$globalAdministratorRoleObjectId = "62e90394-69f5-4237-9190-012177145eeb"

# ポリシーの定義

$policyDefinition = @{
    displayName = "MFA Required for All Users Except Emergency Access and Global Admins"
    state = "enabledForReportingButBlocked" # まずは「レポートのみ」モードで作成することを強く推奨
    conditions = @{
        users = @{
            includeUsers = @("All")

            # 緊急アクセスアカウントとグローバル管理者をポリシー適用から除外

            excludeUsers = @($emergencyAccessAccountObjectId)
            excludeRoles = @($globalAdministratorRoleObjectId) # グローバル管理者をロールで除外
        }
        applications = @{
            includeApplications = @("All")
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa")
    }
}

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

try {
    $createdPolicy = New-MgIdentityConditionalAccessPolicy -BodyParameter $policyDefinition
    Write-Host "条件付きアクセスポリシー '$($createdPolicy.DisplayName)' を作成しました。ID: $($createdPolicy.Id)"
    Write-Host "現在は 'レポートのみ' モードです。十分なテスト後に '有効' に変更してください。"
}
catch {
    Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}

# (オプション) 後でポリシーを有効にする場合


# Set-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $createdPolicy.Id -State "enabled"

コードの前提・計算量・メモリ条件:

  • 前提: Microsoft.Graph PowerShellモジュールのインストール済み、適切なGraph API権限（Policy.ReadWrite.ConditionalAccessなど）を持つアカウントでの認証。PowerShell 7.xを推奨。

  • 計算量: 単一のAPI呼び出しのため、非常に小さい。

  • メモリ条件: 小さい。

Report-onlyモードでのテスト

ポリシーをすぐに「有効」にするのではなく、state = "enabledForReportingButBlocked"（または enabledForReporting）で作成し、「レポートのみ」モードで動作を確認することが非常に重要です。このモードでは、ポリシーが適用された場合にどのような結果になったか（MFA要求、ブロックなど）がサインインログに記録されますが、実際のアクセスはブロックされません。これにより、ユーザーのロックアウトや予期せぬアクセス問題を防ぐことができます。少なくとも数日から数週間はレポートのみモードで監視し、影響範囲を正確に把握した上で本番適用に移行します。

運用監視

条件付きアクセスポリシーとMFAの有効性を維持するには、継続的な運用監視が不可欠です。

  • サインインログ: Microsoft Entra IDのサインインログは、各サインイン試行に対してどの条件付きアクセスポリシーが適用されたか、その結果どうなったか（MFA要求、アクセス許可、ブロックなど）を詳細に記録します。これにより、ポリシーの動作確認やトラブルシューティングが可能です。

  • 監査ログ: 条件付きアクセスポリシーの作成、変更、削除などの管理操作は監査ログに記録されます。これにより、誰がいつポリシーを変更したかを追跡できます。

  • 条件付きアクセスInsightsとレポートワークブック: Azure Monitorのワークブック機能を利用した「条件付きアクセスInsightsとレポート」は、過去90日間のポリシー評価結果をグラフィカルに可視化します。これにより、ポリシーがどれだけ効果的に適用されているか、ユーザーにどのような影響を与えているかを長期的に分析できます。

  • Azure Monitorアラート: サインインログや監査ログの特定のイベント（例: 特定のポリシーによる大量のアクセスブロック）に対して、Azure Monitorでアラートルールを設定できます。これにより、異常な挙動やセキュリティインシデントの発生時に迅速な対応が可能です。

  • SLAとDR: Microsoft Entra ID自体はMicrosoftによってSLAが保証され、地理的に分散されたデータセンターにより高可用性（DR）が実現されています。条件付きアクセス設定自体のバックアップは明示的には不要ですが、ポリシーの変更履歴は監査ログで追跡可能です。重要なポリシー設定はIaC（Infrastructure as Code）として管理し、Gitなどのバージョン管理システムで変更を管理することが推奨されます。

セキュリティ

条件付きアクセスとMFAは、アイデンティティベースのセキュリティを大幅に強化します。

  • 最小特権の原則の適用: 管理者ロールを持つユーザーに対し、常にMFAを要求したり、特定の信頼できるデバイスからのみアクセスを許可したりすることで、管理者権限の濫用や乗っ取りのリスクを大幅に低減できます。

  • レガシー認証のブロック: 古い認証プロトコル（POP3, IMAP, SMTPなど）はMFAに対応しておらず、フィッシング攻撃などのリスクを高めます。条件付きアクセスにより、これらのレガシー認証を完全にブロックし、よりセキュアな認証方法への移行を強制できます。

  • 高リスクサインイン/ユーザーへのMFA強制: Microsoft Entra ID Identity Protection (Microsoft Entra ID P2ライセンスが必要) と連携することで、機械学習に基づいたリスク検出が可能です。異常な場所からのサインインや漏洩した資格情報が使用された疑いがあるサインインなど、リスクが高いと判断されたアクセス試行に対して自動的にMFAを要求したり、アクセスをブロックしたりできます。

  • 緊急アクセスアカウントの保護: 組織のすべてのポリシーが予期せぬロックアウトを引き起こした場合に備え、ポリシーの対象から除外された緊急アクセスアカウントを少なくとも2つ設定し、これらを厳重に保管・監視することが、運用上非常に重要です。

  • Defender for Cloud Appsとの連携: クラウドアプリケーションに対するセッションポリシー（例: 機密ファイルのダウンロードをブロック、監査ログのみのアクセス）を条件付きアクセスと連携させることで、さらに詳細なアクセス制御と脅威保護を実現できます。

コスト

条件付きアクセスの利用には、Microsoft Entra IDの特定のライセンスが必要です。

  • Microsoft Entra ID P1: 基本的な条件付きアクセス機能とMFAが利用可能です。多くのMicrosoft 365 Business PremiumやMicrosoft 365 E3に含まれています。

  • Microsoft Entra ID P2: P1の機能に加えて、Microsoft Entra ID Identity Protectionによるリスクベースの条件付きアクセス、およびPIM（Privileged Identity Management）やEntitlement Managementなどの高度なアイデンティティ管理機能が利用可能です。Microsoft 365 E5に含まれています。

  • MFA機能自体: MFAの利用自体は、Microsoft Entra ID Freeエディションでもセキュリティの既定値（Security Defaults）として提供されますが、柔軟なポリシー設定（特定のユーザー/アプリ/条件でMFAを要求）にはP1以上のライセンスが必要です。

  • Log Analyticsワークスペース: 運用監視で利用するサインインログや監査ログを長期保存したり、高度なクエリを実行したりする場合、Azure Log Analyticsワークスペースにデータを連携します。この場合、Log Analyticsのデータ取り込み量と保持期間に応じてコストが発生します。コスト最適化のため、必要なデータのみを転送し、保持期間を適切に設定することが重要です。

落とし穴

条件付きアクセスとMFAの導入には多くのメリットがありますが、いくつかの一般的な落とし穴に注意が必要です。

  • ロックアウトのリスク: 最も危険な落とし穴は、ポリシーによって組織全体のユーザーや管理者がMicrosoft Entra IDからロックアウトされることです。特に、緊急アクセスアカウントの除外を忘れる、または設定が不適切である場合に発生します。

  • Report-onlyモードの無視: ポリシーをいきなり「有効」モードで展開すると、予期せぬアクセス拒否が発生し、ビジネスに大きな影響を与える可能性があります。必ず「レポートのみ」モードで十分なテスト期間を設け、影響を評価することが不可欠です。

  • レガシー認証クライアントへの影響: 条件付きアクセスでレガシー認証をブロックするポリシーを導入すると、古いメールクライアントや一部のアプリケーションがサインインできなくなる可能性があります。事前に影響を受けるクライアントを特定し、ユーザーへの周知と代替手段の提供が必要です。

  • 複雑すぎるポリシー: ポリシーを細かくしすぎると、管理が複雑になり、予期せぬポリシーの競合やトラブルシューティングの困難さにつながります。まずは広範なポリシーでカバーし、必要に応じて詳細化するアプローチが推奨されます。

  • ライセンスの理解不足: 条件付きアクセスやIdentity Protectionの特定の機能にはMicrosoft Entra ID P1またはP2ライセンスが必要です。必要な機能に対して適切なライセンスが割り当てられていない場合、期待通りのセキュリティが実現できません。

まとめ

Microsoft Entra IDの条件付きアクセスとMFAは、現代のアイデンティティとアクセス管理の要石です。MFAを条件付きアクセスと組み合わせることで、ユーザーの場所、デバイス、アプリケーション、リスクレベルなどのコンテキストに基づいた、きめ細やかで動的なアクセス制御が可能になります。これにより、従来の静的なパスワードベースのセキュリティモデルでは対応しきれなかった多様なサイバー脅威から組織のリソースを保護し、より強固なセキュリティ態勢を確立できます。適切な設計、計画的な導入、そして継続的な監視を通じて、これらの強力な機能を最大限に活用することが重要です。

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

コメント

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