本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Microsoft Entra ID 条件付きアクセス認証強度を活用したゼロトラストアーキテクチャ
クラウドアーキテクトにとって、アイデンティティ保護はゼロトラスト戦略の基礎です。Microsoft Entra IDの条件付きアクセス（CA）認証強度（Authentication Strength）は、特定の認証方法の利用を強制することで、従来の多要素認証（MFA）が抱えるフィッシング耐性の課題を解決し、アクセス境界を強化します[1]。
アーキテクチャ設計：認証強度に基づくアクセス制御フロー
認証強度は、CAポリシーの一部として、ユーザーがアクセスを許可される前に使用する必要がある認証方法のセットを指定するコントロールです[1]。特に「フィッシング耐性のある多要素認証」は、FIDO2セキュリティキーやWindows Hello for Businessなどのフィッシング耐性を持つクレデンシャルを要求し、セッションハイジャックのリスクを低減させます[3]。
CAポリシーにおける認証強度の評価は、サインイン要求時にリアルタイムで行われます[2]。
認証強度評価フロー (Mermaid)
flowchart TD
A["ユーザー"] -->|"サインイン要求"| B{"Entra ID"}
B -->|"セッション評価"| C["条件付きアクセス (CA) ポリシー"]
C -->|"ポリシー適用?"| D{"認証強度要求"}
D -->|"はい"| E["要求された認証方法の検証"]
E -->|"フィッシング耐性MFA? (例: FIDO2)"| F{"アクセス可否"}
E -->|"従来のMFA? (例: TOTP/SMS)"| G{"アクセス可否"}
D -->|"いいえ"| H["通常の認証フロー"]
F -->|"検証成功"| I("アクセス許可")
G -->|"検証成功"| I
F -->|"検証失敗/強度不足"| J("アクセス拒否: 強度不足")
G -->|"検証失敗"| J
H --> I;
subgraph mermaid_group_13["CA評価フェーズ"]
C; D; E; F; G; H;
end
style D fill:#f9f,stroke:#333,stroke-width:2px;
style E fill:#ccf,stroke:#333,stroke-width:2px;設定手順：Graph APIを用いたカスタム強度の定義
認証強度はGraph API (/beta/identity/conditionalAccess/authenticationStrength) を介してカスタム定義を作成・管理できます[4]。ここでは、PowerShellからGraph APIを利用し、「FIDO2およびWindows Hello for Businessのみ」を許可するポリシーを作成します。
この機能の利用には、ユーザーにMicrosoft Entra ID P1ライセンスが必要です[2]。
# 前提: Entra ID P1 ライセンス、適切な Graph API スコープ（Policy.ReadWrite.ConditionalAccess）
# Microsoft.Graph モジュールがインストールされていること
# 1. カスタム認証強度ポリシー定義
# 許可する認証方法ID: fido2, windowsHelloForBusiness
$policyDisplayName = "Strict_PhishingResistant_Policy"
$description = "FIDO2 または Windows Hello for Business のみ許可"
$authenticationMethods = @(
@{ id = "fido2" },
@{ id = "windowsHelloForBusiness" }
)
$policyBody = @{
displayName = $policyDisplayName
description = $description
allowedCombinations = $authenticationMethods
} | ConvertTo-Json
# 2. Graph API (Beta) を利用してポリシーを POST
# Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess" が実行済みであることを前提
$uri = "https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies"
Invoke-MgGraphRequest -Uri $uri -Method POST -Body $policyBody -ContentType "application/json"
Write-Host "カスタム認証強度 '$policyDisplayName' が作成されました。"
# 3. CAポリシーでこのカスタム強度を Grant Controls として指定し、適用を開始する。
運用監視：レポート専用モードとログ活用
CAポリシーは広範な影響を持つため、デプロイには慎重な計画が必要です。
レポート専用モード: ポリシーを導入する際は、適用前に「レポート専用モード」で作成し、その影響をテストします[5]。ポリシーが実際に適用された場合のアクセス結果をサインインログで確認し、意図しないブロックがないかを検証します。
サインインログ: Entra IDのサインインログには、CAポリシー適用状況の詳細（CAポリシー名、適用された認証強度の種類）が具体的に記録されます[5]。これにより、ユーザーのアクセス拒否が認証強度不足によるものか、別の条件によるものかを迅速に切り分けられます。
可観測性: ログデータをAzure MonitorやSentinelに転送し、特定のリソースに対する認証強度不足による拒否イベント（エラーコードなど）を即座にアラートする監視体制を構築します。
セキュリティ：アイデンティティと権限境界
認証強度は、アイデンティティと権限境界の最も外側のレイヤーを形成します。
| アイデンティティ境界 | 役割 | 具体的な境界制御 |
|---|---|---|
| 条件付きアクセス (CA) | アクセス制御の決定ポイント。 | 認証強度、場所、デバイスの状態、リスクスコアを評価。 |
| 認証強度 | 認証の信頼度強制。 | パスワードレス（FIDO2）など、フィッシング耐性を持つ認証方法のみを強制する[3]。 |
| ロールの割り当て | 権限境界。 | PIM (Privileged Identity Management) と連携し、高強度認証時のみ特権ロールを昇格させる。 |
コスト最適化
認証強度機能は、Microsoft Entra ID P1（またはそれを含むE3/M365 Business Premium）ライセンスに含まれます[6]。
ライセンス: 認証強度ポリシーの適用自体に別途の従量課金はありませんが、適用対象の全ユーザーがP1ライセンスを持っている必要があります。
ハードウェア: フィッシング耐性を最高レベルで実現するためにFIDO2セキュリティキーを導入する場合、物理的なキーの購入コスト（通常、数千円/ユーザー）が発生します。管理者や高リスクなユーザーへの限定的な導入から開始し、コスト対効果を最大化します。
運用上の落とし穴
緊急アクセスアカウントの除外: すべてのCAポリシー（認証強度ポリシーを含む）から、必ずクラウド専用の緊急アクセスアカウントを除外し、ポリシー設定ミスによるテナントロックアウトのリスクを回避します。
既存認証の依存: 認証強度を「フィッシング耐性」に設定した場合、Microsoft Authenticatorアプリのプッシュ通知や従来のTOTP/SMS MFAではアクセスできなくなります。導入前にユーザーがFIDO2などの新しい方法を登録済みであることを確認する必要があります。
レガシー認証: 認証強度を適用しても、レガシー認証（POP/IMAPなど）をブロックするCAポリシーが存在しない場合、認証強度を回避される可能性があります。必ず「その他のクライアント」をブロックするポリシーと併用します。
