本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure AD条件付きアクセス（Microsoft Entra ID Conditional Access）設計とMFAの実践
クラウド環境におけるセキュリティの根幹をなすのが、適切なアイデンティティとアクセス管理です。Microsoft Entra ID（旧Azure AD）の条件付きアクセス（Conditional Access: CA）は、Zero Trustの原則に基づき、特定の条件が満たされた場合にのみリソースへのアクセスを許可する強力な機能です。本記事では、クラウドアーキテクトの視点から、Microsoft Entra IDにおけるCAポリシーと多要素認証（MFA）の設計、実装、運用について実践的なアプローチを解説します。
1. アーキテクチャの概要
Microsoft Entra IDの条件付きアクセスは、ユーザー、デバイス、場所、アプリケーション、リスクレベルなどの多様なシグナル（条件）に基づいて、リソースへのアクセスを許可または拒否するアクセス制御ポリシーエンジンです。これにより、組織はセキュリティ体制を強化し、規制要件に準拠することができます。MFAは、CAポリシーの最も一般的なアクセス制御の一つであり、ユーザー認証の強度を大幅に向上させます。
条件付きアクセスフローの概念図
ユーザーがMicrosoft Entra IDで保護されたアプリケーションにアクセスしようとすると、Entra IDは設定されたCAポリシーを評価します。この評価は、以下のようなフローで実行されます。
graph TD
A["ユーザー/デバイス"] --> |1. アクセス要求| B("Microsoft Entra ID")
B --> |2. 認証実行| C{"認証情報提示"}
C --> |3. ポリシー評価シグナル収集| D("条件付きアクセス ポリシーエンジン")
D --> |4. 条件評価| E{"ポリシーの条件に一致?"}
E -- "Yes" --> F{"アクセス制御の適用"}
F -- "MFA要求" --> G["MFAプロンプト"]
G --> |5. MFA成功| H["アクセス許可"]
F -- "アクセスブロック" --> I["アクセス拒否"]
E -- "No" --> H
H --> J["対象アプリケーション"]
I --> J
図1：条件付きアクセスの概要フロー
このフローでは、ユーザーからのアクセス要求に対し、Microsoft Entra IDはCAポリシーエンジンを通じて、ユーザー、デバイス、場所などのシグナルを収集し、定義された条件に照らし合わせてアクセス制御（MFA要求、アクセスブロックなど）を適用します。
アイデンティティと権限境界
Microsoft Entra ID: アイデンティティプロバイダーとして、ユーザーアカウント、グループ、アプリケーションを管理します。CAポリシーの評価と強制の中核を担います。
ロール: Microsoft Entra IDには、グローバル管理者、条件付きアクセス管理者などの組み込みロールがあります。CAポリシーの管理には、「条件付きアクセス管理者」ロールが推奨されます。
条件付きアクセス (CA): アクセス要求が特定の条件を満たす場合に、MFAの強制、デバイスの準拠、セッション制御などの追加要件を課すためのポリシー定義層です。
Microsoft Defender for Cloud Apps (MDCA): CAポリシーと連携し、リアルタイムのセッション制御や異常検出を提供し、クラウドアプリケーションへのアクセスをさらに保護します。
2. 設定手順
ここでは、Graph APIを用いてMFAを要求するシンプルな条件付きアクセスポリシーを作成する手順を示します。このポリシーは、特定のグループのユーザーがクラウドアプリケーションにアクセスする際にMFAを強制するものです。
前提条件
Microsoft Entra ID P1またはP2ライセンス
Microsoft Graph PowerShell SDKのインストール
Install-Module Microsoft.Graph -Scope CurrentUser
適切な権限を持つアカウントでの認証（例: 条件付きアクセス管理者ロール）
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
CAポリシーの作成 (Graph API)
MFAを強制するCAポリシーを作成するには、以下のPowerShellスクリプトを実行します。この例では、「営業部」グループのメンバーが「すべてのクラウドアプリ」にアクセスする際にMFAを要求します。
# ポリシーに含めるユーザーグループのオブジェクトIDを取得（例として「営業部」グループ）
# 実際の環境に合わせてオブジェクトIDを調査してください。
$groupId = (Get-MgGroup -Filter "DisplayName eq '営業部'").Id
# 条件付きアクセスポリシー定義のJSONボディ
$policyJson = @'
{
"displayName": "営業部MFA強制ポリシー",
"state": "enabled", # または "enabledForReportingButNotEnforced" でレポート専用モード
"conditions": {
"users": {
"includeGroups": ["{groupId}"],
"excludeUsers": [
"a1b2c3d4-e5f6-7890-1234-567890abcdef" # 例: 緊急アクセスアカウントの除外
]
},
"applications": {
"includeApplications": ["All"]
},
"clientAppTypes": {
"includeClientAppTypes": ["all"]
},
"locations": {
"includeLocations": ["All"]
}
},
"grantControls": {
"operator": "OR",
"builtInControls": ["mfa"]
}
}
'@
# グループIDをJSON文字列に埋め込む
$policyBody = $policyJson.Replace("{groupId}", $groupId) | ConvertFrom-Json
# Graph APIを使用して条件付きアクセスポリシーを作成
try {
New-MgIdentityConditionalAccessPolicy -BodyParameter $policyBody | Format-List
Write-Host "条件付きアクセスポリシー '営業部MFA強制ポリシー' が正常に作成されました。"
} catch {
Write-Host "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}
# MFAの認証方法ポリシーの確認/設定（ユーザーがMFAを登録できるようにする）
# これはCAポリシーとは別に設定します。
Write-Host "MFA認証方法ポリシーの確認と設定は、Microsoft Entra管理センターの [保護] > [認証方法] > [ポリシー] で行います。"
Write-Host "または、Graph APIの 'beta' エンドポイントで構成可能です。"
コメント:
前提条件: Microsoft Entra ID P1/P2ライセンスとGraph SDKのインストール、適切な認証スコープが必要です。
入力:
$groupIdにはMFAを強制したいユーザーグループのオブジェクトIDを指定します。出力: 作成されたポリシーの詳細が出力されます。エラー時にはエラーメッセージが表示されます。
計算量: API呼び出し1回（O(1)）。
メモリ条件: 小規模なJSONボディとAPIレスポンスを処理するため、特段のメモリ要件はありません。
state を enabledForReportingButNotEnforced に設定することで、ポリシーを運用環境に展開する前に、影響をレポートで確認する「レポート専用モード」でテストできます。これにより、意図しないアクセスブロックを防げます。
3. 運用監視
条件付きアクセスとMFAの運用監視は、セキュリティ体制の維持と問題発生時の迅速な対応に不可欠です。
可観測性
サインインログ: Microsoft Entra IDは、すべての認証試行の詳細なログを記録します。CAポリシーがどのように評価され、MFAが要求されたか、アクセスが許可または拒否されたかを確認できます。
管理センター:
Microsoft Entra 管理センター>Identity>監視と正常性>サインインログログエントリには、ユーザー、アプリケーション、場所、デバイスの状態、ポリシーの結果などが含まれます。
監査ログ: CAポリシーの作成、変更、削除などの管理操作が記録されます。
- 管理センター:
Microsoft Entra 管理センター>Identity>監視と正常性>監査ログ
- 管理センター:
ログの出力と分析
これらのログは、Log Analyticsワークスペースに診断設定として転送することで、高度なクエリ（KQL）やアラート設定が可能になります。
# Microsoft Entra サインインログと監査ログをLog Analyticsワークスペースに転送する診断設定の例
# 事前にLog Analyticsワークスペースを作成しておく必要があります。
$workspaceId = "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroup}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}" # ワークスペースIDを指定
$resourceId = "/providers/Microsoft.Aadiam/diagnosticSettings/serviceLogs"
New-AzDiagnosticSetting -Name "EntraID-Logs-to-LogAnalytics" `
-ResourceId "/providers/Microsoft.Aadiam/diagnosticSettings/serviceLogs" ` # Entra IDの特定のリソースID
-WorkspaceId $workspaceId `
-Categories "SignInLogs", "AuditLogs" ` # 転送するログカテゴリ
-MetricCategory "AllMetrics" `
-Enabled $true
Write-Host "Microsoft Entra IDのサインインログと監査ログの診断設定が完了しました。"
コメント:
前提条件: Azureサブスクリプション、Log Analyticsワークスペース、
Az.Monitorモジュール（Install-Module Az.Monitor）。入力:
$workspaceIdにLog AnalyticsワークスペースのリソースIDを正確に指定する必要があります。resourceIdはMicrosoft Entra IDの診断設定における特殊なIDです。出力: 診断設定の成功メッセージ。
計算量: API呼び出し1回（O(1)）。
KQLクエリ例（過去24時間でMFAが要求され、かつ失敗したサインインを検索）:
SigninLogs | where TimeGenerated > ago(24h) | where ConditionalAccessPolicies has "MFA was required" | where Status.errorCode != 0 | project TimeGenerated, UserDisplayName, UserPrincipalName, AppDisplayName, Status, ConditionalAccessPolicies, Location | sort by TimeGenerated desc
SLA/バックアップ/DR
SLA: Microsoft Entra IDは、Microsoftによって高可用性とパフォーマンスのSLAが提供されています（通常99.9%）。条件付きアクセスを含むサービス全体がこのSLAの対象です。
バックアップ/DR: Entra IDのデータ（ユーザー、グループ、ポリシーなど）のバックアップと災害復旧はMicrosoftによって管理されており、顧客側での具体的なバックアップ操作は不要です。ポリシー設定の変更は監査ログに記録され、以前の設定に戻すことは可能ですが、定期的なポリシー設定のコード化（IaC）がベストプラクティスです。
4. セキュリティ強化
条件付きアクセスとMFAは、エンタープライズセキュリティにおいて不可欠な要素です。
Zero Trust原則の実現: 「決して信頼せず、常に検証する」というZero Trustの考え方をCAポリシーで具現化します。すべてのアクセス要求を明示的に検証し、最小特権の原則を適用します。
レガシー認証のブロック: CAポリシーを使用してExchange ActiveSyncなどのレガシー認証プロトコルをブロックすることで、MFAを回避されるリスクを低減できます。これは一般的な攻撃ベクトルです。
リスクベース条件付きアクセス: Microsoft Entra Identity Protectionと連携し、ユーザーやサインインのリスクレベルに基づいてMFAを要求したり、パスワード変更を強制したりするポリシーを適用できます。
Microsoft Defender for Cloud Apps (MDCA) との連携: CAポリシーでMDCAをセッション制御プロバイダーとして利用することで、アクセス後にセッションを監視し、機密情報のダウンロードブロックや特定の操作の制限を行うことができます。
5. コスト最適化
条件付きアクセスを利用するには、Microsoft Entra IDのP1またはP2ライセンスが必要です。
ライセンスモデル:
Microsoft Entra ID P1: 条件付きアクセス、MFA（Microsoft Authenticatorアプリなど）、Self-Service Password Reset (SSPR) などの基本的なアイデンティティ管理機能を提供します。
Microsoft Entra ID P2: P1の全機能に加え、Microsoft Entra Identity Protection（リスクベースCA、リスクイベント検出）、Privileged Identity Management (PIM) などの高度なアイデンティティセキュリティ機能が含まれます。
コスト最適化のポイント:
適切なSKUの選択: 必要な機能に応じてP1またはP2を選択します。リスクベースCAやPIMが不要であれば、P1で十分な場合があります。
ライセンスの割り当て: CAポリシーの対象となるユーザーのみにP1/P2ライセンスを割り当てます。すべてのユーザーにP2を割り当てる必要がないか検討します。
不要なライセンスの棚卸し: 定期的に使用されていないP1/P2ライセンスを棚卸しし、割り当てを解除することで無駄なコストを削減します。
MFA自体には追加コストは発生しませんが、MFAを強制するためのCAポリシー機能はP1/P2ライセンスが必要です。JST {{jst_today}}現在、P1ライセンスはユーザーあたり月額約800円、P2ライセンスは約1,300円です。正確な価格はMicrosoftの公式価格ページでご確認ください[1]。
6. 落とし穴と対策
CAポリシーの設計と導入には、注意すべき落とし穴がいくつか存在します。
緊急アクセスアカウントの除外忘れ: すべてのCAポリシーから、最低2つの緊急アクセスアカウント（グローバル管理者など）を必ず除外してください。これにより、ポリシー設定ミスやIDプロバイダーの障害発生時にシステムからロックアウトされる事態を防ぎます。これらのアカウントは厳重に管理し、使用頻度を監視してください。
広すぎるスコープの初期適用: 最初から「すべてのユーザー」と「すべてのクラウドアプリ」にCAポリシーを適用すると、大規模なロックアウトを引き起こす可能性があります。最初は小規模なテストグループと特定のアプリケーションから開始し、段階的に適用範囲を拡大してください。
ポリシー競合と評価順序: 複数のCAポリシーが存在する場合、評価順序によって意図しない結果が生じることがあります。Microsoft Entra管理センターの「What If」ツールを使用して、特定のユーザーと条件下でどのポリシーが適用され、最終的なアクセス結果がどうなるかをシミュレーションすることが重要です。
レガシー認証プロトコル: 一部のアプリケーションやクライアント（古いバージョンのOfficeクライアントなど）は、MFAに対応していないレガシー認証プロトコルを使用する場合があります。これらの認証をブロックしないと、CAポリシーの効果が半減します。CAポリシーでレガシー認証をブロックするルールを早期に導入し、影響を受けるユーザーにはモダン認証への移行を促す必要があります。
ユーザーエクスペリエンスの考慮: MFA要求が多すぎるとユーザーの生産性を損ない、MFA疲労を引き起こす可能性があります。信頼できるデバイスや場所からのアクセスではMFA頻度を下げるなど、バランスの取れた設計を検討してください。
7. まとめ
Microsoft Entra IDの条件付きアクセスとMFAは、現代のクラウド環境におけるセキュリティの要石です。適切なアーキテクチャ設計、Graph APIを活用した自動化された設定、詳細な運用監視、そして潜在的な落とし穴への対策を講じることで、組織は強固なセキュリティ体制を確立し、Zero Trust原則を実践できます。継続的な評価と改善を通じて、変化する脅威に対応し、より安全なデジタル環境を構築しましょう。
[1] Microsoft Entra ID の料金: https://azure.microsoft.com/ja-jp/pricing/details/active-directory/ (JST {{jst_today}} 確認)
