Azure AD Conditional Access認証強度

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure AD Conditional Access認証強度

Azure AD Conditional Access (条件付きアクセス) の「認証強度」は、組織のセキュリティ要件に応じてユーザーに特定の認証方法を強制するための強力な機能です。この機能により、より堅牢な認証メカニズム（例えばフィッシング耐性を持つMFA）を特定のシナリオで要求できるようになります。

アーキテクチャ

認証強度は、Microsoft Entra ID (旧 Azure AD) の条件付きアクセス ポリシーにおける「付与コントロール」の一つとして機能します。これは、アクセスが許可される前に満たされなければならない特定の認証要件を定義します。

認証強度の役割: 認証強度は、ユーザーがサインインする際に求められる認証方法のコレクションを指します[1]。例えば、「多要素認証 (MFA)」という認証強度は、ユーザーが登録済みのMFA手段（Microsoft Authenticator、SMS、音声通話など）のいずれかを使用して認証することを要求します。より高度な認証強度として、「フィッシング耐性 MFA」は、FIDO2セキュリティキーやWindows Hello for Businessなどの、フィッシング攻撃に対して高い耐性を持つ認証方法のみを許可します。

カスタム認証強度: 組織は、定義済みの認証強度に加えて、特定の認証方法の組み合わせをカスタム認証強度として定義できます[2]。これにより、例えば「Windows Hello for Business または FIDO2 セキュリティキー」のような、組織固有の要件に合わせた認証ポリシーを柔軟に設定することが可能になります。

以下に、条件付きアクセスにおける認証強度の適用フローを示します。

flowchart TD
    A["ユーザー"] --> |認証要求| B("アプリケーション")
    B --> |認証プロトコル (SAML/OAuth)| C["Microsoft Entra ID"]
    C --> |ユーザー認証| D{"条件付きアクセス ポリシー評価"}
    D -- |ポリシーにマッチ| --> E["付与コントロール"]
    E --> |認証強度 (カスタム/定義済み) 適用| F{"認証強度チェック"}
    F -- |認証要件を満たす| --> G["アクセス許可"]
    F -- |認証要件を満たさない| --> H["認証方法の追加要求"]
    H --> |ユーザーによる認証完了| G
    G --> |アプリケーションへのアクセス| B

図1: 条件付きアクセスにおける認証強度の適用フロー

このフローでは、ユーザーがアプリケーションへのアクセスを要求すると、Microsoft Entra IDが認証を仲介します。条件付きアクセス ポリシーが評価され、ポリシーに合致した場合、そのポリシーで指定された「認証強度」が付与コントロールとして適用されます。ユーザーがその認証強度を満たしていればアクセスが許可され、満たしていなければ追加の認証方法が要求されます。

設定手順

ここでは、Graph API (PowerShell) を使用してカスタム認証強度を作成し、それを条件付きアクセス ポリシーに適用する手順を説明します。

前提条件:

  • Microsoft Entra ID P2 ライセンス[5]

  • Graph PowerShell SDK (Microsoft.Graph.Beta モジュール) のインストール

  • 適切な権限（Conditional Access Administrator または Global Administrator）

1. カスタム認証強度の作成 特定の認証方法（例: FIDO2 セキュリティキー）のみを許可するカスタム認証強度を作成します。

# Graph PowerShell SDKのインストール（未インストールの場合）


# Install-Module -Name Microsoft.Graph.Beta -Scope CurrentUser

# Graphに接続（ConditionalAccess.ReadWrite.All 権限が必要）

Connect-MgGraph -Scopes "ConditionalAccess.ReadWrite.All"

# カスタム認証強度の定義（FIDO2セキュリティキーのみを許可）

$displayName = "Phishing-Resistant FIDO2 Only"
$description = "Requires FIDO2 security keys for phishing resistance."
$allowedCombinations = @("fido2") # 利用可能な値: fido2, x509CertificateSingleFactor, windowsHelloForBusiness, passwordlessMicrosoftAuthenticator, microsoftAuthenticatorPush, sms, voice, oathSoftwareToken, email, temporaryAccessPass

$customAuthStrengthBody = @{
    displayName = $displayName
    description = $description
    allowedCombinations = $allowedCombinations
    combinationConfigurations = @() # 必要に応じて認証方法固有の設定を追加
} | ConvertTo-Json

# カスタム認証強度ポリシーの作成

try {
    $newAuthStrength = Invoke-MgGraphRequest -Method POST -Uri "/beta/identity/conditionalAccess/authenticationStrengthPolicies" -Body $customAuthStrengthBody -ContentType "application/json"
    Write-Host "カスタム認証強度 '$displayName' が作成されました。ID: $($newAuthStrength.id)"
}
catch {
    Write-Error "カスタム認証強度の作成に失敗しました: $($_.Exception.Message)"
}

# 作成された認証強度のIDをメモ（後でCAポリシーで参照）

$customAuthStrengthId = $newAuthStrength.id

コメント:

  • 入力: $displayName (認証強度名)、$description (説明)、$allowedCombinations (許可する認証方法のリスト)。

  • 出力: 新しく作成されたカスタム認証強度のID。

  • 前提: Graph PowerShell SDKのMicrosoft.Graph.Betaモジュールがインストールされ、適切な権限でGraphに接続済みであること。

  • 注意: allowedCombinations は、Microsoft Entra ID の公式ドキュメントで利用可能な値を確認してください。

2. 条件付きアクセス ポリシーの作成 作成したカスタム認証強度を要求する条件付きアクセス ポリシーを作成します。

# 条件付きアクセス ポリシーの定義

$policyName = "Require Phishing-Resistant FIDO2 MFA for All Users"
$policyState = "enabled" # enabledForReportingOnly, enabled, disabled

$users = @{
    includeUsers = @("All") # 特定のユーザー/グループを指定することも可能
}

$applications = @{
    includeApplications = @("All") # 特定のアプリケーションを指定
}

$conditions = @{
    clientAppTypes = @("browser","mobileAppsAndDesktopClients")

    # 例: 場所の条件を追加する場合


    # locations = @{


    #     includeLocations = @("All")


    #     excludeLocations = @("AllTrustedLocations") # 信頼済みIPからのアクセスを除く


    # }

}

$grantControls = @{
    operator = "OR" # 複数のコントロールがある場合、ANDまたはOR
    builtInControls = @() # 組み込みコントロール（MFAなど）
    authenticationStrength = @{ # ここでカスタム認証強度を指定
        id = $customAuthStrengthId
    }
}

$caPolicyBody = @{
    displayName = $policyName
    state = $policyState
    conditions = $conditions
    grantControls = $grantControls
    sessionControls = $null # 必要に応じてセッションコントロールを追加
    users = $users
    applications = $applications
} | ConvertTo-Json

# 条件付きアクセス ポリシーの作成

try {
    Invoke-MgGraphRequest -Method POST -Uri "/beta/identity/conditionalAccess/policies" -Body $caPolicyBody -ContentType "application/json"
    Write-Host "条件付きアクセス ポリシー '$policyName' が作成されました。"
}
catch {
    Write-Error "条件付きアクセス ポリシーの作成に失敗しました: $($_.Exception.Message)"
}

コメント:

  • 入力: $policyName (ポリシー名)、$policyState (ポリシーの状態)、$users (対象ユーザー)、$applications (対象アプリケーション)、$conditions (条件)、$grantControls (付与コントロール)。

  • 出力: なし（ポリシー作成成功メッセージ）。

  • 前提: カスタム認証強度が事前に作成され、そのID ($customAuthStrengthId) が利用可能であること。

  • 注意: 新しいポリシーはまずenabledForReportingOnly (レポートのみ) で作成し、影響を評価した後にenabledに変更することを強く推奨します。

運用監視

条件付きアクセス ポリシー、特に認証強度を含むポリシーの導入後、その効果と影響を継続的に監視することが重要です。

サインインログの確認: Microsoft Entra ID のサインインログは、条件付きアクセス ポリシーの評価結果を詳細に確認できる主要なツールです[4]。

  • Azure Portal: Microsoft Entra ID > 監視 > サインインログ

  • 各サインインイベントの「条件付きアクセス」タブで、適用されたポリシーと、そのポリシーの結果（成功/失敗）を確認できます。認証強度が要求され、ユーザーがそれを満たしたかどうかもここで確認可能です。

「レポートのみ」モードの活用: 新しいポリシーを有効にする前に、必ず「レポートのみ」モード (enabledForReportingOnly) で展開し、その影響を評価します。これにより、ユーザーのアクセスがブロックされることなく、ポリシーが適用された場合にどのような結果になるかをシミュレーションできます。サインインログから「レポートのみ」の結果をフィルタリングして確認することで、潜在的な問題やユーザー体験への影響を特定できます。

可観測性: Microsoft Entra ID は、アクティビティログ（監査ログ、サインインログ、プロビジョニングログ）を通じて詳細な監視機能を提供します[4]。これらのログをAzure Monitor (Log Analyticsワークスペース) にエクスポートすることで、カスタムダッシュボードの作成、アラートの設定、長期的な分析が可能になります。

SLA: Microsoft Entra ID は、月間稼働率 99.9% のサービスレベル契約 (SLA) を提供しており[4]、可用性に関する高い信頼性を持っています。

バックアップ/DR: Microsoft Entra ID 自体はMicrosoftによって運用され、高可用性と災害復旧が組み込まれたサービスであるため、ユーザーが明示的なバックアップ/DR計画を立てる必要は通常ありません。しかし、条件付きアクセス ポリシーやカスタム認証強度の構成は、Graph APIなどを利用してJSON形式などでエクスポートしておくことで、誤って変更された場合の復元や、別テナントへのデプロイに役立ちます。

セキュリティ

認証強度は、アイデンティティとアクセス管理におけるセキュリティ境界を強化する上で極めて重要な役割を果たします。

アイデンティティと権限境界:

  • Microsoft Entra ID: 組織の主要なアイデンティティプロバイダーとして機能し、ユーザー、グループ、アプリケーションのアイデンティティを管理します。

  • 条件付きアクセス (CA): Microsoft Entra ID の機能として、リアルタイムのシグナル（ユーザー、デバイス、場所、アプリケーション、リスクなど）に基づいて、リソースへのアクセス制御の境界を動的に定義します。認証強度は、この境界内で「どのように認証するか」を具体的に指定します。

  • ロール: Microsoft Entra ID の組み込みロール（例: グローバル管理者、条件付きアクセス管理者）やカスタムロールは、管理タスクを実行するための権限境界を定義します。これらのロールを持つユーザーは、認証強度ポリシーの作成・変更が可能です。

  • Defender for Identity/Cloud Apps: Microsoft Defender for Identity や Microsoft Defender for Cloud Apps は、異常な行動やリスクイベントを検出し、そのシグナルを条件付きアクセスにフィードバックします。これにより、リスクベースの条件付きアクセス ポリシーを適用し、特定の認証強度を要求するといった、より高度なセキュリティを実現できます。

具体的なセキュリティ強化:

  • フィッシング耐性MFAの強制: フィッシング耐性のある認証強度（例: FIDO2、Windows Hello for Business）を強制することで、パスワードや従来のMFA（SMS、音声通話）が持つフィッシング攻撃への脆弱性を劇的に低減できます。これにより、最も強力な認証方法で企業の機密データやリソースを保護できます[1]。

  • 最小特権の原則: 特権アクセスワークステーション (PAW) や管理者アカウントに対して、より厳格な認証強度を要求することで、攻撃者がこれらの高価値ターゲットにアクセスする際のハードルを大幅に上げることができます。

  • コンプライアンス要件の達成: 特定の業界規制やコンプライアンス基準（例: NIST SP 800-63B）では、特定の認証保証レベル (AAL) が求められる場合があります。カスタム認証強度を活用することで、これらの要件を満たすことが容易になります。

コスト

認証強度の利用には、Microsoft Entra ID のライセンス費用が主なコストとして発生します。

Microsoft Entra ID P1/P2 ライセンス:

  • Microsoft Entra ID P1: 条件付きアクセス ポリシーの基本的な機能（定義済み認証強度を含む多要素認証の強制など）を利用できます。

  • Microsoft Entra ID P2: カスタム認証強度の作成と利用には、Microsoft Entra ID P2 ライセンスが必要です[5]。P2ライセンスは、Identity Protection（リスクベースの条件付きアクセス）などの高度なセキュリティ機能も含まれます。

コスト最適化:

  • ライセンスの選択: カスタム認証強度が本当に必要かどうかを評価し、不必要なP2ライセンスの購入を避けます。P1で要件が満たせる場合はP1を選択します。

  • ユーザー数に応じた課金: Microsoft Entra ID のライセンスは、通常、ユーザー数に基づいて月額または年額で課金されます。組織内のすべてのユーザーにP2ライセンスが必要か、あるいは特定の管理者や高リスクユーザーのみに適用するかを検討し、適切な数のライセンスを割り当てます。

  • Azure のリソース: 条件付きアクセスや認証強度自体に直接、リザーブドインスタンスやスケジューリングの概念は適用されません。しかし、Microsoft Entra ID のログをAzure Monitor (Log Analytics) に取り込む場合、Log Analyticsのデータ保持期間や取り込み量に応じてコストが発生するため、適切なログポリシーを設定することでコストを最適化できます。

落とし穴

認証強度の導入は強力なセキュリティ強化をもたらしますが、誤った設定は運用上の大きな問題を引き起こす可能性があります。

  1. 過度な制限によるユーザーロックアウト:

    • 説明: 厳しすぎる認証強度を広範囲に適用すると、対応する認証方法を登録していないユーザーや、技術的に利用できないユーザーがアプリケーションにアクセスできなくなる可能性があります。

    • 対策: まずは「レポートのみ」モードで影響を評価し、段階的に展開する。特定の認証強度を要求する前に、対象ユーザーに適切な認証方法を登録するよう促すプロセスを確立する。非常時に備え、除外ユーザーまたは除外グループを設定し、ブレークグラスアカウントがアクセス可能であることを確認する。

  2. テスト不足:

    • 説明: 新しい認証強度ポリシーを十分にテストしないまま本番環境に適用すると、予期せぬアクセス問題が発生する可能性があります。

    • 対策: テストユーザーまたはテストグループを作成し、さまざまなデバイス、場所、アプリケーションでポリシーの動作を検証する。可能な限り多様なシナリオをカバーするテスト計画を策定する。

  3. ライセンス要件の見落とし:

    • 説明: カスタム認証強度はMicrosoft Entra ID P2 ライセンスの機能であるため、P1以下のライセンスで作成しようとすると失敗するか、意図せずポリシーが機能しない場合があります。

    • 対策: 導入前にライセンス要件を明確に確認し、必要な数のP2ライセンスを確保する。

  4. カスタム認証強度の複雑化:

    • 説明: 多数のカスタム認証強度ポリシーを作成しすぎると、管理が複雑になり、どのポリシーがどの認証方法を要求しているのかが分かりにくくなる可能性があります。

    • 対策: カスタム認証強度は必要最小限に留め、明確な命名規則と説明を付与する。定期的にポリシーを見直し、不要なものを削除または統合する。

まとめ

Azure AD Conditional Accessの認証強度は、Microsoft Entra ID を利用する組織にとって、認証セキュリティを次のレベルへと引き上げるための不可欠なツールです。フィッシング耐性のあるMFAの強制から、組織固有のコンプライアンス要件を満たすための柔軟な認証方法の組み合わせまで、幅広いセキュリティニーズに対応できます。

本記事で解説したアーキテクチャ、設定手順、運用監視、セキュリティの考慮事項、そしてコストと落とし穴を理解することで、クラウドアーキテクトは認証強度を効果的に設計・導入し、ユーザーの生産性を損なうことなく、より強固なセキュリティ体制を確立できるでしょう。導入に際しては、段階的なアプローチと十分なテストが成功の鍵となります。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました