Entra ID条件付きアクセスと認証強度

Tech

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

Entra ID条件付きアクセスと認証強度

Microsoft Entra ID (旧 Azure Active Directory) の条件付きアクセス (Conditional Access: CA) は、ゼロトラストセキュリティモデルを実装する上で不可欠な機能です。特に「認証強度 (Authentication Strength)」は、ユーザーがリソースにアクセスする際に、フィッシング耐性のあるMFA (多要素認証) などのより厳格な認証方法を強制し、セキュリティ態勢を大幅に強化します。この機能は、複雑化するサイバー脅威から組織の資産を保護するための重要なツールとなります。

アーキテクチャ

Entra IDの条件付きアクセスは、ユーザーがアプリケーションやサービスへのアクセスを試みる際に、リアルタイムでポリシーを評価し、アクセス制御を決定する判断ポイントとして機能します。

  1. ユーザー認証要求: ユーザーがアプリケーションにアクセスしようとすると、Entra IDに対して認証要求が送信されます。

  2. 条件付きアクセス評価: Entra IDは、設定されたすべての条件付きアクセス ポリシーに対して、ユーザー、デバイス、場所、アプリケーション、サインインリスクなどの条件を評価します。

  3. 付与制御 (Grant Controls): 条件が一致した場合、ポリシーに定義された付与制御が適用されます。これには、MFAの要求、デバイスの準拠要件、ハイブリッドAzure AD参加デバイス要件、利用規約の承諾、そして「認証強度」の要求が含まれます。

  4. 認証強度の適用: 認証強度が要求された場合、ユーザーはポリシーで指定された認証方法（例: フィッシング耐性MFA、FIDO2セキュリティキー）で再認証する必要があります。これにより、より高度な認証セキュリティが強制されます。

  5. アクセス許可またはブロック: すべての要件が満たされた場合、ユーザーはリソースへのアクセスを許可されます。満たされない場合はアクセスがブロックされます。

このプロセスは、Microsoft Learnの「Azure AD の条件付きアクセスとは」に詳細が記載されており、2024年5月14日に更新されています。また、認証強度の概念は同日付で更新された「Microsoft Entra 条件付きアクセス認証強度」で詳しく解説されています。

Mermaidによる条件付きアクセスと認証強度のフローチャートを以下に示します。

graph TD
    A["ユーザー"] --> |認証要求| B("Entra ID");
    B --> |ポリシー評価| C{"条件付きアクセス"};
    C --> |条件一致?| D{"はい"};
    C --> |条件一致?| E{"いいえ"};
    D --> |付与制御| F{"認証強度要求?"};
    F --> |はい| G["指定強度で認証"];
    F --> |いいえ| H["標準MFA等で認証"];
    E --> I["アクセス許可"];
    G --> I;
    H --> I;
    C --> |ブロック| J["アクセスブロック"];
    I --> K["リソースへのアクセス"];
    J --> K;

設定手順

ここでは、フィッシング耐性のあるMFAを要求する認証強度を適用する条件付きアクセス ポリシーを、Microsoft Graph APIとPowerShellで設定する例を示します。この機能にはEntra ID P2ライセンスが必要です（Microsoft Learn, 2024年5月28日更新）。

まず、PowerShellでGraph APIに接続します。

# Microsoft Graph PowerShell SDKのインストール (初回のみ)


# Install-Module Microsoft.Graph -Scope CurrentUser

# 必要なスコープを指定して接続

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

# 例: 組み込みの「Phishing-resistant MFA」認証強度IDを取得する


# 実際には、以下の認証強度IDは組み込みのものとして固定的に参照されます。


# カスタム強度を作成する場合は、そのIDをGraph APIで取得する必要があります。


# 組み込みの認証強度の表示 (Graph ExplorerまたはPowerShellで確認可能)


# GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/authenticationStrengths

# 通常、組み込みのフィッシング耐性MFAの認証強度IDは `d6d76166-5789-4a48-a734-6725265b7468` です。


# ただし、テナントやGraph APIのバージョンによって異なる可能性があるため、


# 最初に Graph API explorer で `GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrengths`


# を実行し、`displayName: "Phishing-resistant MFA"` の `id` を確認することが推奨されます。

$phishingResistantMfaStrengthId = "d6d76166-5789-4a48-a734-6725265b7468" # 2024年6月1日時点での一般的なID

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

$policyDisplayName = "機密情報アプリへのフィッシング耐性MFA要求"
$policyState = "enabledForSpecificUsers" # または "enabled" もしくは "reportOnly"

# 適用対象ユーザーグループのID (例: 全ユーザーの場合は "all")


# Get-MgGroup -DisplayName "特定の機密情報アクセスユーザー" | Select-Object Id

$targetUserGroupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 例: 機密情報アクセス権を持つグループID

# 適用対象アプリケーションのID (例: 特定のエンタープライズアプリ)


# Get-MgServicePrincipal -DisplayName "Salesforce" | Select-Object AppId

$targetAppId = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" # 例: SalesforceのApp ID

$policyBody = @{
    displayName = $policyDisplayName
    state = $policyState
    conditions = @{
        users = @{
            includeUsers = @("None") # 特定のグループにのみ適用
            includeGroups = @($targetUserGroupId)
            excludeUsers = @("None") # 緊急アクセスアカウントは除外推奨
        }
        applications = @{
            includeApplications = @($targetAppId)
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator = "AND"
        authenticationStrength = @{
            id = $phishingResistantMfaStrengthId # 取得した認証強度のID

            # combinedRequirements の利用も可能だが、認証強度IDが推奨

        }
    }
} | ConvertTo-Json -Depth 5

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

Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" -Body $policyBody -ContentType "application/json"

このPowerShellスクリプトは、特定のユーザーグループが特定のアプリケーションにアクセスする際に、「Phishing-resistant MFA」という認証強度を強制する条件付きアクセス ポリシーを作成します。$targetUserGroupId と $targetAppId は、環境に合わせて適切なIDに置き換える必要があります。

運用監視

条件付きアクセス ポリシーと認証強度の適切な運用には、継続的な監視が不可欠です。

  1. サインインログの分析: Entra ID 管理センター (portal.azure.com) の「監視と正常性」→「サインインログ」で、条件付きアクセスの評価結果を確認できます。どのポリシーが適用され、MFAが要求されたか、アクセスがブロックされたかなど、詳細な情報を確認できます（Microsoft Learn, 2024年4月26日更新）。

  2. レポート専用モード (Report-Only Mode): ポリシーを有効化する前に、レポート専用モードでポリシーの影響を評価することが強く推奨されます。これにより、ユーザー体験への影響や、意図しないアクセスブロックを事前に把握できます（Microsoft Learn, 2024年4月25日更新）。

  3. Log AnalyticsとKQL: サインインログや監査ログをAzure Log Analyticsワークスペースにエクスポートし、Kusto Query Language (KQL) を使用して詳細な分析やカスタムアラートを設定できます。例えば、特定の認証強度を満たせずにアクセスがブロックされたイベントを検知し、管理者への通知を自動化できます（Azure Monitor の価格, 2024年5月28日確認）。

  4. 緊急アクセスアカウントの確認: 定期的に緊急アクセスアカウントが条件付きアクセス ポリシーから除外されていることを確認し、管理者がロックアウトされる事態を防ぎます。これは最低限のDR（Disaster Recovery）対策となります。

セキュリティ

Entra ID条件付きアクセスと認証強度は、ゼロトラストセキュリティモデルの中心的な要素であり、組織のセキュリティ態勢を大幅に向上させます。

  • ゼロトラストの実現: 条件付きアクセスは「決して信頼せず、常に検証する」というゼロトラストの原則を具現化します。ユーザーがどこからアクセスしても、デバイスの状態、場所、リスクレベルなどに基づいてアクセスを検証し、許可された認証強度を強制します（Microsoft Learn, 2024年5月28日更新）。

  • リスクベース条件付きアクセス: Entra ID Protectionと連携することで、ユーザーまたはサインインのリスクレベルに基づいて条件付きアクセス ポリシーを動的に適用できます。例えば、異常なサインインが検出された場合に、より高い認証強度を要求したり、アクセスをブロックしたりできます。これはEntra ID P2の機能です（Microsoft Learn, 2024年5月14日更新）。

  • フィッシング耐性MFAの強制: 認証強度は、SMSや音声通話などのフィッシング攻撃に弱いMFA方法を排除し、FIDO2セキュリティキーやMicrosoft Authenticatorの番号一致などの、フィッシング耐性のあるMFAを強制することで、アイデンティティへの攻撃経路を大幅に減少させます。

  • Defender for Cloud Appsとの連携: Microsoft Defender for Cloud Apps (旧 MCAS) と条件付きアクセス アプリ制御を組み合わせることで、セッションレベルでのより詳細なアクセス制御（例: ファイルのダウンロード制限、コピー＆ペーストの禁止）が可能になり、データ漏洩のリスクを低減します（Microsoft Learn, 2024年5月29日更新）。

コスト

Entra ID条件付きアクセスと認証強度の利用には、以下のライセンス費用が発生します。

  • Entra ID P1: 基本的な条件付きアクセス機能はEntra ID P1ライセンスで利用可能です。これにはMFA要求やデバイス状態に基づくポリシーなどが含まれます。

  • Entra ID P2: 認証強度、リスクベース条件付きアクセス (Entra ID Protectionを含む) など、高度なセキュリティ機能を利用するには、Entra ID P2ライセンスが必要です。

  • Log Analytics: 運用監視のためにサインインログや監査ログをAzure Log Analyticsワークスペースにエクスポートする場合、取り込みデータ量とデータ保持期間に応じて課金されます。料金はリージョンやプランによって異なりますが、一般的にデータ量が増えるほどコストも増加します（Azure Monitor の価格, 2024年5月28日確認）。

最適なコスト運用のためには、P1とP2の機能差を理解し、組織のセキュリティ要件に合わせて適切なライセンスを選択することが重要です。また、Log Analyticsのデータ保持期間は必要最小限に設定し、不要なログをフィルタリングすることでコスト最適化が可能です。

落とし穴

条件付きアクセス ポリシーを導入する際には、いくつかの一般的な落とし穴に注意が必要です。

  1. 緊急アクセスアカウントの除外忘れ: すべての条件付きアクセス ポリシーから、最低2つの緊急アクセスアカウントを必ず除外してください。これらを怠ると、ポリシーの誤設定や予期せぬ障害発生時に、管理者がEntra IDにサインインできなくなり、組織全体がロックアウトされる可能性があります（Microsoft Learn, 2024年4月25日更新）。

  2. レポート専用モードなしでの即時適用: ポリシーを有効にする前に、必ずレポート専用モードでその影響を評価してください。いきなり本番環境で有効化すると、意図しないアクセスブロックやユーザーからの問い合わせが殺到する可能性があります。

  3. 適切な認証方法のユーザーへの展開不足: 認証強度ポリシーで特定の認証方法（例: FIDO2セキュリティキー）を要求する場合、ユーザーがその認証方法を登録・利用できるようになっていることを確認してください。準備ができていないユーザーはアクセスできなくなります。

  4. 過剰なポリシーによるユーザー体験の阻害: 厳格すぎるポリシーは、ユーザーの利便性を損ない、生産性の低下を招くことがあります。セキュリティと利便性のバランスを考慮し、組織のニーズに合わせた適切なポリシー設計を心がけましょう。

まとめ

Entra ID条件付きアクセスと認証強度は、現代のサイバー脅威から組織を保護するための強力なツールです。ゼロトラストの原則に基づき、ユーザーがリソースにアクセスする際のセキュリティ要件を細かく制御することで、不正アクセスやデータ侵害のリスクを大幅に軽減できます。

適切なアーキテクチャ設計、Graph APIを利用した効率的な設定、そしてサインインログやレポート専用モードを活用した継続的な運用監視を通じて、組織は強固なセキュリティ態勢を維持できます。また、Entra ID P2ライセンスの利用やLog Analyticsのコスト最適化を考慮しつつ、緊急アクセスアカウントの除外などの落とし穴を回避することで、安全かつ効率的なID管理を実現することが可能です。

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

コメント

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