Entra ID条件付きアクセス: デバイスコンプライアンスとMFA

Tech

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

Entra ID条件付きアクセス: デバイスコンプライアンスとMFA

現代のサイバーセキュリティにおいて、アイデンティティは新たな境界線であり、デバイスのセキュリティ状態は信頼を確立する上で不可欠です。Microsoft Entra IDの条件付きアクセス（Conditional Access: CA）は、これらの要素を統合し、ユーザー、デバイス、場所、アプリケーション、リアルタイムリスクなどのシグナルに基づいて、きめ細やかなアクセス制御を可能にします。本記事では、特にデバイスコンプライアンスと多要素認証（MFA）を組み合わせた強固なアクセス戦略について、クラウドアーキテクトの視点から解説します。

アーキテクチャ

Entra ID条件付きアクセス、Microsoft Intune、およびEntra ID MFAサービスが連携し、ユーザーがクラウドアプリケーションにアクセスする際のセキュリティを強化します。このアーキテクチャでは、ユーザーがアプリケーションにアクセスを試みると、まずEntra IDが認証要求を受け取ります。その後、Entra ID CAポリシーエンジンが、定義された条件（ユーザー、アプリケーション、場所、デバイスの状態など）に基づいて評価を行います。

CAポリシーが「準拠デバイスを要求する」と指定している場合、Entra IDはMicrosoft Intuneと連携し、デバイスのコンプライアンス状態を確認します。Intuneは、組織が定義したセキュリティポリシー（OSバージョン、パスワード要件、ディスク暗号化など）に基づいてデバイスが準拠しているか否かを判断します。また、CAポリシーが「多要素認証を要求する」と指定している場合、Entra ID MFAサービスがユーザーに対してMFAチャレンジを実施します。これらの条件がすべて満たされた場合にのみ、ユーザーはアプリケーションへのアクセスを許可されます。

flowchart TD
    A["ユーザー"] --> |アクセス要求| B("Microsoft Entra ID");
    B -- 認証と認可 --> C{"条件付きアクセス"};
    C -- ポリシー評価 --> D{"条件判定"};
    D -- 条件: ユーザー, アプリ, 場所, デバイスの状態 --> E{"Grantコントロール"};
    E -- Grant: "準拠デバイスを要求" --> F["Microsoft Intune"];
    F --> |デバイスコンプライアンス確認| G{"デバイスの状態"};
    G -- 準拠済み --> H{"MFA要求"};
    H -- Grant: "MFAを要求" --> I["Microsoft Entra MFAサービス"];
    I --> |MFAチャレンジ| A;
    A -- MFA応答 --> I;
    I -- 認証成功 --> J("クラウドアプリケーション");
    G -- 非準拠 --> K["アクセス拒否"];
    I -- 認証失敗 --> K;

図1: Entra ID条件付きアクセスにおけるデバイスコンプライアンスとMFAのフロー

設定手順

Entra ID条件付きアクセスポリシーは、Azureポータル、Microsoft Graph API、またはPowerShell (Microsoft Graph PowerShell SDK) を使用して設定できます。ここでは、MFAと準拠デバイスを要求するCAポリシーをMicrosoft Graph PowerShell SDKで作成する例を示します。

前提条件:

  • Microsoft Entra ID P1またはP2ライセンス。

  • Microsoft Intuneライセンス。

  • Microsoft.Graph.Identity.ConditionalAccess PowerShellモジュールがインストール済みであること。

  • グローバル管理者、条件付きアクセス管理者、またはセキュリティ管理者ロールが付与されていること。

  • 緊急用アカウント（ブレークグラスアカウント）が事前に作成されており、ポリシーの対象から除外されていること。

# Graph API を使用してEntra ID条件付きアクセス ポリシーを作成する例

# 1. Microsoft Graphへの接続


# ConditionalAccessPolicy.ReadWrite.All スコープが必要です。


# Connect-MgGraph -Scopes "ConditionalAccessPolicy.ReadWrite.All"

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


# この例では、全てのユーザー（緊急用アカウントを除く）と全てのクラウドアプリを対象とします。


# デバイスプラットフォームも全てを対象とします。

$conditions = @{
    users = @{
        includeUsers = @("All") # 全ユーザーを対象に含める

        # 緊急用アカウントのオブジェクトIDを除外対象として指定します。


        # 例: $emergencyAccountObjectId = (Get-MgUser -UserId "breakglass@contoso.com").Id


        # 実際には環境に合わせて適切なIDを設定してください。

        excludeUsers = @("{{緊急用アカウントのオブジェクトID}}") 
    }
    applications = @{
        includeApplications = @("All") # 全てのクラウドアプリケーションを対象

        # excludeApplications = @("{{特定のアプリID}}") # 特定のアプリを除外する場合

    }
    platforms = @{
        includePlatforms = @("all") # 全てのデバイスプラットフォームを対象 (Windows, iOS, Android, macOS, Linux)
    }
    locations = @{
        includeLocations = @("all") # 全てのネットワークロケーションを対象

        # excludeLocations = @("{{信頼できるIPアドレス範囲のID}}") # 信頼できる場所を除外する場合

    }
    clientAppTypes = @("all") # 全てのクライアントアプリタイプを対象 (ブラウザ, モバイルアプリ, デスクトップアプリなど)
}

# 3. Grantコントロールを定義


# 多要素認証 (MFA) と準拠済みデバイス (compliantDevice) の両方を要求します。


# operator = "AND" は両方の条件を満たす必要があることを意味します。

$grantControls = @{
    operator = "AND"
    builtInControls = @("mfa", "compliantDevice") # MFAと準拠デバイスを要求
}

# 4. ポリシー名と状態を定義

$policyDisplayName = "グローバル: MFAと準拠デバイスの要求 (Report-Only)"

# ポリシーは最初に "reportOnly" 状態で作成し、影響を評価することを強く推奨します。


# 運用開始時に "enabled" に変更します。

$policyState = "reportOnly" # または "enabled"

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

Write-Host "Creating Conditional Access policy: '$policyDisplayName' with state '$policyState'..."
try {
    $newCaPolicy = New-MgIdentityConditionalAccessPolicy `
        -DisplayName $policyDisplayName `
        -Conditions $conditions `
        -GrantControls $grantControls `
        -State $policyState

    Write-Host "Conditional Access policy created successfully. Policy ID: $($newCaPolicy.Id)"
    Write-Host "Please test this policy thoroughly in 'reportOnly' mode before enabling."
}
catch {
    Write-Error "Failed to create Conditional Access policy: $($_.Exception.Message)"
}

# 参考: 既存ポリシーの状態を変更する例 (IDは上記作成時の出力またはAzure Portalから取得)


# $policyIdToUpdate = "{{作成されたポリシーのID}}"


# Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyIdToUpdate -State "enabled"

コード1: MFAと準拠デバイスを要求するCAポリシーのPowerShellでの作成例

上記コードは、最初にreportOnlyモードでポリシーを作成します。このモードでは、ポリシーが適用された場合の結果をログで確認でき、実際のアクセスはブロックされません。これにより、ユーザーへの影響を事前に評価し、予期せぬロックアウトを防ぐことができます。十分なテストの後、enabled状態に更新してください。

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

  • Entra ID (旧 Azure AD): ユーザーとグループの管理、認証、CAポリシーの評価と適用。

    • ロール: グローバル管理者、条件付きアクセス管理者、セキュリティ管理者。

  • Microsoft Intune: デバイスの登録と管理、コンプライアンスポリシーの定義と適用。

    • ロール: Intune管理者、デバイスポリシーマネージャー。

  • 条件付きアクセス (CA): Entra IDの一部として、ポリシーエンジンを実行し、リアルタイムでアクセス要求を評価。

  • Microsoft Defender for Endpoint: デバイスの脅威情報や脆弱性情報をIntuneに連携し、デバイスコンプライアンスの状態を向上させることが可能。

運用監視

効果的な条件付きアクセス戦略には、継続的な監視が不可欠です。

  • 可観測性:

    • Entra IDサインインログ: 条件付きアクセスによってアクセスが許可または拒否された理由を詳細に確認できます。ポリシー名と結果が記録されます。

    • Entra ID監査ログ: CAポリシーの作成、変更、削除などの管理操作が記録されます。

    • 条件付きアクセスワークブック: Azure Monitor上で利用できる専用のワークブックで、ポリシーの影響、成功/失敗率、ユーザーごとの詳細な適用状況をグラフィカルに可視化できます [Source 5, 2024-06-10, Microsoft]。

  • ログの保存: Entra IDの診断設定を通じて、サインインログと監査ログをAzure Log Analyticsワークスペースに送信し、長期間保存および分析できるように構成します。これにより、セキュリティイベントの履歴調査やコンプライアンス要件への対応が可能になります。

  • SLA/バックアップ/DR: Entra ID自体はMicrosoftによって高可用性（SLA 99.9%）と災害復旧（DR）が提供されています。CAポリシーはテナント設定の一部としてEntra IDに保存されるため、個別のバックアップ/リストア手順は通常不要です。ポリシーをIaC (Infrastructure as Code) で管理することで、構成のバージョン管理と展開の自動化が実現できます。

セキュリティ

条件付きアクセスは、アイデンティティベースのセキュリティにおいて極めて重要な役割を果たします。

  • ID保護: 不審なサインイン試行やリスクの高いユーザー行動に対して、MFAやパスワード変更を強制することで、IDの侵害を防ぎます。

  • デバイスの信頼: 組織のセキュリティ基準を満たすデバイスのみにアクセスを許可することで、マルウェア感染デバイスや脆弱なデバイスからの情報漏洩リスクを低減します。

  • ブレークグラスアカウント: 緊急時にCAポリシーが予期せぬロックアウトを引き起こした場合に備え、CAポリシーの対象外となる緊急用（ブレークグラス）アカウントを少なくとも2つ作成し、厳重に管理することが強く推奨されます [Source 7, 2024-07-16, Microsoft]。

  • 最小特権の原則: CAポリシーの管理には、必要最小限の権限を持つロール（例: 条件付きアクセス管理者）を割り当て、グローバル管理者ロールの使用は極力避けるべきです。

コスト

Entra ID条件付きアクセスとデバイスコンプライアンス機能の利用には、以下のライセンスが必要です。

  • Microsoft Entra ID P1 または P2: 条件付きアクセス機能の利用には、Microsoft Entra ID P1以上のライセンスが必要です。P2ライセンスには、ID保護（Identity Protection）機能も含まれ、リアルタイムのリスク検出をCAポリシーの条件として利用できます [Source 6, 2024-05-23, Microsoft]。

  • Microsoft Intune ライセンス: デバイスコンプライアンス管理には、Microsoft Intuneのライセンスが必要です。通常、Microsoft 365 E3/E5やEnterprise Mobility + Security (EMS) E3/E5などのスイートライセンスに含まれています。

コスト最適化: CAポリシー自体に直接的な使用量に応じた課金はありませんが、適切なライセンスを選択することがコスト最適化に繋がります。必要な機能に応じてP1またはP2を選択し、不要な上位ライセンスを避けることが重要です。Intuneに関しては、デバイス管理台数に応じたライセンスが必要となります。

落とし穴

条件付きアクセスは強力なツールですが、設定を誤るとユーザーの生産性を阻害したり、組織をロックアウトしたりする可能性があります。

  • 「レポートのみ」モードの軽視: ポリシーを有効にする前に必ず「レポートのみ」モードで十分なテスト期間を設けてください [Source 7, 2024-07-16, Microsoft]。これにより、予期せぬアクセス拒否やMFAループなどの問題を事前に特定できます。

  • 過度な制限: 必要以上に厳しいポリシーは、正当なユーザーのアクセスを妨げ、ヘルプデスクへの問い合わせ増加や生産性の低下を招きます。ビジネス要件とセキュリティ要件のバランスを見つけることが重要です。

  • 緊急用アカウントの欠如: 前述の通り、ブレークグラスアカウントがないと、設定ミスや予期せぬ障害時に全ての管理者がEntra IDから締め出されるリスクがあります。

  • ユーザーへの影響の考慮: 新しいポリシーを導入する際は、ユーザーに事前に通知し、MFAの登録方法やデバイスコンプライアンスの要件などを周知徹底する必要があります。

  • ポリシーの複雑化: ポリシーが複雑になりすぎると、管理が困難になり、意図しない設定漏れや競合が発生する可能性があります。シンプルかつ目的が明確なポリシー設計を心がけましょう。

まとめ

Entra ID条件付きアクセスは、デバイスコンプライアンスと多要素認証を組み合わせることで、現代の脅威から組織のデータとリソースを保護するための非常に効果的なフレームワークを提供します。アーキテクチャの理解、計画的な設定、継続的な監視、そしてベストプラクティスに従うことで、セキュリティを強化しつつ、ユーザーエクスペリエンスを最適化することが可能です。常に「レポートのみ」モードでのテストを徹底し、緊急用アカウントを確保し、適切なライセンスを選択することで、安全で堅牢なアクセス環境を構築しましょう。

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

コメント

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