Microsoft Entra条件付きアクセスとMFA強化のアーキテクチャと実践

Tech

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

Microsoft Entra条件付きアクセスとMFA強化のアーキテクチャと実践

クラウドベースのアイデンティティ管理において、セキュリティと利便性の両立は常に重要な課題です。Microsoft Entra ID (旧 Azure AD) の条件付きアクセス (Conditional Access: CA) は、この課題を解決するための強力なツールであり、多要素認証 (MFA) の適用を強化することで、現代のサイバー脅威から組織を保護します。本記事では、Microsoft Entra条件付きアクセスとMFA強化について、そのアーキテクチャから具体的な設定、運用、コスト、そして一般的な落とし穴までをクラウドアーキテクトの視点から解説します。

アーキテクチャの概要

Microsoft Entra条件付きアクセスは、ユーザーがクラウドアプリケーションやリソースにアクセスしようとした際に、リアルタイムで認証要求を評価し、適切なアクセス制御を適用するポリシーエンジンです。これにより、組織はアクセスを許可する前に、ユーザー、デバイス、場所、アプリケーションなどのコンテキストに基づいて、特定の条件（MFA要求、デバイスの準拠、セッションの制限など）を満たすことを強制できます。

MFA強化とは、単にMFAを必須にするだけでなく、その認証方法（認証強度：Authentication Strengths）やセッションの挙動をより細かく制御することを指します。例えば、フィッシング耐性のあるFIDO2セキュリティキーのみを許可する、特定の管理操作に限りMFAを再要求するといった高度なシナリオを実現できます。

条件付きアクセスの認証フロー

一般的な条件付きアクセスとMFA強化の認証フローは以下のようになります。

graph TD
    A["ユーザーがクラウドアプリにアクセスを試行"] --> B{"Microsoft Entra ID認証要求"}
    B --> C{"条件付きアクセスポリシー評価フェーズ"}
    C --|ユーザー、グループ、ロール| D1["ポリシー条件: ユーザー"]
    C --|クラウドアプリ、アクション| D2["ポリシー条件: アプリケーション"]
    C --|デバイスの状態、プラットフォーム| D3["ポリシー条件: デバイス"]
    C --|場所 (IPアドレス)、クライアントアプリ| D4["ポリシー条件: 場所とクライアントアプリ"]
    D1 & D2 & D3 & D4 --> E{"すべてのポリシー条件が一致するか?"}
    E --|いいえ| F["アクセス許可 (ポリシーなし)"]
    E --|はい| G{"アクセス付与コントロールの適用"}
    G --|特定の認証強度 (MFA) 必須| H["MFA要求フェーズ (例: FIDO2)"]
    H --> I{"MFA実行 (認証強度検証)"}
    I --|MFA成功| J["セッション制御の適用フェーズ"]
    I --|MFA失敗| K["アクセスブロック"]
    G --|セッション制御 (サインイン頻度、永続化) を適用| J
    J --> L["リソースへのアクセスを許可"]
    K --> M["リソースへのアクセスを拒否"]

[1]

このフローでは、まずユーザーの認証要求がMicrosoft Entra IDに送信され、その後、定義された条件付きアクセスポリシーが評価されます。ポリシー条件（ユーザー、アプリケーション、デバイス、場所など）が一致した場合、ポリシーで設定された付与コントロール（MFA必須、特定の認証強度要求、ブロックなど）が適用されます。特に「認証強度」は、特定のMFAメソッド（例: Microsoft Authenticatorプッシュ通知、FIDO2セキュリティキー）を強制することで、MFAのセキュリティレベルを向上させます。

設定手順

ここでは、PowerShell (Microsoft Graph PowerShell SDK) を使用して、特定の管理者ロールを持つユーザーがクラウドアプリにアクセスする際に、フィッシング耐性のある認証強度を必須とする条件付きアクセスポリシーをレポート専用モードで作成する例を示します。

このポリシーはMicrosoft Entra ID P2ライセンスが必要です。基本的な条件付きアクセスはP1ライセンスで利用可能ですが、認証強度の利用はP2ライセンスが必須となります[4]。

PowerShellスクリプト例: 管理者ロールにフィッシング耐性MFAを要求

この例では、Get-MgBetaIdentityConditionalAccessAuthenticationStrength コマンドレットを使用してフィッシング耐性のある認証強度のIDを取得し、それを利用します。Microsoft Graph PowerShell SDKのMicrosoft.Graph.Betaモジュールのインストールが必要になる場合があります。

# PowerShellスクリプト例: 管理者ロールにフィッシング耐性のあるMFAを要求する条件付きアクセスポリシーの作成

# 必要なMicrosoft Graph PowerShellモジュールをインストールします


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


# Install-Module -Name Microsoft.Graph.Beta.Identity.ConditionalAccess -Scope CurrentUser # 認証強度管理用

# 管理者としてMicrosoft Graphに接続します


# Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "RoleManagement.Read.Directory", "Policy.Read.ConditionalAccess.AuthenticationStrength"

# ポリシー名と説明を定義

$policyDisplayName = "グローバル管理者にフィッシング耐性MFAを要求（レポート専用）"
$policyDescription = "Global Administratorロールを持つユーザーがクラウドアプリにアクセスする際、フィッシング耐性のあるMFAを要求します。"

# 1. 対象となる管理者ロールのObjectIDを取得 (例: Global Administrator)


# Get-MgDirectoryRoleTemplate | Where-Object {$_.DisplayName -eq "Global Administrator"}

$globalAdminRoleId = "62e90394-69f5-4237-9137-0175ff589133" # Global AdministratorロールのObjectID (テナント共通)

# 2. フィッシング耐性のある認証強度のIDを取得


# "Phishing-resistant MFA" または "FIDO2 Security Key (Preview)" などの認証強度を探します。


# 以下のコマンドでテナント内の認証強度リストを確認し、適切なIDを取得してください。


# Get-MgBetaIdentityConditionalAccessAuthenticationStrength | Select-Object Id, DisplayName


# 例として、フィッシング耐性のあるMFAのIDを仮定します。実際には上のコマンドで取得したIDを使用してください。

$phishingResistantAuthStrengthId = "c1f36e4b-a9b0-4665-b16a-a1787e28942b" # 例: フィッシング耐性のあるMFAのID

# ポリシー条件:


# a. ユーザー: Global Administratorロールのメンバー

$usersCondition = @{
    IncludeRoles = @($globalAdminRoleId)

    # 緊急アクセスアカウントは必ず除外してください（ObjectIDまたはグループIDを指定）

    ExcludeUsers = $null
    ExcludeGroups = $null
}

# b. クラウドアプリ: すべてのクラウドアプリ

$applicationsCondition = @{
    IncludeApplications = @("All")
    ExcludeApplications = $null
}

# c. クライアントアプリの種類: すべてのクライアントアプリ

$clientAppTypesCondition = @("all")

# ポリシーの付与コントロール:


# 特定の認証強度を必須とする

$grantControls = @{
    Operator = "OR" # 複数のコントロールがある場合、どれか1つを満たせば良いか、すべてを満たす必要があるか
    AuthenticationStrength = @{ Id = $phishingResistantAuthStrengthId } # 特定の認証強度を要求
}

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

$conditionalAccessPolicy = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphConditionalAccessPolicy
$conditionalAccessPolicy.DisplayName = $policyDisplayName
$conditionalAccessPolicy.Description = $policyDescription
$conditionalAccessPolicy.Conditions = @{
    Users = $usersCondition
    Applications = $applicationsCondition
    ClientAppTypes = $clientAppTypesCondition
}
$conditionalAccessPolicy.GrantControls = $grantControls

# 最初は「レポート専用モード」でデプロイし、影響を確認することを強く推奨します。


# 完全に有効にする場合は "Enabled" に、無効にする場合は "Disabled" に設定します。

$conditionalAccessPolicy.State = "enabledForReportingButBlocked" # レポート専用モード

# ポリシーをMicrosoft Entra IDにデプロイ

Write-Host "条件付きアクセスポリシー '$policyDisplayName' をレポート専用モードで作成しています..."
try {
    $createdPolicy = New-MgIdentityConditionalAccessPolicy -BodyParameter $conditionalAccessPolicy
    Write-Host "ポリシーが正常に作成されました。ID: $($createdPolicy.Id)"
    Write-Host "数時間後にMicrosoft Entra管理センターの「条件付きアクセス Insights and reporting」ワークブックで影響を確認してください。"
}
catch {
    Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}

このスクリプトは、Global Administratorロールに属するユーザーがMicrosoft Entra IDに管理アクセスする際に、フィッシング耐性のあるMFA（FIDO2セキュリティキーなど）を要求するポリシーをレポート専用モードで作成します。このポリシーは、まず enabledForReportingButBlocked (レポート専用モード) でデプロイし、影響を慎重に監視することが不可欠です。Microsoft Learnによると、Windowsデバイスプラットフォームを条件とする機能が2024年7月25日 (JST) に一般提供開始されており、より詳細なデバイスベースの制御も可能です[1]。

運用監視

条件付きアクセスとMFAの運用監視は、セキュリティ体制を維持し、ユーザーエクスペリエンスを最適化するために不可欠です。

  • サインインログ (Sign-in logs): Microsoft Entra管理センターで確認できるサインインログは、各認証要求に適用された条件付きアクセスポリシーの詳細、MFAの結果、リスクレベルなどを記録します。これにより、ポリシーの動作をリアルタイムで把握できます。

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

  • 条件付きアクセス Insights and reporting ワークブック: このAzure Monitorワークブックは、条件付きアクセスポリシーの影響を視覚的に分析するために設計されており、レポート専用モードでポリシーをデプロイした際の効果予測や、既存ポリシーの適用状況を詳細に確認できます。[5]

  • レポート専用モード (Report-only mode): 新しいポリシーを有効にする前に、必ずこのモードでデプロイし、影響を数日から数週間監視することが推奨されます。これにより、意図しないロックアウトやユーザーへの影響を事前に特定できます。

  • アラート: Azure MonitorとLog Analyticsを連携させ、特定の条件（例: 多数のMFA失敗、リスクの高いサインイン）に基づいてアラートを設定することで、セキュリティイベントに迅速に対応できます。

  • SLA (Service Level Agreement): Microsoft Entra IDは高可用性サービスであり、Microsoftは99.9%の月間稼働率を保証しています。条件付きアクセスもこのインフラストラクチャ上で動作するため、高い信頼性を提供します。

  • バックアップ/DR (Disaster Recovery): 条件付きアクセスポリシーはMicrosoft Entra IDに保存されるため、物理的なバックアップの必要はありません。ただし、ポリシー設定の意図しない変更に備え、PowerShellやGraph APIを利用してポリシー定義をコードとして管理（Infrastructure as Code）し、バージョン管理システムで管理することを推奨します。

セキュリティ強化

Microsoft Entra条件付きアクセスとMFAは、アイデンティティと権限境界を強化するための重要な要素です。

  • 最小特権の原則: 最小限の権限で管理タスクを実行できるよう、Microsoft Entraロールを適切に割り当て、条件付きアクセスを使用して管理者ロールへのアクセスを厳格化します。例えば、特権管理者ロールへのアクセスには、登録済みデバイスからのMFAを必須とします。

  • Authentication Strengthsの活用: 2024年7月29日 (JST) に更新されたMicrosoft Learnのドキュメントで詳述されているように、パスワードレス認証（FIDO2セキュリティキー）やMicrosoft Authenticatorのプッシュ通知など、フィッシング耐性のあるMFA方法を特定のシナリオで強制することで、最も一般的な認証攻撃（フィッシング）に対する耐性を高めます。[2]

  • リスクベース条件付きアクセス: Microsoft Entra ID Protection (Microsoft Entra ID P2ライセンスが必要) と連携し、ユーザーやサインインのリスクレベルに基づいてMFAを要求したり、アクセスをブロックしたりするポリシーを設定できます。これにより、異常なサインイン試行を自動的に検知し、対応します。

  • Microsoft Defender for Cloud Apps (MDCA) との連携: 条件付きアクセスとMDCAを統合することで、セッションベースの制御（例: ファイルのダウンロードを禁止、セッションの監視）を適用し、承認済みクラウドアプリ内でのデータ漏洩リスクを低減できます。

  • セッションコントロール: 2024年7月24日 (JST) に更新された情報によると、「サインイン頻度」や「永続ブラウザセッション」などのセッションコントロールを設定することで、MFA後のセッションの有効期間や再認証の頻度を管理し、継続的なセキュリティを確保できます。[3]

コスト最適化

Microsoft Entra条件付きアクセスとMFA強化の利用には、Microsoft Entra IDの適切なライセンスが必要です。

  • ライセンス要件:

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

    • Microsoft Entra ID P1: 基本的な条件付きアクセス機能（MFAの強制、場所ベースのアクセス制御、デバイスの状態による制御など）を利用できます。

    • Microsoft Entra ID P2: P1の機能に加え、認証強度 (Authentication Strengths) や リスクベース条件付きアクセス（Microsoft Entra ID Protection） といったMFA強化機能を利用できます。[4]

  • コスト最適化の戦略:

    • 適切なライセンスプランの選択: 全ユーザーがP2ライセンスを必要とするわけではありません。例えば、すべてのユーザーにMFAを必須とするだけであればP1で十分です。認証強度やリスクベースCAが必要な管理者や特定の高リスクユーザーにのみP2ライセンスを割り当てることで、コストを最適化できます。

    • 不要な機能の確認: 現在利用しているライセンスプランで提供される機能が、本当にビジネス要件に合致しているか定期的に見直し、過剰なライセンスを購入していないか確認します。

    • グループベースのライセンス割り当て: Microsoft Entra IDのグループベースのライセンス割り当てを活用し、必要なユーザーにのみP1またはP2ライセンスを付与することで、管理オーバーヘッドとコストを削減します。

運用上の落とし穴と対策

条件付きアクセスは非常に強力ですが、設定を誤るとサービス停止やロックアウトを引き起こす可能性があります。

  • ロックアウトのリスク:

    • 落とし穴: すべての管理者にMFAを必須とするポリシーをテストせずに有効化し、MFA登録ができていない管理者がロックアウトされる。

    • 対策:

      1. 緊急アクセスアカウントの確保: 少なくとも2つのクラウド専用アカウント（オンプレミスと同期されない）を作成し、いかなる条件付きアクセスポリシーからも除外します。これらのアカウントは厳重に管理し、緊急時のみ使用します。

      2. レポート専用モードでの検証: ポリシーを本稼働する前に、必ずレポート専用モードで数週間運用し、影響を詳細に分析します。

      3. 段階的な展開: まず小規模なテストグループにポリシーを適用し、問題がないことを確認してから、徐々にユーザー範囲を拡大します。

  • ユーザーエクスペリエンスへの影響:

    • 落とし穴: あらゆるアクセスにMFAを強制することで、ユーザーの生産性が低下し、不満が生じる。

    • 対策: 信頼された場所からのアクセスや、登録済みデバイスからのアクセスにはMFAを緩和するなど、セキュリティと利便性のバランスを取ります。セッションコントロールの「サインイン頻度」を適切に設定し、再認証の頻度を管理します。

  • ポリシーの複雑化:

    • 落とし穴: 多数の重複したポリシーや矛盾するポリシーが存在し、管理が困難になり、意図しないアクセス許可/拒否が発生する。

    • 対策: ポリシーの数を最小限に保ち、明確な目的を持たせます。定期的にポリシーを見直し、整理します。命名規則を確立し、管理しやすくします。

  • レガシー認証プロトコルへの対応:

    • 落とし穴: Exchange ActiveSyncやIMAP/POPなどのレガシー認証プロトコルはMFAに対応していないため、MFA必須ポリシーをバイパスされる可能性がある。

    • 対策: 条件付きアクセスでレガシー認証を完全にブロックするポリシーを設定し、最新の認証プロトコル（モダン認証）への移行を推進します。

まとめ

Microsoft Entra条件付きアクセスとMFA強化は、現代のアイデンティティセキュリティ戦略の要です。最新のMicrosoft Entra IDの機能（例: Windowsデバイスプラットフォームの条件、認証強度）を活用することで、組織は柔軟かつ強力なアクセス制御を実装し、進化する脅威からリソースを保護できます。しかし、その強力さゆえに、計画的な導入、徹底したテスト、継続的な監視が不可欠です。本記事で解説したアーキテクチャ、設定手順、運用監視、セキュリティ強化、コスト最適化、そして一般的な落とし穴とその対策を参考に、堅牢で効率的なアイデンティティセキュリティ基盤を構築してください。

参考文献 [1] Microsoft Learn. “What’s new in Microsoft Entra ID.” 2024年7月25日 (JST) 更新. https://learn.microsoft.com/en-us/entra/fundamentals/whats-new [2] Microsoft Learn. “Conditional Access authentication strengths.” 2024年7月29日 (JST) 更新. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-authentication-strength [3] Microsoft Learn. “Conditional Access policy settings.” 2024年7月24日 (JST) 更新. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-settings [4] Microsoft Learn. “How to get a license for Microsoft Entra ID.” 2024年6月28日 (JST) 更新. https://learn.microsoft.com/en-us/entra/fundamentals/how-to-licensing [5] Microsoft Learn. “Plan a Conditional Access deployment.” 2024年7月25日 (JST) 更新. https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access

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

コメント

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