Microsoft Entra ID 条件付きアクセスとMFAによるゼロトラストセキュリティ実装

Tech

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

Microsoft Entra ID 条件付きアクセスとMFAによるゼロトラストセキュリティ実装

Microsoft Entra ID（旧 Azure Active Directory）の条件付きアクセス（Conditional Access: CA）と多要素認証（Multi-Factor Authentication: MFA）は、今日の複雑なサイバー脅威環境において、ゼロトラストセキュリティモデルを実装するための基盤となる機能です。本記事では、クラウドアーキテクトの視点から、これらの機能を最大限に活用し、堅牢なセキュリティ体制を構築するためのアーキテクチャ、設定、運用、コスト、そして潜在的な落とし穴について解説します。

アーキテクチャの概要

Microsoft Entra ID 条件付きアクセスは、ユーザーがクラウドアプリケーションやオンプレミスアプリケーションにアクセスする際の「if-then」ステートメントとして機能します [1]。具体的には、ユーザーがアクセスを試行する際に、ユーザー属性、デバイスの状態、場所、アプリケーション、リアルタイムのリスク検出などの様々なシグナルを評価し、MFAの要求、アクセスブロック、デバイスの準拠の要求といった制御を適用します。MFAは、ユーザーが知っているもの（パスワード）、持っているもの（スマートフォン）、またはユーザー自身（生体認証）の複数の認証要素を組み合わせることで、セキュリティを大幅に向上させます [7]。

この統合アーキテクチャにより、以下の主要なセキュリティ原則が実現されます。

  • ゼロトラスト（Never Trust, Always Verify）: 常にアクセス要求を検証し、最小限の特権アクセスを保証します。

  • 多層防御: MFAと組み合わせることで、単一の認証要素が侵害されてもアクセスを防ぐことができます。

  • コンテキストに応じたアクセス制御: アクセス試行時のコンテキストに基づいて、動的にセキュリティポリシーを適用します。

条件付きアクセスの意思決定フロー

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

flowchart TD
    A["ユーザーがアクセスを試行"] --> B{"サインインシグナル収集"};
    B --> C{"条件付きアクセスポリシー評価"};
    C -- 該当ポリシーあり --> D{"ポリシー条件一致?"};
    D -- YES | すべての条件が一致 --> E{"アクセス制御適用"};
    E -- MFA要求 | デバイス準拠要求 | アクセスブロック --> F{"ユーザーインタラクション"};
    F -- 成功 | MFA認証済み | デバイス準拠 --> G["アクセス許可"];
    F -- 失敗 | MFA未認証 | デバイス未準拠 --> H["アクセス拒否"];
    D -- NO | 条件が一致しない --> G;
    C -- 該当ポリシーなし --> G;

説明:

  1. ユーザーがアクセスを試行: ユーザーがMicrosoft 365などのクラウドアプリケーションへのアクセスを開始します。

  2. サインインシグナル収集: Microsoft Entra IDは、ユーザー、デバイス、場所、アプリケーション、サインインリスクなどの情報を収集します。

  3. 条件付きアクセスポリシー評価: 収集されたシグナルを基に、すべてのCAポリシーが評価されます。

  4. ポリシー条件一致?: 評価されたポリシーの条件にすべて合致するかを判断します。

  5. アクセス制御適用: 条件が一致した場合、関連する制御（MFA要求、デバイス準拠要求、アクセスブロックなど）が適用されます。

  6. ユーザーインタラクション: ユーザーは適用された制御に従ってアクション（MFA認証、デバイス準拠の確認など）を実行します。

  7. アクセス許可: すべての条件と制御が満たされれば、アクセスが許可されます。

  8. アクセス拒否: 条件が満たされないか、制御が失敗した場合、アクセスは拒否されます。

設定手順

条件付きアクセスの設定は、Microsoft Entra管理センターからGUIで実施できますが、IaC（Infrastructure as Code）やGraph API/PowerShellを利用することで、より効率的かつ一貫性のあるデプロイが可能です。ここでは、PowerShellとMicrosoft Graph APIを利用した設定例を示します。

前提条件:

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

  • Graph PowerShell SDKのインストール。

  • 適切な権限（条件付きアクセス管理者、セキュリティ管理者など）。

1. すべての管理ユーザーにMFAを要求するポリシーの作成

このポリシーは、Azureロールに割り当てられたユーザーがサインインする際にMFAを要求します。これは最も基本的なセキュリティ要件の一つです [2]。

# Graph PowerShell SDKをインポート


# Install-Module Microsoft.Graph -Scope CurrentUser

# 接続（初回のみ認証プロンプトが表示されます）


# スコープ: Policy.ReadWrite.ConditionalAccess は条件付きアクセス ポリシーの読み書き権限を与えます。

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

# ポリシーの定義

$policyDisplayName = "すべての管理者に対するMFA要求"

# state: enabled (有効), enabledForReportingButBlocked (レポート専用、ブロックはしない), disabled (無効)

$policyState = "enabled" 

# ユーザー条件: グローバル管理者ロールのユーザーを対象に含めます。


# グローバル管理者ロールのIDは "62e90394-69f5-4237-91fa-a95dfd01865a" です。


# 組織の緊急アクセスアカウントなど、MFAを除外するユーザーは excludedUsers に指定します。

$users = @{
    includedGroups = @() 
    includedRoles = @("62e90394-69f5-4237-91fa-a95dfd01865a")
    includedUsers = @()
    excludedUsers = @() 
}

# アプリケーション条件: すべてのクラウドアプリに適用します。

$conditions = @{
    applications = @{
        includedApplications = @("All") 
    }
    clientAppTypes = @("all") # すべてのクライアントアプリタイプ (ブラウザ、モバイルアプリなど)
}

# アクセス制御: MFAを要求します。

$grantControls = @{
    operator = "OR"
    builtInControls = @("mfa") # 多要素認証を要求
}

# ポリシーオブジェクトの構築

$policy = @{
    displayName = $policyDisplayName
    state = $policyState
    conditions = $conditions
    grantControls = $grantControls
    users = $users
}

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


# 出力: 作成されたポリシーの DisplayName, State, Id を表示します。

New-MgIdentityConditionalAccessPolicy -BodyParameter $policy | Format-List DisplayName, State, Id

# ポリシーIDの取得例（既存ポリシーの更新や確認用）


# Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, Id

コメント:

  • includedRoles: 特定のAzure ADロールIDを指定することで、そのロールに割り当てられたユーザーを対象とします。グローバル管理者のIDは62e90394-69f5-4237-91fa-a95dfd01865aです。

  • excludedUsers: 緊急アクセスアカウントなど、ポリシーの対象外とするユーザーを指定します。本番環境に適用する前に、必ず緊急アクセスアカウントを例外設定し、テストを実施してください [5]。

  • state = "enabledForReportingButBlocked": この設定でポリシーをデプロイすると、実際にアクセスをブロックすることなく、そのポリシーが適用された場合のログを確認できます。これにより、影響範囲を事前に把握し、運用リスクを低減できます [5]。

運用監視

条件付きアクセスの効果的な運用には、継続的な監視と評価が不可欠です。

  • サインインログの監視: Microsoft Entra管理センターの「サインインログ」では、ユーザーのサインイン試行と、それに対してどの条件付きアクセスポリシーが適用されたか、結果としてアクセスが許可されたか、拒否されたかを確認できます [3]。

  • 条件付きアクセス Insights and Reporting: この機能は、CAポリシーのインパクトを可視化し、ポリシーがどれくらいのユーザーに影響を与えているか、どのような結果になっているか（成功、失敗、MFA要求など）を詳細に分析できます [3]。これは新しいポリシーをデプロイする際や既存ポリシーの効果を評価する際に非常に有用です。

  • Audit ログ: 条件付きアクセスポリシーの作成、更新、削除といった管理アクティビティはAuditログに記録されます。これにより、誰がいつポリシーを変更したかを追跡できます。

  • Microsoft Sentinelとの統合: Entra IDのログはMicrosoft Sentinelに統合することで、高度な脅威検出、相関分析、自動応答（SOAR）のシナリオに活用できます。

可観測性、SLA、バックアップ/DR

  • 可観測性: 上記のログとレポート機能を活用し、異常なサインインパターンやポリシーの誤設定を早期に検出します。アラートを設定し、特定の条件（例: 多数のアクセス拒否）が発生した場合に運用チームに通知することが重要です。

  • SLA: Microsoft Entra ID自体は、Microsoftのサービスレベルアグリーメント（SLA）に準拠しており、高い可用性が保証されています。条件付きアクセスもこの基盤上で動作するため、個別のSLAは提供されませんが、Entra IDのSLAに準じます。

  • バックアップ/DR: 条件付きアクセスポリシーはMicrosoft Entra IDテナントの構成情報の一部として保存されます。明示的な「バックアップ」機能はありませんが、PowerShellスクリプトやGraph APIを利用してポリシー定義をJSON形式でエクスポートし、Gitリポジトリなどで管理することで、構成のバックアップとバージョン管理を実現できます。これにより、誤った変更が発生した場合のロールバックや、新しいテナントへの迅速なデプロイが可能になります。

セキュリティ

条件付きアクセスは、以下の点でセキュリティを大幅に強化します。

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

    • Entra ID: IDプロバイダーとして認証と認可の基盤を提供します。

    • ロール: ユーザーに割り当てることで、最小特権の原則を適用します。条件付きアクセスは、特定のロールを持つユーザーに対してのみポリシーを適用できます（例: グローバル管理者ロールにMFAを強制）。

    • 条件付きアクセス: サインイン時に動的にアクセスを評価し、特定の制御（MFA、デバイス準拠、場所制限など）を強制します。これは、Entra IDとアプリケーション間のアクセス境界を確立します。

    • Microsoft Defender for Cloud Apps (MDCA): CAと連携し、リアルタイムのセッション制御（例: ダウンロードブロック）を提供します。これにより、データ流出のリスクを低減できます。MDCAはCASB（Cloud Access Security Broker）機能を提供し、アクセス後の行動を監視・制御します。

    • Microsoft Entra Identity Protection: Microsoft Entra ID P2ライセンスに含まれる機能で、ユーザーやサインインのリスクをリアルタイムで検出し、条件付きアクセスと連携して、リスクレベルに応じたMFA要求やパスワード変更要求を自動化できます [4]。

  • 緊急アクセスアカウント: すべてのCAポリシーの対象外となる「緊急アクセスアカウント」を少なくとも2つ作成し、厳重に管理することが必須です [5]。これにより、CAポリシーの誤設定や、Entra IDの障害時に管理者が完全にロックアウトされるリスクを回避できます。

  • レポート専用モード（Report-only mode）: 新しいポリシーを本番環境にデプロイする前に、必ず「レポート専用モード」でテストし、予期せぬ影響がないことを確認します [5]。これにより、業務への影響を最小限に抑えながら、ポリシーの効果を評価できます。

  • 継続的なレビュー: ポリシーは一度設定したら終わりではありません。組織のセキュリティ要件の変化や新しい脅威に対応するため、定期的にポリシーを見直し、最適化する必要があります。

コスト

条件付きアクセス機能を利用するには、Microsoft Entra ID P1またはP2ライセンスが必要です [4]。

  • Microsoft Entra ID P1:

    • 基本的な条件付きアクセス機能が含まれます。

    • デバイスベースのCA、場所ベースのCA、アプリケーションベースのCAなどが利用可能です。

  • Microsoft Entra ID P2:

    • P1の機能に加え、Microsoft Entra Identity Protectionが含まれます。

    • リスクベースの条件付きアクセスが可能になり、ユーザーリスクやサインインリスクに基づいて動的にアクセス制御を適用できます。これは高度なセキュリティ対策に不可欠です。

    • Microsoft Defender for Cloud Appsとの連携も強化されます。

コスト最適化の観点からは、組織のセキュリティ要件と予算を慎重に比較検討する必要があります。

  • P1で十分かP2が必要か: 高度な脅威検出とリスクベースのアクセス制御が必須であればP2が推奨されます。特に、多数のSaaSアプリケーションを利用し、多様なデバイスからのアクセスが予想される場合はP2の価値が高いです。

  • ユーザー数に応じたライセンスコスト: ライセンスはユーザーごとに課金されるため、対象となるユーザー数が多いほどコストは増加します。

落とし穴と注意点

  • ロックアウトのリスク: ポリシーの設計ミスや緊急アクセスアカウントの未設定は、管理者がEntra IDから完全にロックアウトされる重大なリスクを招きます [5]。

  • 過剰なポリシーの複雑化: あまりに多くのポリシーを設定したり、条件を細かくしすぎると、管理が複雑になり、予期せぬ動作やトラブルシューティングの困難さにつながります。共通のポリシーを適用し、必要に応じて除外設定を利用するなど、シンプルさを心がけましょう。

  • テスト不足: レポート専用モードを使用せず、いきなりenabledでポリシーをデプロイすると、ユーザーの生産性に深刻な影響を与える可能性があります [5]。

  • MFA導入時のユーザーへの影響: MFAはセキュリティを向上させますが、ユーザーによっては不便に感じる場合があります。MFAの導入前には十分なアナウンスとトレーニングを行い、FIDO2セキュリティキーのような使いやすい認証方法も検討しましょう。

  • レガシー認証の排除: 条件付きアクセスは、レガシー認証プロトコル（POP3, IMAP4, SMTPなど）からのアクセスをブロックするポリシーを設定できます。これらを有効にすることで、ブルートフォース攻撃などのリスクを大幅に低減できますが、既存のアプリケーションへの影響を十分に評価する必要があります。

まとめ

Microsoft Entra IDの条件付きアクセスとMFAは、ゼロトラストセキュリティ戦略の中心的な要素です。この2つの機能を適切に組み合わせることで、ユーザーの生産性を損なうことなく、強固なセキュリティ体制を構築できます。アーキテクチャ設計から始まり、PowerShellやGraph APIを活用した効率的な設定、継続的な運用監視、そして潜在的なコストとリスクの管理まで、全体的なライフサイクルを考慮することが成功の鍵です。 特に、緊急アクセスアカウントの確保とレポート専用モードでの慎重なテストは、ロックアウトという最悪のシナリオを避けるために不可欠です。これらのベストプラクティスを遵守することで、組織はデジタル資産を効果的に保護し、変化し続ける脅威環境に対応できるようになります。

参考文献: [1] Microsoft Learn. 「条件付きアクセスとは何ですか?」. 最終更新日: 2024年6月12日. 取得元: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview [2] Microsoft Learn. 「一般的な条件付きアクセス ポリシー」. 最終更新日: 2024年5月28日. 取得元: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-conditional-access-policies-common [3] Microsoft Learn. 「条件付きアクセスを監視およびレポートする」. 最終更新日: 2024年4月10日. 取得元: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/howto-conditional-access-insights-reporting [4] Microsoft Learn. 「条件付きアクセスの前提条件」. 最終更新日: 2024年6月12日. 取得元: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview#prerequisites [5] Microsoft Learn. 「条件付きアクセスのベスト プラクティス」. 最終更新日: 2024年3月15日. 取得元: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/best-practices [6] Microsoft Learn. 「Microsoft Graph API で条件付きアクセス ポリシーを管理する」. 最終更新日: 2024年6月5日. 取得元: https://learn.microsoft.com/ja-jp/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0 [7] Microsoft Learn. 「しくみ: Microsoft Entra 多要素認証」. 最終更新日: 2024年5月1日. 取得元: https://learn.microsoft.com/ja-jp/azure/active-directory/authentication/concept-mfa-howitworks

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

コメント

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