Microsoft Entra 条件付きアクセスで多要素認証を強制するアーキテクチャと実装

Tech

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

Microsoft Entra 条件付きアクセスで多要素認証を強制するアーキテクチャと実装

クラウドサービスへのアクセスは、従来の境界型セキュリティモデルでは不十分であり、IDベースのセキュリティが重要性を増しています。特に、多要素認証（MFA）はID関連の攻撃から組織を保護するための最も効果的な手段の一つです。Microsoft Entra ID（旧Azure AD）の「条件付きアクセス」は、MFAを強制するための強力なツールであり、特定の条件に基づいてユーザーにMFAを要求することで、セキュリティと利便性のバランスを取ります。本記事では、Microsoft Entra 条件付きアクセスを用いたMFA強制のアーキテクチャ、具体的な設定手順、運用監視、セキュリティ考慮事項、コスト、および導入時の落とし穴について解説します。

1. Microsoft Entra 条件付きアクセスでMFAを強制するアーキテクチャ

Microsoft Entra 条件付きアクセスは、ユーザーがクラウドアプリケーションにアクセスしようとした際に、リアルタイムでさまざまなシグナル（ユーザー、場所、デバイス、アプリケーション、リアルタイムのリスクなど）を評価し、その評価に基づいてアクセスを許可するか、MFAを要求するか、アクセスをブロックするかを決定するポリシーエンジンです[1]。MFAの強制はこのポリシーによって実現されます。

1.1. 主要コンポーネント

  • ユーザー: クラウドアプリケーションへのアクセスを試みるエンティティ。

  • アプリケーション: Microsoft 365やSaaSアプリ、カスタム開発アプリなど、保護対象のリソース。

  • Microsoft Entra ID: ユーザー認証を一元的に管理するIDプロバイダー。

  • 条件付きアクセスエンジン: Microsoft Entra IDに統合され、サインイン要求時にポリシーを評価します。

  • MFAプロバイダー: Microsoft Authenticatorアプリ、FIDO2セキュリティキー、電話など、多要素認証を実行するサービス。

1.2. 認証フロー

条件付きアクセスによってMFAが強制される際の認証フローは以下の図のようになります。

graph TD
    A["ユーザー"] --> |1. サインイン要求| B("アプリケーション");
    B --> |2. 認証要求| C["Microsoft Entra ID"];
    C --> |3. 条件付きアクセスポリシー評価| D{"条件付きアクセスエンジン"};
    D -- MFAが必須の場合 --> E["MFAプロバイダー"];
    D -- MFAが不要/除外の場合 --> F["リソースへのアクセス許可"];
    E --> |4. MFA認証成功| C;
    C --> |5. アクセストークン発行| B;
    B --> |6. リソースアクセス| G["保護されたリソース"];
    F --> |直接アクセス許可| B;
    D -- MFAが必要だが失敗 --> H["アクセス拒否"];

このフローでは、ユーザーのサインイン要求がMicrosoft Entra IDに送られた後、条件付きアクセスエンジンが構成されたポリシーを評価します。MFAが要求される条件に合致した場合、MFAプロバイダーによる追加の認証が求められます。MFAが成功するとアクセストークンが発行され、ユーザーはアプリケーションにアクセスできます。

2. 設定手順

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

2.1. Microsoft Entra 管理センターでの設定

最も一般的な方法は、Microsoft Entra 管理センター（旧Azure Portal）のGUIを使用することです[2]。

  1. 前提条件:

    • Microsoft Entra ID P1以上のライセンスが割り当てられていること。

    • ユーザーがMFA登録済みであること（または、セキュリティの既定値群が有効になっていること）。

  2. ポリシー作成:

    1. Microsoft Entra 管理センター (https://entra.microsoft.com/) に管理者アカウントでサインインします。

    2. 左側のナビゲーションで [保護] > [条件付きアクセス] を選択します。

    3. [新しいポリシー] > [新しいポリシーを作成する] をクリックします。

    4. [名前] を入力します（例: All Users Require MFA for All Cloud Apps）。

    5. [ユーザー]:

      • [含める] で [すべてのユーザー] を選択します。

      • [除外] で [緊急アクセスアカウント] を指定します[3]。これにより、ポリシーの誤設定やEntra IDの問題発生時に誰もサインインできなくなる事態を防ぎます。

    6. [ターゲットリソース]:

      • [含める] で [すべてのクラウド アプリ] を選択します。特定のアプリケーションのみを対象とすることも可能です。

    7. [条件]: （オプション）

      • [場所]: 特定の国/地域からのアクセスのみMFAを要求する、あるいは信頼できるIPアドレスからのアクセスは除外するといった設定が可能です。

      • [デバイスプラットフォーム]: iOS/Android/Windowsなど、特定のOSからのアクセスのみMFAを要求することもできます。

      • [サインイン リスク]: Microsoft Entra ID Protectionのサインインリスクレベルに基づいてMFAを要求できます（Microsoft Entra ID P2が必要）。

    8. [アクセス制御]:

      • [許可] を選択し、[多要素認証を要求する] にチェックを入れます。

    9. [ポリシーの有効化]:

      • 最初は [レポート専用] モードで作成し、ポリシーの影響を評価します[6]。

      • 影響がないことを確認したら、[オン] に切り替えてポリシーを有効にします。

2.2. PowerShell / Microsoft Graph APIでの設定例

PowerShellとMicrosoft Graph APIを使用して、条件付きアクセスポリシーをコードとして管理することも可能です。これにより、IaC (Infrastructure as Code) の原則に従ってポリシーを展開し、バージョン管理できます[5]。

以下のPowerShellスクリプトは、すべてのユーザーに対してすべてのクラウドアプリでMFAを要求するポリシーを作成する例です。

# PowerShell Graph SDKのインストールと接続


# 必要に応じてInstall-Module Microsoft.Graph -Scope CurrentUser を実行

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

# 緊急アクセスアカウントのグループID (事前に作成しておく)


# 例: $EmergencyAccessGroupId = (Get-MgGroup -Filter "DisplayName eq 'Emergency Access Accounts'").Id

$PolicyName = "All Users Require MFA for All Cloud Apps"

# 条件付きアクセス ポリシーの定義 (JSON形式)

$CAPolicyBody = @{
    displayName = $PolicyName
    state = "enabledForReportingButBlocked" # レポート専用モードで開始
    conditions = @{
        applications = @{
            includeApplications = @("All")
        }
        users = @{
            includeUsers = @("All")

            # excludeGroups = @($EmergencyAccessGroupId) # 緊急アクセスグループを除外する場合

        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa") # 多要素認証を要求
    }
} | ConvertTo-Json -Depth 5

# ポリシーの作成

try {
    $Policy = New-MgIdentityConditionalAccessPolicy -BodyParameter $CAPolicyBody
    Write-Host "条件付きアクセス ポリシー '$($Policy.DisplayName)' を作成しました。ID: $($Policy.Id)"
    Write-Host "最初はレポート専用モードで有効化されています。影響を評価してください。"
}
catch {
    Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}

# 参考: ポリシーを有効にするには、以下のコマンドを実行


# $PolicyId = "<作成されたポリシーのID>"


# Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $PolicyId -BodyParameter @{ state = "enabled" }

# コメント:


# - Connect-MgGraph で必要なスコープ (Policy.ReadWrite.ConditionalAccess) を指定。


# - displayName: ポリシーの名前。


# - state: ポリシーの状態。


#   - "enabledForReportingButBlocked": レポート専用モード（影響を評価するために推奨）。


#   - "enabled": ポリシーを有効化。


#   - "disabled": ポリシーを無効化。


# - conditions: ポリシーが適用される条件を定義。


#   - applications.includeApplications: どのクラウドアプリに適用するか。"All"はすべてのアプリ。


#   - users.includeUsers: どのユーザーに適用するか。"All"はすべてのユーザー。


#   - users.excludeGroups: 特定のグループ（例: 緊急アクセスアカウント）を除外。


# - grantControls: アクセスを許可するための制御。


#   - builtInControls: "mfa" は多要素認証を要求。


# - 作成後は、Microsoft Entra 管理センターでレポートを確認し、問題がなければ `state` を "enabled" に更新する。

3. 運用監視

条件付きアクセスは一度設定すれば終わりではなく、継続的な監視と調整が必要です。

3.1. 監査とレポート

  • レポート専用モード: ポリシーを本稼働環境に展開する前に、レポート専用モードで動作させることで、ポリシーがユーザーにどのような影響を与えるかをシミュレーションできます[6]。これにより、予期せぬアクセスブロックを防ぎます。

  • サインインログ: Microsoft Entra IDのサインインログは、条件付きアクセスの結果を確認する上で不可欠です。どのポリシーが適用され、アクセスが許可されたか、あるいは拒否されたかを詳細に確認できます。ログはAzure MonitorのLog Analyticsワークスペースにエクスポートし、KQL（Kusto Query Language）を使って高度な分析やアラート設定を行うことが推奨されます。

  • 監査ログ: 条件付きアクセス ポリシー自体の変更は、Microsoft Entra IDの監査ログで追跡できます。

3.2. 緊急アクセスアカウント

組織全体のロックアウトを防ぐため、最低2つの緊急アクセスアカウントを条件付きアクセス ポリシーから除外することが必須です[3]。これらのアカウントは厳重に管理し、通常の運用では使用せず、緊急時のみアクセスできるようにします。

3.3. SLAとDR

Microsoft Entra IDは、MicrosoftによってSLA (Service Level Agreement) が提供され、高い可用性（通常99.9%以上）が保証されています。地理的冗長性もMicrosoft側で管理されており、ユーザー側で特別な災害復旧（DR）計画を立てる必要は通常ありません。MFA認証方法の多様化（Authenticatorアプリ、FIDO2キー、SMS、電話など）は、特定の認証方法が一時的に利用できない場合の冗長性として機能します。

4. セキュリティ

条件付きアクセスは、Entra IDのセキュリティ体制を強化する上で中心的な役割を果たします。

  • 最小権限の原則: 条件付きアクセス ポリシーの管理には、条件付きアクセス管理者などの最小限の権限を持つロールを割り当てます。グローバル管理者以外の担当者にポリシー管理を委任することで、権限の分離を図ります。

  • Entra ID Protectionとの連携: Microsoft Entra ID P2ライセンスを導入している場合、Entra ID Protectionが提供するユーザーリスクおよびサインインリスクの検出を活用できます[4]。条件付きアクセス ポリシーでこれらのリスクレベルを条件に含めることで、例えば「低リスクのサインインからはMFAを要求せず、高リスクのサインインからはMFAとパスワード変更を要求する」といった、より動的でアダプティブなセキュリティ対策を実現できます。

5. コスト

条件付きアクセスの利用には、Microsoft Entra IDのライセンス費用が発生します。

  • ライセンス要件: 条件付きアクセスの機能を利用するには、Microsoft Entra ID P1またはP2ライセンスが必要です[4]。MFA自体は、Security Defaultsを有効にすることで無料で利用可能ですが、条件付きアクセスのような詳細な制御はできません。

  • コスト最適化:

    • P1/P2ライセンスの最適化: 条件付きアクセスを必要とするユーザーにのみP1またはP2ライセンスを割り当てることで、ライセンスコストを最適化できます。

    • Log Analyticsのデータ保持: サインインログや監査ログをAzure MonitorのLog Analyticsにエクスポートする場合、データ保持期間に応じてコストが発生します。必要な期間のみデータを保持するように設定することで、コストを抑えることができます。

6. 落とし穴とベストプラクティス

6.1. 誤設定のリスク

条件付きアクセスは強力なツールですが、誤って設定すると、ユーザーがサービスにアクセスできなくなる「ロックアウト」を引き起こす可能性があります。

  • 緊急アクセスアカウントの未設定: これが最も危険な落とし穴です。必ず事前に緊急アクセスアカウントを設定し、ポリシーから除外してください。

  • すべてのユーザー/すべてのクラウドアプリへの一斉適用: 大規模な組織では、一部のレガシーアプリケーションやスクリプトがMFAに対応していない場合があります。また、特定のグループや部門にのみMFAを適用したいケースもあります。

6.2. 段階的導入とテスト

  • レポート専用モードの活用: ポリシーを本稼働環境で有効にする前に、必ずレポート専用モードでテスト期間を設けてください[6]。これにより、ポリシーの影響範囲を正確に把握し、予期せぬ問題を特定できます。

  • 段階的ロールアウト: すべてのユーザーに一斉にMFAを強制するのではなく、まずは少数のテストユーザーグループ、次に部門ごと、といった段階的なロールアウトを検討してください。

  • ユーザー教育とサポート: MFAの導入はユーザーエクスペリエンスに影響を与えます。導入前にユーザーへの十分な教育を行い、FAQやトラブルシューティングガイドを提供し、サポート体制を確立することが重要です。

7. まとめ

Microsoft Entra 条件付きアクセスは、Microsoft Entra IDにおけるIDベースのセキュリティを強化し、多要素認証を柔軟かつ効果的に強制するための重要な機能です。アーキテクチャの理解、GUIまたはMicrosoft Graph APIを用いた正確な設定、そしてレポート専用モードを活用した徹底的なテストを通じて、安全かつ円滑なMFA強制環境を構築することができます。運用監視、緊急アクセスアカウントの管理、そしてコスト最適化の考慮も、長期的なセキュリティ運用には不可欠です。これらのベストプラクティスを遵守することで、組織はデジタル資産をより強固に保護し、ID関連の脅威から防御することが可能になります。

参考資料 [1] Microsoft Learn: 条件付きアクセスとは？ – Microsoft Entra (2024年4月22日更新). URL: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/overview [2] Microsoft Learn: Microsoft Entra Conditional Access で多要素認証を要求する – Microsoft Entra (2024年4月11日更新). URL: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/howto-conditional-access-mfa-all-users [3] Microsoft Learn: Microsoft Entra 条件付きアクセスを展開するためのベスト プラクティス – Microsoft Entra (2024年4月11日更新). URL: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/best-practices [4] Microsoft Learn: Microsoft Entra ID のライセンスの基本 (2024年4月22日更新). URL: https://learn.microsoft.com/ja-jp/entra/identity/fundamentals/licensing-basics [5] Microsoft Learn: 条件付きアクセス API の概要 (2024年2月21日更新). URL: https://learn.microsoft.com/ja-jp/graph/api/resources/conditionalaccess-overview?view=graph-rest-1.0 [6] Microsoft Learn: 条件付きアクセスのレポート専用モードとは – Microsoft Entra (2024年4月11日更新). URL: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-report-only

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

コメント

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