Microsoft Entra ID 条件付きアクセスによるゼロトラスト実現

Tech

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

Microsoft Entra ID 条件付きアクセスによるゼロトラスト実現

Microsoft Entra ID 条件付きアクセス（Conditional Access、CA）は、Microsoft Entra ID（旧 Azure Active Directory）のセキュリティフレームワークの中核をなす機能であり、組織がゼロトラストモデルを実装するための重要なツールです。ユーザー、デバイス、場所、アプリケーション、サインインリスクなどの特定の条件に基づいてアクセス制御ポリシーを定義し、リソースへのアクセスを許可、ブロック、または多要素認証（MFA）などの追加のセキュリティ要件を強制することで、組織のセキュリティ体制を強化します。

アーキテクチャ概要

Microsoft Entra ID 条件付きアクセスは、認証要求がMicrosoft Entra IDによって受信された際に、リアルタイムでポリシー評価を行うエンジンとして機能します。その基本的なアーキテクチャは「条件（Assignments）」と「制御（Access Controls）」で構成されます。

  • 条件 (Assignments): アクセス要求がどのような状況で行われているかを定義します。

    • ユーザーとグループ: 特定のユーザーまたはグループにポリシーを適用します。すべてのユーザーに適用することも、特定のユーザーやグループを除外することも可能です。

    • クラウド アプリまたはアクション: アクセスしようとしている特定のSaaSアプリ、オンプレミスアプリ、ユーザーアクション（例: ユーザー登録情報の登録/変更）を指定します。

    • デバイス プラットフォーム: iOS、Android、Windows、macOSなど、デバイスのOSを識別します。

    • 場所: 特定のIPアドレス範囲（信頼済みIP）からのアクセスか、信頼できない場所からのアクセスかを判断します。

    • クライアント アプリ: ブラウザ、モバイルアプリ、デスクトップクライアント、Exchange ActiveSyncなど、使用されているクライアントアプリの種類を識別します。

    • デバイスの状態: デバイスが「準拠」または「ハイブリッド Azure AD 参加済み」であるかを評価します。

    • サインイン リスク: Microsoft Entra ID Identity Protectionによって検出されたサインインのリスクレベルに基づいてポリシーを適用します（Premium P2機能）。

  • 制御 (Access Controls): 条件が満たされた場合に適用されるアクションを定義します。

    • アクセスを許可する:

      • 多要素認証を要求する (MFA)

      • デバイスを準拠としてマークすることを要求する

      • ハイブリッド Azure AD 参加済みデバイスを要求する

      • 承認済みクライアント アプリを要求する

      • アプリ保護ポリシーを要求する

    • アクセスをブロックする: アクセス要求を拒否します。

    • セッション制御:

      • アプリ強制制限（Microsoft Defender for Cloud Appsとの連携）

      • サインイン頻度、永続的ブラウザーセッションの制御

このフレームワークにより、組織は「適切なユーザーが、適切なデバイスから、適切な場所で、適切なアプリケーションに、適切なリスクレベルでアクセスしているか」を動的に評価し、セキュリティを確保できます。

以下は、条件付きアクセスがどのように評価されるかを示すフローチャートです。

flowchart TD
    A["ユーザーの認証要求"] --> |ID/パスワード提供|B("Microsoft Entra ID");
    B --> |ポリシー評価要求|C{"条件付きアクセス ポリシー エンジン"};
    C --> |条件評価|D["ユーザー/グループ"];
    C --> |条件評価|E["クラウド アプリ"];
    C --> |条件評価|F["デバイス プラットフォーム"];
    C --> |条件評価|G["場所"];
    C --> |条件評価|H["サインイン リスク"];
    D & E & F & G & H --> I{"すべての条件に合致?"};
    I --|Yes| J["アクセス制御の適用"];
    J --> K{"許可制御は適用可能?"};
    K --|Yes| L["MFAを要求/準拠デバイスを要求 など"];
    L --> M["認証成功/アクセス許可"];
    K --|No| N["アクセスをブロック"];
    I --|No| M;
    M --|アクセストークン発行| P("リソースへアクセス");

[1] Microsoft Learn: 条件付きアクセスとは何か (最終更新日: 2024年5月23日)

条件付きアクセス ポリシーの構成手順

条件付きアクセス ポリシーは、Azure portalからグラフィカルに設定できるほか、Microsoft Graph APIを利用してIaC（Infrastructure as Code）として管理することも可能です。ここでは、PowerShellとMicrosoft Graph APIを使用してポリシーを作成する具体例を示します。

この例では、「特定のユーザーグループが、信頼できない場所から、特定のクラウドアプリケーション（例: Microsoft 365）にアクセスしようとした場合に、多要素認証（MFA）を要求する」ポリシーを作成します。

前提条件:

  • Microsoft Entra ID P1またはP2ライセンスが割り当てられていること。

  • Graph APIにアクセスするための適切な権限を持つサービスプリンシパルまたはユーザーアカウントがあること（例: Conditional Access Administrator ロール）。

  • Microsoft Graph PowerShell SDK または curl などのツールが利用可能であること。

# Graph APIのアクセス情報を設定

$tenantId = "YOUR_TENANT_ID" # 実際のテナントIDに置き換える
$appId = "YOUR_APP_ID"     # Graph APIにアクセスするためのアプリケーションID (例: Azure ADアプリ登録で取得)
$appSecret = "YOUR_APP_SECRET" # アプリケーションのシークレット

# アクセストークンを取得

$body = @{
    client_id = $appId
    client_secret = $appSecret
    scope = "https://graph.microsoft.com/.default"
    grant_type = "client_credentials"
}
$tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Method Post -Body $body
$accessToken = $tokenResponse.access_token

# 適用対象となるグループのID (例: "Sales Department" グループ)

$targetGroupId = "YOUR_TARGET_GROUP_ID" # 実際のグループIDに置き換える

# 信頼できない場所 (すべての場所から信頼できる場所を除外)


# "all" を指定し、"trustedLocations" を除外することで「すべての場所 - 信頼できる場所」を表現できるが、


# Graph APIで `excludeLocations` は `includeLocations` が `any` の場合のみサポート。


# ここでは例として、特定の国のIP範囲を「信頼できない」と見なす場合は、その国のIP範囲IDを指定する。


# 例として、特定の国を「Japan」以外のすべてとする場合は、国IDを指定するか、動的に作成したIP名前付き場所のIDを指定する。


# 今回は簡略化のため、「すべての場所」として定義し、信頼できる場所がないと仮定する。


# または、Azure Portalで事前に「信頼できる場所」を定義し、そのIDをここで除外する。


# (Graph APIでLocationオブジェクトのIDを取得する必要がある)


# 実際のシナリオでは、Name-based location (Named Location) を事前に定義し、そのIDを使用するのが一般的。


# 例: $untrustedLocationId = "YOUR_UNTRUSTED_LOCATION_ID"

# ポリシー定義のJSONボディ

$policyJson = @{
    displayName = "MFA Required for Sales from Untrusted Locations to M365"
    state = "enabledForReportingButNotEnforced" # 初めはレポート専用モードでデプロイ推奨
    conditions = @{
        users = @{
            includeGroups = @($targetGroupId)
        }
        applications = @{
            includeApplications = @("All") # 特定のアプリID (例: Microsoft 365 Apps) を指定することも可能
        }
        locations = @{
            includeLocations = @("All") # 例としてすべての場所を含める

            # excludeLocations = @($trustedLocationId) # 信頼できる場所のIDがあればここで除外

        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa") # MFAを要求
    }
} | ConvertTo-Json -Depth 5 # 構造が複雑なためDepthを増やす

# 条件付きアクセス ポリシーを作成するGraph APIエンドポイント

$uri = "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"

# ポリシーを作成

try {
    $response = Invoke-RestMethod -Uri $uri -Method Post -Headers @{Authorization = "Bearer $accessToken"} -ContentType "application/json" -Body $policyJson
    Write-Host "条件付きアクセス ポリシーが正常に作成されました。"
    $response | Format-List
}
catch {
    Write-Error "条件付きアクセス ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
    $_.Exception.Response.Content | ConvertFrom-Json | Format-List
}

コメント:

  • 入力: $tenantId, $appId, $appSecret, $targetGroupId (およびオプションで $trustedLocationId または特定の場所のID)。

  • 出力: 新しく作成された条件付きアクセス ポリシーのオブジェクト。

  • 前提: 事前にアプリケーション登録と権限付与が必要。ConditionalAccess.ReadWrite.All 権限を持つサービスプリンシパルまたはユーザーコンテキストで実行。

  • 計算量: 単一のAPI呼び出しであり、オーケストレーションは不要なため、計算量は小さい。

  • メモリ条件: JSONペイロードのサイズに依存するが、通常は非常に小さい。

注意点: state = "enabledForReportingButNotEnforced" はレポート専用モードです。本番環境に適用する前に、必ずこのモードで効果を検証してください。検証後、"enabled" に変更することでポリシーが強制されます。[8] Microsoft Learn: Microsoft Graph を使用して条件付きアクセス ポリシーを管理する (最終更新日: 2024年5月23日)

運用監視と可観測性

条件付きアクセス ポリシーの導入後も、その効果を継続的に監視し、必要に応じて調整することが不可欠です。

  • サインインログ: Microsoft Entra IDのサインインログは、各認証試行に対してどの条件付きアクセス ポリシーが適用され、その結果どうなったか（成功、失敗、MFA要求など）を詳細に記録します。Azure portalの「Microsoft Entra ID」→「監視」→「サインインログ」から確認できます。

  • 条件付きアクセス What Ifツール: Azure portalの条件付きアクセスブレードにある「What If」ツールは、特定のユーザー、アプリケーション、デバイス、場所などの条件でアクセスした場合に、どのポリシーが適用され、どのような結果になるかをシミュレーションできます。デプロイ前のテストや、トラブルシューティングに非常に有効です。[6] Microsoft Learn: 条件付きアクセスの設定のテスト (最終更新日: 2024年5月23日)

  • レポート専用モード: 新規ポリシーを最初に「レポート専用モード」でデプロイすることで、実際のユーザーアクセスに影響を与えることなく、ポリシーがどのように適用されるかをサインインログで確認できます。このモードで一定期間監視し、予期しない影響がないことを確認してから「オン（強制）」モードに切り替えるのがベストプラクティスです。[5] Microsoft Learn: 条件付きアクセス ポリシーの計画 (最終更新日: 2024年5月23日)

  • Azure Monitor ワークブック: Microsoft Entra IDのログはAzure Monitorに統合できるため、カスタムのワークブックを作成して条件付きアクセスに関する詳細なレポートやダッシュボードを構築し、傾向分析や異常検知を行うことが可能です。[7] Microsoft Learn: 条件付きアクセスのトラブルシューティング (最終更新日: 2024年5月23日)

  • SLAとDR/バックアップ: Microsoft Entra ID自体は、Premium P1/P2ライセンスにおいて99.9%の可用性SLAを提供しています[4] (Microsoft Learn, 2024年5月30日)。条件付きアクセスはこの基盤上で動作するため、同様の高可用性が期待できます。ポリシー設定のバックアップや災害復旧（DR）については、ポリシー設定はMicrosoft Entra IDテナントに保存されており、Graph APIを通じてエクスポート・インポートすることで、設定をコードとして管理（IaC）し、必要な場合に復元することが可能です。

セキュリティと権限境界

条件付きアクセスは、Microsoft Entra IDのセキュリティスタックにおいて重要な役割を担い、アイデンティティと権限境界を明確にします。

  • Microsoft Entra ID: ユーザー、グループ、デバイス、アプリケーションといったすべてのアイデンティティのプロバイダーであり、認証を行います。

  • 条件付きアクセス（CA）: 認証されたアイデンティティがリソースにアクセスする際の「条件」を評価し、「アクセス制御」を決定するエンフォースメントポイントです。CAは、誰が（ユーザー/グループ）、どこから（場所）、何を使って（デバイス/クライアントアプリ）、何に（クラウドアプリ）、どのような状況で（リスクレベル）アクセスするかを判断します。

  • Microsoft Defender for Cloud Apps（MDCA）: 条件付きアクセスと連携し、より高度なセッション制御を提供します。例えば、特定条件下のセッションで、ユーザーが機密ファイルをダウンロードすることを禁止したり、リアルタイムでユーザーアクティビティを監視・アラートを生成したりすることが可能です。

  • Microsoft Entra IDロール: 条件付きアクセス ポリシーの管理には、特定の管理ロールが必要です。例えば、「条件付きアクセス管理者」「セキュリティ管理者」「グローバル管理者」などのロールを持つユーザーのみが、ポリシーの作成、変更、削除を行うことができます。これにより、ポリシー自体の変更に対する権限境界が確保されます。ただし、ポリシーが一旦設定されると、そのポリシーはEntra IDの認証パイプラインに組み込まれ、ポリシーの適用はポリシーによって対象とされたユーザーの管理ロールには依存しません。

  • ゼロトラストの実現: 条件付きアクセスは「決して信頼せず、常に検証する (Never Trust, Always Verify)」というゼロトラストの原則を具体的に実装します。ユーザーが社内ネットワークにいるからといって信頼せず、毎回、アイデンティティ、デバイスの状態、場所、セッションリスクなどを検証し、適切なアクセス権を付与することで、セキュリティ違反のリスクを最小限に抑えます。[3] Microsoft Learn: 条件付きアクセスとは (最終更新日: 2024年6月24日)

コストとライセンス最適化

条件付きアクセス機能を利用するためには、適切なMicrosoft Entra IDのライセンスが必要です。

  • ライセンス要件: Microsoft Entra ID Premium P1 または Premium P2 ライセンスが必要です。

    • Microsoft Entra ID Premium P1: 多要素認証（MFA）、デバイスベースの条件（ハイブリッド Azure AD 参加済み、デバイスの準拠）、場所ベースの条件、承認済みクライアントアプリとアプリ保護ポリシーなどの基本的な条件付きアクセス機能が利用できます。

    • Microsoft Entra ID Premium P2: P1のすべての機能に加え、Microsoft Entra ID Identity Protectionによるリアルタイムのサインインリスクおよびユーザーリスク検出に基づく条件、Just-In-Time（JIT）アクセスレビューなどの高度な機能が利用できます。

  • コスト最適化:

    • P1 vs P2 の選択: 組織のセキュリティ要件と予算に基づいて適切なライセンスを選択します。リスクベースの適応型ポリシーや高度なID保護機能が必要な場合はP2が推奨されますが、基本的なMFAやデバイス・場所ベースの制御で十分な場合はP1でコストを抑えることができます。

    • ユーザーライセンスの割り当て: Microsoft Entra ID Premiumライセンスはユーザー単位で課金されます。全てのユーザーにP2ライセンスを割り当てる必要はなく、高度なセキュリティ要必要とする管理者や特定の部門のユーザーにのみP2ライセンスを割り当て、その他のユーザーにはP1ライセンスを割り当てることで、コストを最適化できます。必要なユーザー数を見積もり、過剰なライセンス購入を避けることが重要です。

    • リソース最適化: 条件付きアクセス自体は、特定のコンピューティングリソースを消費するわけではなく、Microsoft Entra IDのサービスの一部として提供されます。したがって、スケジューリングやリザーブドインスタンスによるコスト最適化は適用されません。運用監視のためにAzure Monitorのログ分析を使用する場合、ログの保存期間やデータ量に応じてコストが発生するため、適切なログ保持ポリシーを設定することが推奨されます。

[4] Microsoft Learn: Microsoft Entra ID のライセンス要件 (最終更新日: 2024年5月30日)

導入における落とし穴とベストプラクティス

条件付きアクセスは非常に強力なツールですが、不適切な設定はユーザーのロックアウトや運用の中断を招く可能性があります。

  • 緊急アクセスアカウントの除外: 最も重要なベストプラクティスの一つです。最低2つのクラウド専用グローバル管理者アカウント（ディレクトリ同期されないアカウント）を全ての条件付きアクセス ポリシーから除外してください。これにより、ポリシーの設定ミスや構成エラーによって全ての管理者がロックアウトされる事態を防ぎます。これらのアカウントは厳重に管理し、緊急時のみ使用するようにしてください。[5] Microsoft Learn: 条件付きアクセス ポリシーの計画 (最終更新日: 2024年5月23日)

  • What Ifツールとレポート専用モードの活用: ポリシーを本番環境に適用する前に、必ず「What If」ツールで影響をシミュレーションし、最初のデプロイは「レポート専用モード」で行ってください。このモードで一定期間（数日〜数週間）運用し、サインインログを確認して予期しないアクセスブロックや動作がないことを確認してから、本番環境に適用（「オン」モードに変更）します。

  • 段階的なロールアウト: 全ユーザーに一斉にポリシーを適用するのではなく、まず少数のテストユーザーグループに適用し、問題がないことを確認してから、徐々にユーザー範囲を拡大していく「段階的ロールアウト」が推奨されます。

  • ポリシーの命名規則と文書化: 複雑な環境では多数のポリシーが共存するため、明確な命名規則（例: CA_MFA_AllUsers_UntrustedLocation）を定め、各ポリシーの目的、対象、影響を文書化することが、運用保守の効率化につながります。

  • 既存ポリシーとの競合確認: 新しいポリシーを作成する際には、既存のポリシーとの競合や予期しない相互作用がないかを確認することが重要です。特に、複数のポリシーが同じユーザーやアプリケーションを対象とする場合、最も制限の厳しいポリシーが適用される傾向があるため、注意が必要です。

まとめ

Microsoft Entra ID 条件付きアクセスは、現代の複雑なクラウド環境において、アイデンティティベースのセキュリティを強化し、ゼロトラストモデルを実現するための不可欠な機能です。適切なアーキテクチャ設計、Microsoft Graph APIを活用した効率的な設定、そして継続的な運用監視を通じて、組織はセキュリティ体制を大幅に向上させることができます。また、Microsoft Entra ID Premium P1/P2ライセンスの適切な選択と割り当てにより、コストを最適化しつつ、セキュリティ要件を満たすことが可能です。導入時には緊急アクセスアカウントの除外やレポート専用モードの活用といったベストプラクティスを厳守し、計画的かつ慎重に進めることが、成功への鍵となります。

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

コメント

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