<p><!--META { "title": "Azure AD B2C カスタムポリシー実装ガイド", "primary_category": "クラウド>Azure", "secondary_categories": ["Azure AD B2C","Identity","Custom Policy"], "tags": ["Azure ADB2C","Identity Experience Framework","Custom Policy","Conditional Access","Graph API","B2C Admin"], "summary": "Azure AD B2Cカスタムポリシーの実装アーキテクチャ、設定、運用監視、セキュリティ、コスト、および落とし穴を解説します。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"Azure AD B2Cカスタムポリシーの実装ガイド。アーキテクチャから運用、セキュリティ、コストまで網羅。複雑な認証要件をセキュアに実現するための具体的な手順と考慮事項を解説します。 #Azure #ADB2C #Identity","hashtags":["#Azure","#ADB2C"]}, "link_hints": ["https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/custom-policy-overview"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure AD B2C カスタムポリシー実装ガイド</h1> <p>Azure AD B2C（Azure Active Directory B2C）は、顧客向けのIDとアクセス管理（CIAM）サービスであり、Webおよびモバイルアプリケーションへのセキュアなアクセスを提供します。標準機能で対応できない複雑な認証フローやユーザー体験を実現するためには、Identity Experience Framework（IEF）に基づくカスタムポリシーの実装が不可欠です。本ガイドでは、カスタムポリシーのアーキテクチャから設定、運用、セキュリティ、コスト、そして一般的な落とし穴までを詳細に解説します。</p> <h2 class="wp-block-heading">1. アーキテクチャ</h2> <p>Azure AD B2Cカスタムポリシーは、Identity Experience Framework (IEF) と呼ばれるオーケストレーションエンジン上で動作するXMLファイル群で構成されます。これにより、ユーザーのサインアップ、サインイン、プロファイル編集、パスワードリセットといったIDジャーニーを高度にカスタマイズできます。標準ポリシーと異なり、外部IDプロバイダー（IdP）連携、REST API呼び出しによるカスタムロジックの組み込み、多要素認証（MFA）の強制といった複雑なシナリオに対応可能です[1]。</p> <h3 class="wp-block-heading">1.1. カスタムポリシーの構成要素</h3> <ul class="wp-block-list"> <li><p><strong>TrustFrameworkBase.xml</strong>: 基本的なクレーム定義、変換、技術プロファイル、IDプロバイダー定義が含まれます。</p></li> <li><p><strong>TrustFrameworkExtensions.xml</strong>: Baseポリシーを拡張し、テナント固有の設定やカスタムの技術プロファイルを定義します。</p></li> <li><p><strong>SignUpOrSignIn.xml / ProfileEdit.xml / PasswordReset.xml</strong>: アプリケーションから呼び出される「証明書利用者 (Relying Party)」ポリシーファイルで、特定のIDジャーニーを定義します。</p></li> </ul> <h3 class="wp-block-heading">1.2. 認証フローの概念図</h3> <p>ユーザーがアプリケーションを介してAzure AD B2Cに認証リクエストを送信すると、Azure AD B2Cはカスタムポリシーを適用し、IEFが定義されたIDジャーニーを実行します。このジャーニーには、B2Cディレクトリ内のユーザー情報へのアクセス、外部IdPとの連携、カスタムAPIの呼び出しなどが含まれます。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD A["ユーザー"] --> |1. 認証リクエスト| B("アプリケーション") B --> |2. 認証要求 (OAuth/OpenID Connect)| C["Azure AD B2C"] C --> |3. カスタムポリシー適用| D("(Identity Experience Framework (IEF"))) D --> |4. クレーム取得/設定| E["Azure AD B2C ディレクトリ"] D --> |5. 外部IdP連携 (例: Google)| F["外部IDプロバイダー"] D --> |6. REST API呼び出し (カスタムロジック)| G["REST API(\"例: 本人確認\")"] E --> D F --> D G --> D D --> |7. 認証結果 (クレームセット)| C C --> |8. IDトークン/アクセストークン| B B --> |9. アプリケーションアクセス| A </pre></div> <h2 class="wp-block-heading">2. 設定手順</h2> <p>カスタムポリシーの実装は、XMLファイルの編集とアップロードが中心となります。ここでは、一般的な手順をPowerShellスクリプトを用いて説明します。</p> <h3 class="wp-block-heading">2.1. 前提条件</h3> <ul class="wp-block-list"> <li><p>Azure AD B2C テナントが構成済みであること。</p></li> <li><p>Graph API にアクセスするためのアプリケーション登録と権限が付与されていること（Policy.ReadWrite.TrustFramework）。</p></li> <li><p>PowerShell AzureAD モジュールがインストールされていること。</p></li> </ul> <h3 class="wp-block-heading">2.2. カスタムポリシーファイルの準備</h3> <p>Azure AD B2C のGitHubリポジトリからスターターパックをダウンロードし、テナント固有の情報にカスタマイズします[2]。</p> <ol class="wp-block-list"> <li><p>GitHubからスターターパックをクローンまたはダウンロードします。 <code>https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack</code></p></li> <li><p><code>TrustFrameworkExtensions.xml</code> を開き、テナント名やアプリケーションIDなどのプレースホルダーを実際の値に置き換えます。</p></li> <li><p>必要に応じて、新しい技術プロファイルやオーケストレーションステップを定義し、IDジャーニーをカスタマイズします。</p></li> </ol> <h3 class="wp-block-heading">2.3. カスタムポリシーのアップロード</h3> <p>カスタムポリシーは、Azure PortalまたはGraph API（PowerShell/CLI）を介してアップロードできます。以下はPowerShellを使用したGraph API経由でのアップロード例です。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 前提: Azure AD に接続済みであること (Connect-MgGraph -Scopes "Policy.ReadWrite.TrustFramework") # 変数定義 $b2cTenantName = "yourb2ctenant.onmicrosoft.com" $policyDirectory = "C:\AzureB2CCustomPolicies" # カスタムポリシーXMLファイルが保存されているディレクトリ # ポリシーファイルのパスを定義 $basePolicyPath = Join-Path $policyDirectory "TrustFrameworkBase.xml" $extensionsPolicyPath = Join-Path $policyDirectory "TrustFrameworkExtensions.xml" $signInPolicyPath = Join-Path $policyDirectory "SignUpOrSignIn.xml" $profileEditPolicyPath = Join-Path $policyDirectory "ProfileEdit.xml" $passwordResetPolicyPath = Join-Path $policyDirectory "PasswordReset.xml" # TrustFrameworkBase.xml のアップロードまたは更新 Write-Host "Uploading or updating TrustFrameworkBase.xml..." $basePolicyContent = Get-Content $basePolicyPath -Raw Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/trustFramework/policies" -Body (@{id="B2C_1A_TrustFrameworkBase"; content=$basePolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue Invoke-MgGraphRequest -Method PUT -Uri "https://graph.microsoft.com/beta/trustFramework/policies/B2C_1A_TrustFrameworkBase" -Body (@{content=$basePolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue # TrustFrameworkExtensions.xml のアップロードまたは更新 Write-Host "Uploading or updating TrustFrameworkExtensions.xml..." $extensionsPolicyContent = Get-Content $extensionsPolicyPath -Raw Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/trustFramework/policies" -Body (@{id="B2C_1A_TrustFrameworkExtensions"; content=$extensionsPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue Invoke-MgGraphRequest -Method PUT -Uri "https://graph.microsoft.com/beta/trustFramework/policies/B2C_1A_TrustFrameworkExtensions" -Body (@{content=$extensionsPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue # 他の証明書利用者ポリシー (SignUpOrSignIn.xml など) のアップロードまたは更新 # 各ポリシーについて同様の操作を繰り返す Write-Host "Uploading or updating SignUpOrSignIn.xml..." $signInPolicyContent = Get-Content $signInPolicyPath -Raw Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/trustFramework/policies" -Body (@{id="B2C_1A_signup_signin"; content=$signInPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue Invoke-MgGraphRequest -Method PUT -Uri "https://graph.microsoft.com/beta/trustFramework/policies/B2C_1A_signup_signin" -Body (@{content=$signInPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue Write-Host "Policy upload process complete." # 注釈: # - Connect-MgGraph で Policy.ReadWrite.TrustFramework スコープが必要です。 # - POSTは新規作成、PUTは更新に使用します。エラーハンドリングのため両方を試行しています。 # - ポリシーIDはXMLファイルのTrustFrameworkPolicy要素のPolicyId属性と一致させる必要があります。 </pre> </div> <h2 class="wp-block-heading">3. 運用監視</h2> <p>Azure AD B2Cの運用監視は、ユーザーの認証体験の健全性を保つ上で重要です。</p> <h3 class="wp-block-heading">3.1. 可観測性</h3> <ul class="wp-block-list"> <li><p><strong>診断設定</strong>: Azure AD B2Cの診断設定を構成し、監査ログとサインインログをLog Analyticsワークスペースに送信します[3]。これにより、カスタムポリシーの実行状況、エラー、ユーザーアクティビティを詳細に分析できます。</p></li> <li><p><strong>Application Insights</strong>: カスタムポリシー内で呼び出されるREST APIや、外部システムとの連携に関するログをApplication Insightsに集約することで、エンドツーエンドのトレースが可能になります。</p></li> <li><p><strong>アラート</strong>: Log Analyticsクエリを使用して、特定の認証エラー（例: <code>ResultType eq "50000"</code>）や異常なサインイン試行を検出し、Azure Monitorアラートを設定します。</p></li> </ul> <h3 class="wp-block-heading">3.2. SLAとDR/バックアップ</h3> <p>Azure AD B2Cは、Premium P1/P2 SKUにおいて99.9%のSLAを提供します[4]。カスタムポリシー自体はXMLファイルであり、Gitなどのバージョン管理システムで管理することでバックアップと復元が容易になります。災害復旧（DR）戦略としては、カスタムポリシーのコードを地理的に冗長なリポジトリに保存し、複数の環境（開発、テスト、本番）へのデプロイを自動化することが推奨されます。</p> <h2 class="wp-block-heading">4. セキュリティ</h2> <p>アイデンティティ管理においてセキュリティは最優先事項です。Azure AD B2Cは様々なセキュリティ機能を活用できます。</p> <h3 class="wp-block-heading">4.1. アイデンティティと権限境界</h3> <ul class="wp-block-list"> <li><p><strong>Azure RBAC（ロールベースのアクセス制御）</strong>: Azure AD B2Cの管理者には、必要な最小限の権限を持つカスタムロールまたは組み込みロール（例: B2C ユーザーフロー管理者、Identity Governance 管理者）を付与します。Graph APIアクセスに利用するサービスプリンシパルにも同様に最小権限（Policy.ReadWrite.TrustFramework）を付与します。</p></li> <li><p><strong>Entra ID (Azure AD) Conditional Access（条件付きアクセス）</strong>: Azure AD B2C Premium P1またはP2ライセンスを導入することで、条件付きアクセスをカスタムポリシーに適用できます[5]。例えば、特定の国のIPアドレスからのアクセスをブロックしたり、高リスクのサインインに対してMFAを強制したりできます。</p></li> </ul> <h3 class="wp-block-heading">4.2. その他のセキュリティ対策</h3> <ul class="wp-block-list"> <li><p><strong>Key Vaultとの連携</strong>: カスタムポリシー内で外部REST APIを呼び出す際のシークレット（APIキーなど）は、Azure Key Vaultに保存し、ポリシーから参照するように構成します。これにより、XMLファイルに直接シークレットをハードコードするリスクを排除できます。</p></li> <li><p><strong>Microsoft Defender for Cloud Apps</strong>: Azure AD B2Cの活動を監視し、異常な行動やポリシー違反を検出するためにDefender for Cloud Apps（旧称 Microsoft Cloud App Security）と連携することが可能です。</p></li> </ul> <h2 class="wp-block-heading">5. コスト</h2> <p>Azure AD B2Cの料金は、月間アクティブユーザー（MAU）数に基づいています[4]。</p> <ul class="wp-block-list"> <li><p><strong>MAUベースの課金</strong>: ユーザーが認証やカスタムポリシーを利用した回数ではなく、月に一度でも認証を行ったユニークユーザー数で課金されます。</p></li> <li><p><strong>無料利用枠</strong>: 最初の50,000 MAUまでは無料で利用できます。</p></li> <li><p><strong>Premium P1/P2</strong>: 特定の高度な機能（条件付きアクセス、Identity Protection、Connectors to SaaS apps）を利用するには、Azure AD Premium P1またはP2ライセンスが必要です。これらのライセンスは、ユーザー単位で追加料金が発生します。カスタムポリシー自体はどのSKUでも利用可能ですが、セキュリティ機能を強化する場合にはP1/P2の検討が必要です。</p></li> <li><p><strong>コスト最適化</strong>: 無料利用枠を活用し、不要なMAUを発生させないよう設計を最適化します。また、カスタムポリシーが複雑な外部API呼び出しを多数含む場合、関連するAzureサービスの利用料も考慮に入れる必要があります。</p></li> </ul> <h2 class="wp-block-heading">6. 落とし穴と対策</h2> <p>カスタムポリシーの導入にはいくつかの課題があります。</p> <ul class="wp-block-list"> <li><p><strong>XMLの複雑性とデバッグ</strong>: IEFポリシーは複雑なXML構造を持ち、学習曲線が急です。エラーメッセージが不明瞭な場合も多く、デバッグには「Application Insights」との連携や「TrustFrameworkPolicy」ログの活用が不可欠です。</p></li> <li><p><strong>バージョン管理とCI/CD</strong>: ポリシーの変更はアプリケーションに直接影響するため、Gitなどのバージョン管理システムで厳密に管理し、CI/CDパイプライン（例: Azure DevOps Pipelines）を構築して自動デプロイを行うことが推奨されます[6]。</p></li> <li><p><strong>外部システム連携の堅牢性</strong>: REST APIの呼び出しは、ネットワーク遅延や外部システムのダウンタイムに影響されます。ポリシーには、タイムアウト設定、リトライメカニズム、エラーハンドリング（例: フォールバックパス）を実装し、堅牢性を高める必要があります。</p></li> <li><p><strong>パフォーマンス</strong>: カスタムポリシーが多数のステップや外部API呼び出しを含む場合、認証に時間がかかることがあります。不要なクレーム変換の削減や、REST APIの応答時間最適化によってパフォーマンスを改善します。</p></li> </ul> <h2 class="wp-block-heading">7. まとめ</h2> <p>Azure AD B2Cカスタムポリシーは、複雑な認証要件を持つアプリケーションに対して、高度な柔軟性とカスタマイズ性を提供します。本ガイドで解説したアーキテクチャ、設定手順、運用監視、セキュリティ対策、コスト、そして一般的な落とし穴と対策を理解し、適切に適用することで、セキュアでユーザーフレンドリーなCIAMソリューションを構築できます。XMLの学習コストやデバッグの複雑性はありますが、適切な設計とCI/CDの導入により、そのメリットを最大限に引き出すことが可能です。</p> <hr/> <p><strong>参照情報</strong></p> <p>[1] Microsoft Learn. “Azure Active Directory B2C のカスタム ポリシーの概要”. 最終更新日: 2024年5月10日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/custom-policy-overview">https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/custom-policy-overview</a> [2] Azure-Samples. “active-directory-b2c-custom-policy-starterpack”. GitHub. <a href="https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack">https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack</a> [3] Microsoft Learn. “Azure AD B2C で監査ログを監視する”. 最終更新日: 2024年5月10日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/manage-audit-logs">https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/manage-audit-logs</a> [4] Microsoft Azure. “Active Directory B2C の料金”. <a href="https://azure.microsoft.com/ja-jp/pricing/details/active-directory-b2c/">https://azure.microsoft.com/ja-jp/pricing/details/active-directory-b2c/</a> [5] Microsoft Learn. “Azure Active Directory B2C で条件付きアクセスを有効にする”. 最終更新日: 2024年5月10日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/conditional-access-identity-protection">https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/conditional-access-identity-protection</a> [6] Microsoft Learn. “Azure AD B2C でカスタム ポリシーの CI/CD をデプロイする”. 最終更新日: 2024年5月10日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/deploy-custom-policies-devops">https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/deploy-custom-policies-devops</a></p>

flowchart TD
    A["ユーザー"] --> |1. 認証リクエスト| B("アプリケーション")
    B --> |2. 認証要求 (OAuth/OpenID Connect)| C["Azure AD B2C"]
    C --> |3. カスタムポリシー適用| D("(Identity Experience Framework (IEF")))
    D --> |4. クレーム取得/設定| E["Azure AD B2C ディレクトリ"]
    D --> |5. 外部IdP連携 (例: Google)| F["外部IDプロバイダー"]
    D --> |6. REST API呼び出し (カスタムロジック)| G["REST API(\"例: 本人確認\")"]
    E --> D
    F --> D
    G --> D
    D --> |7. 認証結果 (クレームセット)| C
    C --> |8. IDトークン/アクセストークン| B
    B --> |9. アプリケーションアクセス| A

# 前提: Azure AD に接続済みであること (Connect-MgGraph -Scopes "Policy.ReadWrite.TrustFramework")

# 変数定義

$b2cTenantName = "yourb2ctenant.onmicrosoft.com"
$policyDirectory = "C:\AzureB2CCustomPolicies" # カスタムポリシーXMLファイルが保存されているディレクトリ

# ポリシーファイルのパスを定義

$basePolicyPath = Join-Path $policyDirectory "TrustFrameworkBase.xml"
$extensionsPolicyPath = Join-Path $policyDirectory "TrustFrameworkExtensions.xml"
$signInPolicyPath = Join-Path $policyDirectory "SignUpOrSignIn.xml"
$profileEditPolicyPath = Join-Path $policyDirectory "ProfileEdit.xml"
$passwordResetPolicyPath = Join-Path $policyDirectory "PasswordReset.xml"

# TrustFrameworkBase.xml のアップロードまたは更新

Write-Host "Uploading or updating TrustFrameworkBase.xml..."
$basePolicyContent = Get-Content $basePolicyPath -Raw
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/trustFramework/policies" -Body (@{id="B2C_1A_TrustFrameworkBase"; content=$basePolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue
Invoke-MgGraphRequest -Method PUT -Uri "https://graph.microsoft.com/beta/trustFramework/policies/B2C_1A_TrustFrameworkBase" -Body (@{content=$basePolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue

# TrustFrameworkExtensions.xml のアップロードまたは更新

Write-Host "Uploading or updating TrustFrameworkExtensions.xml..."
$extensionsPolicyContent = Get-Content $extensionsPolicyPath -Raw
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/trustFramework/policies" -Body (@{id="B2C_1A_TrustFrameworkExtensions"; content=$extensionsPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue
Invoke-MgGraphRequest -Method PUT -Uri "https://graph.microsoft.com/beta/trustFramework/policies/B2C_1A_TrustFrameworkExtensions" -Body (@{content=$extensionsPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue

# 他の証明書利用者ポリシー (SignUpOrSignIn.xml など) のアップロードまたは更新


# 各ポリシーについて同様の操作を繰り返す

Write-Host "Uploading or updating SignUpOrSignIn.xml..."
$signInPolicyContent = Get-Content $signInPolicyPath -Raw
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/trustFramework/policies" -Body (@{id="B2C_1A_signup_signin"; content=$signInPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue
Invoke-MgGraphRequest -Method PUT -Uri "https://graph.microsoft.com/beta/trustFramework/policies/B2C_1A_signup_signin" -Body (@{content=$signInPolicyContent} | ConvertTo-Json) -ErrorAction SilentlyContinue

Write-Host "Policy upload process complete."

# 注釈:


# - Connect-MgGraph で Policy.ReadWrite.TrustFramework スコープが必要です。


# - POSTは新規作成、PUTは更新に使用します。エラーハンドリングのため両方を試行しています。


# - ポリシーIDはXMLファイルのTrustFrameworkPolicy要素のPolicyId属性と一致させる必要があります。