<p><!--META { "title": "Azure Entra ID: 条件付きアクセス認証強度", "primary_category": "クラウド>Azure", "secondary_categories": ["セキュリティ","アイデンティティ管理"], "tags": ["Azure Entra ID","Conditional Access","Authentication Strength","MFA","Graph API","PowerShell"], "summary": "Azure Entra IDの条件付きアクセス認証強度について、アーキテクチャ、設定手順、運用監視、セキュリティ、コスト、落とし穴をクラウドアーキテクトの視点から解説します。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"Azure Entra IDの条件付きアクセス認証強度で、特定の多要素認証（MFA）を強制する方法を解説。セキュリティ強化と運用、コスト、注意点までカバーします。 #Azure #EntraID #セキュリティ","hashtags":["#Azure","#EntraID","#セキュリティ"]}, "link_hints": ["https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-authentication-strength"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure Entra ID: 条件付きアクセス認証強度</h1> <h2 class="wp-block-heading">アーキテクチャ概要</h2> <p>Azure Entra ID (旧称 Azure Active Directory) の条件付きアクセス (Conditional Access: CA) は、組織のリソースへのアクセスを制御するための強力なツールです。この中で「認証強度 (Authentication Strength)」は、特定の条件下でユーザーが使用すべき多要素認証 (Multi-Factor Authentication: MFA) の方法をさらに細かく指定できる機能です。従来の「MFAを要求する」だけでは、SMS認証やMicrosoft Authenticatorの承認通知など、様々なMFA方法が許容されていました。しかし、認証強度を導入することで、「フィッシング耐性のあるMFA (Phishing-resistant MFA)」のみを要求する、といった高度なセキュリティ要件を満たすことが可能になります。</p> <p>認証強度は、大きく分けて以下の2種類があります。</p> <ul class="wp-block-list"> <li><p><strong>組み込みの認証強度</strong>: Microsoftが事前に定義している強度で、例えば「MFA Strength – High (フィッシング耐性MFA)」や「MFA Strength – Medium (任意のMFA)」などがあります。</p></li> <li><p><strong>カスタム認証強度</strong>: 管理者が独自に許可するMFA方法の組み合わせを定義できます。これにより、特定の認証要件に合わせた柔軟なポリシーを構築できます。</p></li> </ul> <p>認証強度は、Entra IDテナント内で定義され、条件付きアクセス ポリシーの「アクセス制御 > 付与」セクションで設定されます。ユーザーがアプリケーションにアクセスしようとすると、まずEntra IDがユーザー、デバイス、場所、アプリケーションなどの様々な条件を評価します。その後、ポリシーで認証強度が要求されていれば、ユーザーは指定されたMFA方法で認証を完了する必要があります。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD A["ユーザーがアプリケーションへアクセスを試行"] --> B("Azure Entra IDが要求を受信") B --> C{"条件付きアクセス ポリシーの評価"}; C -- ユーザー/グループ | アプリケーション | デバイス | 場所 | サインインリスク --> D{"ポリシーが適用されるか？"}; D -- いいえ --> E["アクセス許可"]; D -- はい --> F{"認証強度が要求されているか？"}; F -- いいえ (従来のMFA) --> G["MFAチャレンジ"]; F -- はい (特定のMFA方法) --> H["指定された認証強度でのMFAチャレンジ"]; G --> I{"認証成功？"}; H --> I; I -- はい --> J["アクセス許可"]; I -- いいえ --> K["アクセス拒否"]; style J fill:#c8e6c9,stroke:#388e3c,stroke-width:2px; style K fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px; </pre></div> <p>図：条件付きアクセスと認証強度の決定フロー</p> <p>このアーキテクチャにより、例えば機密性の高い財務アプリケーションへのアクセスにはFIDO2セキュリティキーを、一般的な社内ポータルへのアクセスにはMicrosoft Authenticatorの通知を、といった粒度でのセキュリティ制御が可能となります[1]。</p> <h2 class="wp-block-heading">設定手順</h2> <p>認証強度は、AzureポータルまたはMicrosoft Graph API (PowerShellを含む) を使用して設定できます。ここでは、Azureポータルでの設定手順と、PowerShellによるGraph APIでの設定例を示します。</p> <h3 class="wp-block-heading">Azureポータルでの設定手順</h3> <ol class="wp-block-list"> <li><p><strong>Azure Entra ID 管理センターにサインイン</strong>します。 (<code>https://entra.microsoft.com/</code>)</p></li> <li><p>左側のナビゲーションペインで、<strong>「保護」</strong> > <strong>「条件付きアクセス」</strong> > <strong>「ポリシー」</strong> の順に選択します。</p></li> <li><p><strong>「新しいポリシー」</strong> をクリックし、新しい条件付きアクセス ポリシーを作成します。</p></li> <li><p><strong>「名前」</strong> にポリシーの名前 (例: <code>PhishingResistantMFA_for_CriticalApps</code>) を入力します。</p></li> <li><p><strong>「ユーザー」</strong> : このポリシーを適用するユーザーまたはグループを選択します。推奨は特定のグループから開始し、テストすることです。</p></li> <li><p><strong>「ターゲット リソース」</strong>: このポリシーを適用するクラウドアプリまたはアクションを選択します。例えば、特定の機密性の高いアプリケーションを選択します。</p></li> <li><p><strong>「条件」</strong>: 必要に応じて、デバイスプラットフォーム、場所、クライアントアプリ、デバイス状態、サインインリスクなどを設定します。</p></li> <li><p><strong>「アクセス制御」</strong> > <strong>「付与」</strong> に移動し、<strong>「アクセスの付与」</strong> を選択します。</p></li> <li><p>プルダウンメニューから <strong>「認証強度を要求する」</strong> を選択します。</p></li> <li><p>ドロップダウンリストから、必要な認証強度を選択します。例えば、<strong>「MFA Strength – High (最も安全な組み込み)」</strong> を選択します。これにより、フィッシング耐性のあるMFA方法 (FIDO2セキュリティキー、Windows Hello for Businessなど) のみが許可されます。</p></li> <li><p><strong>「選択」</strong> をクリックします。</p></li> <li><p><strong>「ポリシーの有効化」</strong> を <strong>「レポートのみ」</strong> に設定し、影響を監視することをお勧めします。問題がなければ <strong>「オン」</strong> に変更します。</p></li> <li><p><strong>「作成」</strong> をクリックしてポリシーを保存します。</p></li> </ol> <h3 class="wp-block-heading">PowerShellでの設定例 (Microsoft Graph API)</h3> <p>Microsoft Graph PowerShell SDK を使用して、特定の認証強度を要求する条件付きアクセス ポリシーを作成できます。</p> <p><strong>前提条件</strong>:</p> <ul class="wp-block-list"> <li><p><code>Microsoft.Graph.Identity.SignIns</code> モジュールがインストールされていること。</p></li> <li><p>適切な Graph API 権限 (例: <code>ConditionalAccess.ReadWrite.All</code>) を持つアカウントで接続されていること。</p></li> </ul> <div class="codehilite"> <pre data-enlighter-language="generic"># モジュールのインストール（未インストールの場合は実行） # Install-Module -Name Microsoft.Graph.Identity.SignIns # Graph APIに接続（初回は認証プロンプトが表示されます） # Connect-MgGraph -Scopes "ConditionalAccess.ReadWrite.All" # 認証強度IDの取得 # 組み込みの「MFA Strength - High (最も安全な組み込み)」のIDを取得する例 # Get-MgIdentityConditionalAccessAuthenticationStrength -Filter "displayName eq 'MFA Strength - High (最も安全な組み込み)'" | Select-Object Id, DisplayName $authenticationStrengthId = "f5ed389a-0744-4860-9884-fd33406e129f" # MFA Strength - High の組み込みID (2024年1月23日時点のMicrosoft Learn情報に基づく[1]) # ポリシーの対象ユーザーを設定 $users = @{ IncludeUsers = @("All") # すべてのユーザーを対象とする例 #ExcludeUsers = @("admin@contoso.com") # 特定のユーザーを除外する例 } # ポリシーの対象アプリケーションを設定 $applications = @{ IncludeApplications = @("All") # すべてのクラウドアプリを対象とする例 #IncludeApplications = @("6f0cd49f-f227-466d-a363-066ac06dfa99") # 特定のアプリIDを指定する例 (例: Microsoft Teams) } # アクセス制御 - 付与を設定 $grantControls = @{ BuiltInAuthenticationStrength = @{ Id = $authenticationStrengthId } } # ポリシーオブジェクトの作成 $conditionalAccessPolicy = @{ DisplayName = "PhishingResistantMFA for All Apps - PowerShell ({{jst_today}})" State = "enabledForReportingButBlocked" # レポートのみで有効化し、影響を監視推奨 Conditions = @{ Users = $users Applications = $applications ClientAppTypes = @("all") } GrantControls = @{ Operator = "OR" # 複数の付与コントロールがある場合（今回は認証強度のみ） BuiltInAuthenticationStrength = @($grantControls.BuiltInAuthenticationStrength) } } # 条件付きアクセス ポリシーの作成 New-MgIdentityConditionalAccessPolicy -BodyParameter $conditionalAccessPolicy # 注意：作成後、AzureポータルやGraph Explorerでポリシーが正しく作成されたか確認してください。 # レポートモードでしばらく運用し、問題がなければStateを "enabled" に変更してください。 </pre> </div> <h2 class="wp-block-heading">運用監視</h2> <p>認証強度が適用された条件付きアクセス ポリシーの運用においては、その効果と潜在的な問題を監視することが不可欠です。</p> <ol class="wp-block-list"> <li><p><strong>サインインログ</strong>: Entra IDのサインインログは、ポリシーがどのように適用されたかを確認する主要な情報源です。各サインインイベントには、適用された条件付きアクセス ポリシー、その結果 (成功、失敗、ブロック)、および適用されたアクセス制御 (例: 認証強度の要求) の詳細が含まれます。これにより、ユーザーが意図した認証強度でアクセスしているか、またはブロックされている理由を特定できます[4]。</p> <ul> <li><strong>パス</strong>: Azure Entra ID > 監視と正常性 > サインインログ</li> </ul></li> <li><p><strong>監査ログ</strong>: 条件付きアクセス ポリシー自体の作成、更新、削除は監査ログに記録されます。これにより、誰がいつポリシーを変更したかを追跡し、変更履歴を管理できます。</p> <ul> <li><strong>パス</strong>: Azure Entra ID > 監視と正常性 > 監査ログ</li> </ul></li> <li><p><strong>条件付きアクセス Insights and Report</strong>: このワークブックは、条件付きアクセス ポリシーの評価結果を視覚的に表示し、レポートのみモードで実行されているポリシーの潜在的な影響を分析するのに役立ちます。認証強度の導入前に、レポートモードでポリシーを評価することは、サービス中断を防ぐ上で非常に重要です。</p> <ul> <li><strong>パス</strong>: Azure Entra ID > 保護 > 条件付きアクセス > Insights and Report</li> </ul></li> </ol> <p><strong>SLAとバックアップ/DR</strong>: Azure Entra ID自体は、MicrosoftのSLA (Service Level Agreement) に基づいて高い可用性を提供しています。条件付きアクセス ポリシーはテナント設定としてEntra IDに保存され、グローバルに冗長化されているため、特定のバックアップや災害復旧 (DR) の手順は不要です。ポリシー設定の変更は監査ログで追跡できるため、実質的な「ロールバック」は手動での設定復元か、Graph API/IaCを用いたバージョン管理に依存します。</p> <h2 class="wp-block-heading">セキュリティ</h2> <p>認証強度は、Entra ID環境のセキュリティを大幅に向上させます。</p> <ul class="wp-block-list"> <li><p><strong>フィッシング耐性MFAの強制</strong>: 最も重要な利点の一つは、フィッシング攻撃に対する耐性が高いMFA方法 (FIDO2セキュリティキー、Windows Hello for Business) を強制できる点です。これにより、MFAを突破しようとする攻撃者の試みを大幅に困難にします。</p></li> <li><p><strong>リスクベースのアクセス制御との連携</strong>: Azure Entra ID Identity Protectionからのサインインリスクやユーザーリスクの検出と組み合わせることで、さらに動的なセキュリティポリシーを構築できます。例えば、高リスクなサインインと判断された場合にのみ、より高い認証強度を要求するポリシーを適用できます。</p></li> <li><p><strong>ゼロトラスト原則の強化</strong>: 「決して信頼せず、常に検証する」というゼロトラストの原則に沿って、認証強度によってユーザーのアイデンティティ検証を強化します。</p></li> <li><p><strong>アイデンティティと権限境界</strong>: 認証強度ポリシーは、Entra IDのテナント内で、特定のアプリケーションやリソースへのアクセスを保護する境界を強化します。ポリシーの管理は、<strong>条件付きアクセス管理者</strong>または<strong>セキュリティ管理者</strong>ロールを持つユーザーに限定すべきです。これにより、ポリシーの誤用や不正な変更を防ぎ、権限の分離を徹底します。</p></li> </ul> <h2 class="wp-block-heading">コスト</h2> <p>認証強度を含む条件付きアクセス機能の利用には、Azure Entra IDのライセンスが必要です。</p> <ul class="wp-block-list"> <li><p><strong>Azure Entra ID Premium P1</strong>: 条件付きアクセス機能の基本的な利用には、このライセンスが必須です。これには、組み込みの認証強度をポリシーで利用する機能が含まれます。</p></li> <li><p><strong>Azure Entra ID Premium P2</strong>: カスタム認証強度を作成・利用するには、このライセンスが必要です。また、Identity Protectionからのリアルタイムのリスク検出と連携した条件付きアクセス ポリシー (リスクベースCA) を利用する場合もP2ライセンスが必要となります[1]。</p></li> </ul> <p>これらのライセンスは、ユーザーあたりの月額料金で提供されます。認証強度自体に追加の直接的なコストは発生しませんが、P2ライセンスの有無が利用できる機能の範囲を決定します。コスト最適化のためには、P1またはP2ライセンスが必要なユーザーのみに割り当て、不必要なライセンス付与を避けることが重要です。</p> <h2 class="wp-block-heading">落とし穴と注意点</h2> <p>認証強度の導入にはいくつかの潜在的な落とし穴があり、注意深い計画とテストが必要です。</p> <ul class="wp-block-list"> <li><p><strong>ロックアウトのリスク</strong>: 認証強度ポリシーは非常に強力であるため、誤って設定すると、管理者を含むすべてのユーザーがリソースにアクセスできなくなる「ロックアウト」が発生する可能性があります。</p> <ul> <li><p><strong>対策</strong>:</p> <ul> <li><p>常に<strong>緊急アクセスアカウント</strong>を用意し、条件付きアクセス ポリシーから除外することを強く推奨します。これらのアカウントは厳重に管理し、通常の運用では使用しません。</p></li> <li><p>ポリシーは必ず<strong>「レポートのみ」モード</strong>から開始し、影響を慎重に監視します。</p></li> <li><p>段階的な展開 (特定のテストグループから開始し、徐々に拡大) を行います。</p></li> </ul></li> </ul></li> <li><p><strong>ユーザーエクスペリエンスへの影響</strong>: ユーザーが要求される認証強度に対応できるMFA方法を登録していない場合、アクセスがブロックされます。これはユーザーの混乱や不満につながる可能性があります。</p> <ul> <li><strong>対策</strong>: 導入前にユーザーへの十分な周知と、新しいMFA方法 (例: FIDO2セキュリティキー) の登録手順を提供します。</li> </ul></li> <li><p><strong>従来のMFAとの混同</strong>: 「MFAを要求する」と「認証強度を要求する」の違いを明確に理解する必要があります。認証強度は、単なるMFAではなく、MFAの「種類」を制限します。</p></li> <li><p><strong>MFA登録ポリシーとの整合性</strong>: 認証強度で要求されるMFA方法が、Entra IDのMFA登録ポリシーで有効になっており、ユーザーが登録可能であることを確認する必要があります。</p></li> <li><p><strong>カスタム認証強度の管理</strong>: カスタム認証強度を定義する場合、どの認証方法を許可し、どのセキュリティレベルに対応するかを慎重に設計する必要があります。複雑になりすぎると管理が困難になる可能性があります。</p></li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>Azure Entra IDの条件付きアクセス認証強度は、現代の脅威環境において組織のリソースを保護するための不可欠な機能です。特定のMFA方法を強制することで、フィッシング耐性を高め、ゼロトラストの原則を強化します。導入にはAzure AD Premium P1/P2ライセンスが必要であり、特にカスタム強度やリスクベースのCAを利用する場合はP2が求められます。</p> <p>設定はAzureポータルまたはGraph API経由で可能ですが、ロックアウトのリスクを避けるために「レポートのみ」モードでのテストと段階的な展開が極めて重要です。サインインログや監査ログを活用した継続的な運用監視も欠かせません。クラウドアーキテクトとして、この強力なツールを適切に設計・導入・運用することで、組織のセキュリティ体制を飛躍的に向上させることができます。</p> <hr/> <p>[1] Microsoft Learn: What is authentication strength for Conditional Access? (更新日: 2024年1月23日, Microsoft) [2] Microsoft Learn: Configure a custom authentication strength for Conditional Access (更新日: 2023年11月22日, Microsoft) [3] Microsoft Graph API Documentation: conditionalAccessPolicy resource type (更新日: 2023年12月14日, Microsoft) [4] Microsoft Learn: Monitor and report on Conditional Access (更新日: 2023年9月28日, Microsoft)</p>

graph TD
    A["ユーザーがアプリケーションへアクセスを試行"] --> B("Azure Entra IDが要求を受信")
    B --> C{"条件付きアクセス ポリシーの評価"};
    C -- ユーザー/グループ | アプリケーション | デバイス | 場所 | サインインリスク --> D{"ポリシーが適用されるか？"};
    D -- いいえ --> E["アクセス許可"];
    D -- はい --> F{"認証強度が要求されているか？"};
    F -- いいえ (従来のMFA) --> G["MFAチャレンジ"];
    F -- はい (特定のMFA方法) --> H["指定された認証強度でのMFAチャレンジ"];
    G --> I{"認証成功？"};
    H --> I;
    I -- はい --> J["アクセス許可"];
    I -- いいえ --> K["アクセス拒否"];

    style J fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    style K fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px;

# モジュールのインストール（未インストールの場合は実行）


# Install-Module -Name Microsoft.Graph.Identity.SignIns

# Graph APIに接続（初回は認証プロンプトが表示されます）


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

# 認証強度IDの取得


# 組み込みの「MFA Strength - High (最も安全な組み込み)」のIDを取得する例


# Get-MgIdentityConditionalAccessAuthenticationStrength -Filter "displayName eq 'MFA Strength - High (最も安全な組み込み)'" | Select-Object Id, DisplayName

$authenticationStrengthId = "f5ed389a-0744-4860-9884-fd33406e129f" # MFA Strength - High の組み込みID (2024年1月23日時点のMicrosoft Learn情報に基づく[1])

# ポリシーの対象ユーザーを設定

$users = @{
    IncludeUsers = @("All") # すべてのユーザーを対象とする例
    #ExcludeUsers = @("admin@contoso.com") # 特定のユーザーを除外する例

}

# ポリシーの対象アプリケーションを設定

$applications = @{
    IncludeApplications = @("All") # すべてのクラウドアプリを対象とする例
    #IncludeApplications = @("6f0cd49f-f227-466d-a363-066ac06dfa99") # 特定のアプリIDを指定する例 (例: Microsoft Teams)

}

# アクセス制御 - 付与を設定

$grantControls = @{
    BuiltInAuthenticationStrength = @{
        Id = $authenticationStrengthId
    }
}

# ポリシーオブジェクトの作成

$conditionalAccessPolicy = @{
    DisplayName = "PhishingResistantMFA for All Apps - PowerShell ({{jst_today}})"
    State = "enabledForReportingButBlocked" # レポートのみで有効化し、影響を監視推奨
    Conditions = @{
        Users = $users
        Applications = $applications
        ClientAppTypes = @("all")
    }
    GrantControls = @{
        Operator = "OR" # 複数の付与コントロールがある場合（今回は認証強度のみ）
        BuiltInAuthenticationStrength = @($grantControls.BuiltInAuthenticationStrength)
    }
}

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

New-MgIdentityConditionalAccessPolicy -BodyParameter $conditionalAccessPolicy

# 注意：作成後、AzureポータルやGraph Explorerでポリシーが正しく作成されたか確認してください。


# レポートモードでしばらく運用し、問題がなければStateを "enabled" に変更してください。