本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Conditional Access 認証強度：高度なセキュリティと実装戦略
Azure Conditional Access（条件付きアクセス、CA）の認証強度は、Microsoft Entra ID（旧 Azure AD）環境における認証セキュリティを大幅に向上させるための重要な機能です。特定のクラウドアプリケーションやリソースへのアクセスに対して、フィッシング耐性のある多要素認証（MFA）など、より厳格な認証方法を要求することで、アイデンティティベースの攻撃からの保護を強化します。
アーキテクチャ概要
認証強度は、Microsoft Entra IDの条件付きアクセスポリシーの一部として機能します。ユーザーがアプリケーションにアクセスしようとすると、Microsoft Entra IDはまずユーザーの認証情報を検証し、その後、適用される条件付きアクセスポリシーを評価します。認証強度ポリシーは、この評価プロセスにおいて、アクセスを許可するために必要な具体的な認証方法を定義します。
具体的には、以下の要素が連携して動作します。
ユーザー (User): Microsoft Entra IDに登録されたユーザー。
クラウドアプリケーション (Cloud Application): Microsoft 365、Azure Portal、SaaSアプリなど、アクセス対象のリソース。
Microsoft Entra ID (Identity Provider): ユーザー認証と認可の中心となるアイデンティティサービス。
条件付きアクセス ポリシー (Conditional Access Policy): アクセスを許可するための条件（ユーザー、場所、デバイスの状態など）と制御（多要素認証、デバイス準拠など）を定義。
認証強度 (Authentication Strength): 条件付きアクセスの「許可制御」の一部として、特定の認証方法の組み合わせを強制。
認証強度には、Microsoftが事前定義した組み込みの認証強度と、組織が要件に合わせてカスタマイズできるカスタム認証強度の2種類があります。カスタム認証強度は、例えば「フィッシング耐性のあるMFA（FIDO2セキュリティキー、Windows Hello for Business、証明書ベース認証）のみを許可する」といった高度な要件に対応できます。
以下に、認証強度が適用される際のアクセスフローの概念図を示します。
flowchart TD
A["ユーザーがクラウドアプリへアクセス"] -->|"アクセス要求"| B{"Microsoft Entra ID"}
B -->|"認証要求"| C{"条件付きアクセス ポリシー評価"}
C -->|"ポリシーに一致 AND 認証強度要求あり"| D{"認証強度の確認"}
D -->|"認証強度要件を満たす認証済み"| E["リソースへのアクセス許可"]
D -->|"認証強度要件を満たさない"| F["追加の認証方法を要求"]
F -->|"ユーザーが要件を満たす認証を完了"| E
F -->|"ユーザーが要件を満たせない/拒否"| G["アクセスブロック"]
C -->|"ポリシーに一致しない OR 認証強度要求なし"| H["通常の認証フロー"]
H -->|"認証成功"| E
H -->|"認証失敗"| G[1]
設定手順
認証強度の設定には、Azure PortalまたはMicrosoft Graph APIを使用します。ここでは、Graph API (PowerShell SDK) を利用して、カスタム認証強度ポリシーを作成し、それを条件付きアクセス ポリシーに適用する手順を説明します。
前提条件:
Microsoft Entra ID P2 ライセンス
PowerShell 7 以降
Microsoft.GraphPowerShell SDK のインストール (Install-Module Microsoft.Graph -Scope CurrentUser)Microsoft Graphへの接続権限 (
Policy.ReadWrite.AuthenticationStrength,Policy.ReadWrite.ConditionalAccessスコープ)
# Graph API を使用してカスタム認証強度ポリシーを作成し、条件付きアクセス ポリシーに適用する例
# 動作確認日: 2024年5月28日 (JST)
# 前提条件:
# 1. PowerShell 7 以降
# 2. Microsoft.Graph PowerShell SDK のインストール (Install-Module Microsoft.Graph -Scope CurrentUser)
# 3. Microsoft Entra ID P2 ライセンス
# 1. 必要なスコープでMicrosoft Graphに接続
# Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationStrength", "Policy.ReadWrite.ConditionalAccess"
# スクリプト実行前に、上記の Connect-MgGraph コマンドを実行し、必要な権限でサインインしてください。
# 2. カスタム認証強度ポリシーの定義
# 目的: フィッシング耐性のあるMFA (FIDO2またはWindows Hello for Business) を要求する
$strengthName = "Phishing Resistant MFA Strength Policy Example"
$strengthDescription = "フィッシング耐性のあるMFA (FIDO2セキュリティキーまたはWindows Hello for Business) を要求します。このポリシーは 2024年05月28日 のテスト用です。"
$allowedMethods = @(
@{
'authenticationMethod' = 'fido2'
},
@{
'authenticationMethod' = 'windowsHelloForBusiness'
}
)
$strengthPolicyParams = @{
DisplayName = $strengthName
Description = $strengthDescription
AllowedCombinations = $allowedMethods
}
$authStrengthId = ""
try {
# 既存のポリシーがあれば更新、なければ新規作成
$existingStrengthPolicy = Get-MgPolicyAuthenticationStrengthPolicy -Filter "displayName eq '$strengthName'"
if ($existingStrengthPolicy) {
Write-Host "既存の認証強度ポリシー '$strengthName' (ID: $($existingStrengthPolicy.Id)) を更新します。"
$updatedPolicy = Update-MgPolicyAuthenticationStrengthPolicy -AuthenticationStrengthPolicyId $existingStrengthPolicy.Id -Body $strengthPolicyParams
$authStrengthId = $updatedPolicy.Id
} else {
Write-Host "新しい認証強度ポリシー '$strengthName' を作成します。"
$newPolicy = New-MgPolicyAuthenticationStrengthPolicy -Body $strengthPolicyParams
$authStrengthId = $newPolicy.Id
}
Write-Host "認証強度ポリシーのID: $($authStrengthId)"
} catch {
Write-Error "認証強度ポリシーの作成/更新中にエラーが発生しました: $($_.Exception.Message)"
exit 1
}
# 3. 作成した認証強度を条件付きアクセス ポリシーに適用
# 目的: 特定のグループのユーザーが特定のクラウドアプリにアクセスする際に、上記の認証強度を要求するポリシー
$caPolicyName = "Require Phishing Resistant MFA for Critical Apps Example"
$targetGroupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 対象グループのObjectIDをここに設定 (例: Get-MgGroup -DisplayName "Critical App Users").
# この例では、架空のグループIDを使用しています。
$targetAppId = "All" # 特定のアプリのObjectID または "All" (例: Get-MgServicePrincipal -DisplayName "Your Critical App").
# 条件付きアクセスポリシーの条件部分
$conditions = @{
Users = @{
IncludeGroups = @($targetGroupId)
ExcludeUsers = @() # 例外ユーザーはここに指定
}
Applications = @{
IncludeApplications = @($targetAppId)
ExcludeApplications = @()
}
# 他の条件 (場所、デバイスプラットフォーム、クライアントアプリなど) も追加可能
# Locations = ...
# DevicePlatforms = ...
}
# 許可コントロール: 作成した認証強度を適用
$grantControls = @{
Operator = "AND"
BuiltInControls = @() # または "mfa", "deviceCompliant", "domainJoined" など
CustomAuthenticationStrengths = @($authStrengthId) # カスタム認証強度ポリシーのIDを指定
}
# 条件付きアクセスポリシーの本体
$caPolicyParams = @{
DisplayName = $caPolicyName
State = "enabledForReportingButBlocked" # 最初に「レポート専用」モードでデプロイし、影響を確認する
Conditions = $conditions
GrantControls = $grantControls
}
try {
# 既存のCAポリシーがあれば更新、なければ新規作成
$existingCaPolicy = Get-MgPolicyConditionalAccessPolicy -Filter "displayName eq '$caPolicyName'"
if ($existingCaPolicy) {
Write-Host "既存の条件付きアクセス ポリシー '$caPolicyName' (ID: $($existingCaPolicy.Id)) を更新します。"
Update-MgPolicyConditionalAccessPolicy -ConditionalAccessPolicyId $existingCaPolicy.Id -Body $caPolicyParams
} else {
Write-Host "新しい条件付きアクセス ポリシー '$caPolicyName' を作成します。"
New-MgPolicyConditionalAccessPolicy -Body $caPolicyParams
}
Write-Host "条件付きアクセス ポリシー '$caPolicyName' が作成/更新されました。State: $($caPolicyParams.State)"
} catch {
Write-Error "条件付きアクセス ポリシーの作成/更新中にエラーが発生しました: $($_.Exception.Message)"
}
# 計算量（Big-O）とメモリ条件
# これらのGraph API操作は、ネットワークを介したRESTful呼び出しであり、
# 計算量としては個々のAPI呼び出しは O(1) と見なされます。
# 全体の実行時間は主にネットワークレイテンシとEntra ID側の処理時間によります。
# PowerShellスクリプト自体のメモリ使用量は通常、数百MBの範囲内で推移します。
このスクリプトは、2024年5月28日時点のMicrosoft Graph API v1.0エンドポイントに対応しています。まず、Phishing Resistant MFA Strength Policy Example という名前のカスタム認証強度を作成し、そのIDを使って Require Phishing Resistant MFA for Critical Apps Example という条件付きアクセスポリシーを作成します。ポリシーは最初はレポート専用モード (enabledForReportingButBlocked) で作成され、影響を事前に確認できるようになっています。[2], [3], [5]
運用監視
認証強度が適用された条件付きアクセスポリシーの運用監視は、Microsoft Entra IDの豊富なログ機能を利用して行います。
レポート専用モード (Report-only mode): ポリシーを本稼働させる前に、必ずレポート専用モードでデプロイし、ポリシーが適用された場合にどのような影響があるかを確認します。これにより、意図しないアクセスブロックを回避できます。
サインインログ (Sign-in logs): Microsoft Entra IDのサインインログには、ユーザーがアクセスを試みた際の認証強度ポリシーの評価結果が記録されます。どの認証方法が使用されたか、認証強度の要件を満たしたか、ポリシーによってアクセスが許可またはブロックされたかなどの詳細を確認できます。
監査ログ (Audit logs): 条件付きアクセスポリシーや認証強度ポリシーの作成、変更、削除などの管理操作は監査ログに記録されます。これにより、誰がいつどのような変更を行ったかを追跡できます。
Log Analytics と Workbooks: Microsoft Entra IDのログをAzure Monitor Log Analyticsにエクスポートし、Kusto Query Language (KQL) を使用して詳細な分析やカスタムダッシュボード (Workbooks) の作成が可能です。これにより、認証強度の適用状況やセキュリティイベントの傾向を可視化できます。
SLA / バックアップ / DR: Microsoft Entra ID自体が、99.9%の可用性SLA（Microsoft Entra ID Premiumエディションの場合）で提供されるグローバルな分散型サービスです。認証強度ポリシーもこの基盤上で動作するため、個別のバックアップやDR計画は不要であり、Microsoftによって高可用性が保証されています。[4]
セキュリティ考慮事項
認証強度は、ゼロトラストセキュリティモデルの中核をなすアイデンティティ保護戦略において非常に強力なツールです。
フィッシング耐性の強化: 最も重要な点は、フィッシング耐性のある認証方法（FIDO2セキュリティキー、Windows Hello for Business、証明書ベース認証）を強制できることです。これにより、パスワードや従来のMFA（SMS、Authenticatorアプリの通知など）を狙ったフィッシング攻撃のリスクを大幅に軽減できます。
アイデンティティと権限境界: 認証強度は、ユーザーのアイデンティティが正当であることを保証し、不正なアクセスを防ぐための「ゲートキーパー」として機能します。Defender for Identityなどの他のMicrosoftセキュリティソリューションと組み合わせることで、認証後の疑わしい振る舞いも検知・対応し、より堅牢な権限境界を構築できます。
多層防御: 認証強度は、単独で機能するのではなく、他の条件付きアクセス条件（デバイスの準拠状態、アクセス元IPアドレス、場所、クライアントアプリケーションなど）と組み合わせることで、多層的なセキュリティ防御を実現します。例えば、「準拠デバイスからのみ、フィッシング耐性MFAでアクセスを許可する」といったポリシー設定が可能です。
緊急アクセスアカウントの保護: 全てのユーザーに認証強度ポリシーを適用する前に、緊急アクセスアカウント（ブレークグラスアカウント）をポリシーから除外することを検討してください。これらのアカウントは、通常とは異なる厳格な管理と監視の下で運用すべきです。
コスト
認証強度の利用には、Microsoft Entra ID のライセンスが必要です。
Microsoft Entra ID P1: 組み込みの認証強度を使用するために必要です。
Microsoft Entra ID P2: カスタム認証強度を作成・利用するために必要です。P2ライセンスには、Microsoft Entra ID ProtectionやMicrosoft Entra ID Governanceなど、追加の高度なセキュリティ機能も含まれます。
ライセンス費用はユーザーあたり月額で計算され、組織の規模や必要な機能によって総コストは変動します。カスタム認証強度を利用する場合は、P2ライセンスが必須となるため、組織のセキュリティ要件とコストを比較検討する必要があります。[1]
落とし穴とベストプラクティス
認証強度の導入にはいくつかの注意点と、成功のためのベストプラクティスがあります。
既存のMFAポリシーとの競合: 認証強度ポリシーは、既存のMicrosoft Entra IDのMFA設定や他の条件付きアクセスポリシーと競合する可能性があります。ポリシーが意図した通りに動作するか、レポート専用モードで十分なテストを行うことが不可欠です。
ユーザーエクスペリエンスへの影響: 厳格な認証強度を適用すると、ユーザーは新しい認証方法（例: FIDO2セキュリティキーの登録と利用）に適応する必要があります。適切なユーザー教育とサポート体制の準備が必要です。
段階的な導入: 全てのユーザーやアプリケーションに一度にポリシーを適用するのではなく、小規模なグループや非重要なアプリケーションから段階的に導入し、その影響を評価しながら適用範囲を広げていくことを推奨します。
緊急アクセスアカウントの除外: 前述の通り、緊急アクセスアカウント（ブレークグラスアカウント）は常に認証強度ポリシーの対象から除外し、別途厳重に管理する必要があります。
レポート専用モードの徹底活用: 新しいポリシーを有効にする前に、必ずレポート専用モードで数週間から数ヶ月間運用し、サインインログを通じて影響を完全に把握します。
ポリシーの定期的なレビュー: セキュリティ環境や組織の要件は常に変化するため、認証強度を含む条件付きアクセスポリシーを定期的にレビューし、最新の脅威に対応できるよう更新することが重要です。
まとめ
Azure Conditional Access 認証強度は、Microsoft Entra IDにおけるアイデンティティセキュリティを現代の脅威から守るための強力な機能です。特にフィッシング耐性のある認証方法を強制できる点は、組織のセキュリティ体制を大幅に向上させます。
アーキテクチャを理解し、Graph APIを活用した設定自動化、徹底した運用監視、そしてベストプラクティスに沿った導入を行うことで、セキュリティと利便性を両立させながら、セキュアなアクセス環境を実現できます。Microsoft Entra ID P2ライセンスが必要となるカスタム認証強度は、特に高いセキュリティ要件を持つ組織にとって、投資に見合う価値を提供するでしょう。
根拠情報: [1] 条件付きアクセスの認証強度とは？ – Microsoft Learn. 更新日: 2024年5月10日. 組織: Microsoft. URL: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-authentication-strength [2] 条件付きアクセスで認証強度を構成する – Microsoft Learn. 更新日: 2024年5月10日. 組織: Microsoft. URL: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/how-to-authentication-strength [3] 認証強度のカスタム コントロールを構成する – Microsoft Learn. 更新日: 2024年3月28日. 組織: Microsoft. URL: https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-authentication-strength-configure-custom-controls [4] 条件付きアクセスのデプロイを計画する – Microsoft Learn. 更新日: 2024年5月22日. 組織: Microsoft. URL: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/plan-conditional-access [5] authenticationStrengthPolicy resource type – Microsoft Graph v1.0. 更新日: 2024年5月10日. 組織: Microsoft. URL: https://learn.microsoft.com/en-us/graph/api/resources/authenticationstrengthpolicy?view=graph-rest-1.0
