本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Microsoft Entra ID条件付きアクセス実践ガイド
Microsoft Entra ID（旧Azure Active Directory）の条件付きアクセス（Conditional Access: CA）は、ゼロトラストセキュリティモデルを実現するための重要な機能です。ユーザー、デバイス、場所、アプリケーション、リアルタイムのリスクなど、さまざまな条件に基づいてアクセス制御を適用し、組織のリソースを保護します。本ガイドでは、条件付きアクセスのアーキテクチャから設定、運用、セキュリティ、コスト、そして実践における落とし穴までを網羅的に解説します。
1. アーキテクチャ
Microsoft Entra IDは、組織のアイデンティティ管理の中心となるクラウドベースのディレクトリサービスです。条件付きアクセスは、このEntra ID上で動作するポリシーエンジンであり、リソースへのアクセス要求が来た際に、事前定義された条件に基づいてアクセスを許可、制限、またはブロックします。
条件付きアクセスは、以下の主要なコンポーネントと連携して動作します。
Microsoft Entra ID: ユーザー、グループ、アプリケーションの登録、認証の実行。
条件付きアクセス ポリシー: アクセス制御のルールセット。
Entra ID Identity Protection: ユーザーとサインインのリアルタイムリスク検出。Premium P2ライセンスで利用可能。検出されたリスクレベルをCAポリシーの条件として利用できます。
Microsoft Defender for Cloud Apps (MDCA): クラウドアプリのシャドーIT検出、リアルタイムセッション制御、アクセス制御。MDCAは条件付きアクセスと連携し、セッションポリシー（例えば、ダウンロードの禁止やコピー＆ペーストの制限）を適用します。
デバイスの準拠性: Microsoft IntuneなどのMDMソリューションで管理されるデバイスの準拠状態をCAポリシーの条件として利用します。
以下のフローチャートは、条件付きアクセスがどのように機能するかを示しています。
flowchart TD
User["ユーザー"] --> A{"認証リクエスト"};
A --> B["Microsoft Entra ID認証"];
B --> C{"条件付きアクセスポリシー評価"};
C -->|"条件:ユーザー/グループ/アプリ/デバイス/場所/リスク"| D{"条件判定"}
D -->|"条件を満たす"| E["アクセス制御を適用"]
D -->|"条件を満たさない"| F["アクセスをブロック"]
E -->|"多要素認証要求/デバイス準拠要求/セッション制御"| G["クラウドアプリケーション"]
E -->|"アクセス許可のみ"| G
F --> H["アクセス拒否"];
C --- I("#quot;Entra ID Identity Protection(リスク評価#quot;)");
E --- J("#quot;Microsoft Defender for Cloud Apps(リアルタイムセッション制御#quot;)");
G --- K["リソース利用"];
subgraph mermaid_group_14["Entra IDエコシステム"]
B
C
I
end図1: 条件付きアクセスのアーキテクチャフロー
2. 設定手順
条件付きアクセス ポリシーは、Azure Portal、Microsoft Graph API、またはPowerShell (Microsoft Graph PowerShell SDK経由) を使用して設定できます。ここでは、Microsoft Graph PowerShell SDK を使用した基本的なポリシー設定例を示します。
前提条件:
Microsoft Entra ID Premium P1以上のライセンス
Microsoft Graph PowerShell SDKのインストール (
Install-Module Microsoft.Graph -Scope CurrentUser)ConditionalAccessPolicy.ReadWrite.Allスコープでの接続 (Connect-MgGraph -Scopes "ConditionalAccessPolicy.ReadWrite.All")
例: 特定のグループ（SalesUsers）がOffice 365アプリにアクセスする際に、多要素認証（MFA）を要求するポリシーを作成する
# 1. 接続スコープの確認と必要に応じた接続
# Connect-MgGraph -Scopes "ConditionalAccessPolicy.ReadWrite.All"
# 2. 対象グループのIDを取得 (例: DisplayNameが"SalesUsers"のグループ)
# $targetGroup = Get-MgGroup -Filter "DisplayName eq 'SalesUsers'"
# $targetGroupId = $targetGroup.Id
# 3. 緊急アクセスアカウント（ブレークグラスアカウント）のユーザーIDを取得
# このアカウントはポリシーの適用対象から常に除外すべきです。
# $emergencyAdminUser = Get-MgUser -UserPrincipalName "breakglass_admin@yourdomain.com"
# $emergencyAdminUserId = $emergencyAdminUser.Id
# 4. ポリシーの定義
$policyName = "SalesUsers_MFA_for_Office365"
$reportOnly = $true # 初期導入時は必ず「レポート専用モード」でテストを推奨。
$policyBody = @{
displayName = $policyName
state = if ($reportOnly) {"reportOnly"} else {"enabled"} # reportOnly または enabled
conditions = @{
users = @{
includeGroups = @($targetGroupId)
excludeUsers = @($emergencyAdminUserId) # 緊急アクセスアカウントを除外
}
applications = @{
# Office 365のApp ID。他の一般的なアプリIDはMicrosoft Learnを参照。
# "All cloud apps" の場合は ["All"] を指定
includeApplications = @("00000003-0000-0ff1-ce00-000000000000")
}
clientAppTypes = @("all") # 全てのクライアントアプリタイプ (ブラウザ、モバイルなど)
}
grantControls = @{
operator = "OR" # AND もしくは OR
builtInControls = @("mfa") # 多要素認証要求
}
}
# 5. ポリシーの作成
# New-MgIdentityConditionalAccessPolicy -BodyParameter $policyBody
# 6. 作成したポリシーの確認
# Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq '$policyName'" | Format-List DisplayName, Id, State, Conditions, GrantControls
コード1: PowerShellによる条件付きアクセスポリシーの作成例
ポリシーはまず reportOnly モードで作成し、影響をテストします。十分な検証後、state を enabled に変更して有効化します。
3. 運用監視
条件付きアクセスの運用では、ポリシーの適用状況と効果を継続的に監視することが不可欠です。
Entra ID サインインログ:
Microsoft Entra管理センターの「監視」セクションにある「サインインログ」で、すべての認証試行と条件付きアクセスの評価結果を確認できます。各サインインイベントには、適用されたCAポリシー、その結果（成功/失敗）、制御（MFA要求など）の詳細が含まれます。
これらのログはLog Analyticsワークスペースにエクスポートし、Kusto Query Language (KQL) を使用して詳細な分析やアラート設定を行うことが推奨されます。
# Log Analyticsワークスペースで、特定の条件付きアクセスポリシーの適用結果を確認
SigninLogs | where TimeGenerated > ago(7d) | extend CAPolicyEvaluations = parse_json(ConditionalAccessPolicies) | mv-expand CAPolicyEvaluations | where CAPolicyEvaluations.displayName == “SalesUsers_MFA_for_Office365” // 特定のポリシー名でフィルタ | project TimeGenerated, UserDisplayName, AppDisplayName, IPAddress, Location, ConditionalAccessStatus, CAPolicyEvaluations.result, CAPolicyEvaluations.grantControls.builtInControls | order by TimeGenerated desc
コード2: KQLによるサインインログからのCA結果抽出例
Entra ID 監査ログ:
- 条件付きアクセス ポリシーの作成、更新、削除などの管理操作は監査ログに記録されます。
レポート専用モード:
- 新規ポリシーをデプロイする際や既存ポリシーを変更する際には、必ず「レポート専用モード」で開始してください。これにより、ポリシーが実際に適用された場合の影響をシミュレーションし、サインインログで結果を確認できますが、実際のアクセスはブロックされません。
SLAとDR/バックアップ:
条件付きアクセス自体に個別のSLAはありませんが、Microsoft Entra IDの全体的なSLA（通常99.9%または99.99%）に準拠します。
DR（災害復旧）はMicrosoft Entra IDのグローバルな冗長性によって担保されています。
条件付きアクセス ポリシーの設定は、PowerShellやGraph APIを用いて定期的にエクスポートし、IaC（Infrastructure as Code）として管理することで、構成のバックアップとバージョン管理を実現できます。
4. セキュリティ
条件付きアクセスは、ゼロトラストセキュリティモデルの中核をなす要素であり、アイデンティティと権限境界を強化するために多層的なアプローチを提供します。
ゼロトラスト原則の適用: 「決して信頼せず、常に検証する」という原則に基づき、全てのアクセス要求を検証します。MFAの強制、デバイスの準拠性チェック、地理的場所の制限、リスクベースの評価を通じて、不審なアクセスを排除します。
最小特権の原則: Entra IDの組み込みロールを活用し、条件付きアクセスの管理には「条件付きアクセス管理者」または「セキュリティ管理者」ロールを付与します。これらのロールは、必要最低限の権限のみを持つべきです。
Entra ID Identity Protectionとの連携: Microsoft Entra ID Premium P2ライセンスを保有している場合、Identity Protectionが検出する「ユーザーリスク」や「サインインリスク」を条件として利用できます。例えば、「高リスクのサインイン」が検出された場合にアクセスをブロックしたり、MFAを強制したりすることが可能です。
Microsoft Defender for Cloud Apps (MDCA) との連携: MDCAと連携することで、リアルタイムセッションポリシーを適用し、クラウドアプリ内での機密データのダウンロード制限やコピー＆ペーストの禁止など、より詳細なセキュリティ制御を実現できます。
5. コスト
条件付きアクセスは、Microsoft Entra IDのライセンスモデルに依存します。
Microsoft Entra ID Premium P1:
- 基本的な条件付きアクセス ポリシー（MFA要求、デバイス準拠、場所ベースのアクセス制御など）を使用するために必要です。
Microsoft Entra ID Premium P2:
P1の機能に加え、Entra ID Identity Protectionのリスクシグナルに基づく条件付きアクセス ポリシー（ユーザーリスク、サインインリスク）を使用する場合に必要です。
PIM（Privileged Identity Management）などの高度な機能も含まれます。
Microsoft Defender for Cloud Apps (MDCA):
- MDCAのリアルタイムセッション制御を利用する場合、別途MDCAライセンス（通常、Microsoft 365 E5 Securityに含まれる）が必要です。
コスト最適化:
組織のセキュリティ要件を評価し、必要な機能に応じて適切なライセンス（P1またはP2）を選択します。すべてのユーザーにP2ライセンスが必要とは限りません。
MDCAの機能が必要ない場合は、そのライセンスコストを回避できます。
不必要なポリシーを削除し、簡素化することで管理コストを削減できます。
6. 落とし穴とベストプラクティス
条件付きアクセスは強力なツールですが、誤った設定はアクセス障害やセキュリティホールにつながる可能性があります。
緊急アクセスアカウント（ブレークグラスアカウント）の確保:
- ポリシー設定ミスなどで全ての管理者がロックアウトされる事態に備え、少なくとも2つの「緊急アクセスアカウント」を作成し、全ての条件付きアクセス ポリシーから除外してください。これらのアカウントは厳重に管理し、通常の運用には使用せず、緊急時にのみ利用します。
「レポート専用モード」での徹底的なテスト:
- 新しいポリシーを有効化する前に、必ず「レポート専用モード」で少なくとも1週間程度は運用し、影響をサインインログで確認してください。これには、様々なユーザー、デバイス、場所からのアクセスシナリオを含めるべきです。
ポリシーの評価順序の理解:
- 条件付きアクセス ポリシーに評価順序は存在せず、すべてのポリシーが同時に評価されます。ユーザーと条件に合致するすべての「ブロック」ポリシーは「許可」ポリシーよりも優先されます。複数のポリシーが競合し、「ブロック」と「許可」の両方が適用可能な場合、結果はブロックになります。
「すべてのクラウドアプリ」の慎重な使用:
- 「すべてのクラウドアプリ」を対象とするポリシーは強力ですが、Microsoft Azure管理ポータルなどの重要な管理インターフェースも含まれるため、意図しないロックアウトを防ぐために慎重に設計し、テストが必要です。特定のアプリケーションを除外することを検討してください。
デバイスの準拠状態の維持:
- デバイスの準拠状態を条件とする場合、ユーザーが常に準拠状態のデバイスを使用していることを確認する必要があります。IntuneなどのMDMツールとの連携を適切に構成し、ユーザーへの情報提供も重要です。
フェデレーション環境での注意点:
- AD FSなどのフェデレーションサービスを使用している場合、条件付きアクセスの評価はEntra ID側で行われるため、フェデレーションプロバイダーの設定と競合しないよう注意が必要です。
7. まとめ
Microsoft Entra ID条件付きアクセスは、今日の複雑なクラウド環境において、組織のセキュリティを大幅に強化するための不可欠なツールです。本ガイドで解説したアーキテクチャ、設定手順、運用監視、セキュリティの考慮事項、コスト最適化、そして実践における落とし穴を理解し、適切な計画とテストに基づいて実装することで、ゼロトラストセキュリティモデルの実現に大きく貢献できます。{{jst_today}}現在も進化を続けるEntra ID条件付きアクセスを効果的に活用し、堅牢なアイデンティティ主導型セキュリティを確立しましょう。
