Azure AD Conditional Access MFAとデバイスによる堅牢なアクセス制御

Tech

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

Azure AD Conditional Access MFAとデバイスによる堅牢なアクセス制御

アーキテクチャの概要

Microsoft Entra ID（旧 Azure AD）のConditional Access（条件付きアクセス、以下CA）は、ゼロトラストモデルの中核をなす強力なセキュリティ機能です。ユーザーがクラウドアプリケーションにアクセスしようとした際、リアルタイムで様々なシグナル（ユーザー、場所、デバイスの状態、サインインリスクなど）を評価し、定義されたポリシーに基づいてアクセスを許可、制限、またはブロックします。特に、多要素認証（MFA）とデバイスの状態を組み合わせることで、従来のパスワード認証のみに依存するよりも遥かに堅牢なアクセス制御を実現します[5]。

デバイスベースのCAは、アクセス元のデバイスが組織のセキュリティポリシーに準拠しているか、または信頼できるデバイス（Azure AD 参加済み、ハイブリッド Azure AD 参加済みなど）であるかを判断し、アクセス可否の条件とします[1, 2]。これにより、未承認デバイスやセキュリティ基準を満たさないデバイスからのアクセスを制限し、データ漏洩のリスクを低減します。

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

このアーキテクチャの中心となるのはMicrosoft Entra IDです。ユーザーとデバイスのIDはEntra IDで管理され、CAポリシーはEntra IDテナント内で構成されます。デバイスのコンプライアンス状態は通常、Microsoft Intune（デバイス管理ソリューション）によって評価され、その情報がEntra IDに連携されます[1]。

CAポリシーの管理には、条件付きアクセス管理者またはグローバル管理者のEntra IDロールが必要です。これらのロールを持つユーザーは、ポリシーの作成、変更、削除を行うことができます。

以下は、Conditional Accessによるアクセス評価のフローを示したMermaid図です。

flowchart TD
    A["ユーザーがクラウドアプリにアクセスを試行"] --> B{"サインイン要求がEntra IDに到達"}
    B --|ポリシー評価を開始| C{"Conditional Accessポリシー評価"}
    C --|条件一致を判断| D{"いずれかのポリシー条件に合致？"}
    D --|Yes| E{"デバイス状態を評価するポリシーが適用される"}
    E --|デバイスが非準拠または未参加| F["アクセスをブロックする"]
    E --|デバイスが準拠またはハイブリッドAD参加| G{"MFAが要求されている？"}
    G --|Yes| H["ユーザーにMFAを要求"]
    H --|MFA認証成功| I["アクセスを許可する"]
    G --|No| I
    D --|No| I
    F --|エンドユーザーに通知| J["アクセスが拒否されました"]
  • 図の解説: ユーザーがクラウドアプリにアクセスしようとすると、Entra IDがサインイン要求を受け取ります。設定されたCAポリシーが評価され、条件が一致する場合、デバイスの状態が評価されます。デバイスが組織のセキュリティ基準を満たさない場合（非準拠や未参加）、アクセスはブロックされます。準拠または信頼されたデバイスからのアクセスであれば、MFAの要否が判断され、要求されていればMFAを完了することでアクセスが許可されます。

設定手順

Microsoft Entra IDのConditional Accessポリシーは、Microsoft Entra管理センターのGUIまたはMicrosoft Graph APIを介して設定できます。ここでは、特定のクラウドアプリケーションへのアクセスを、準拠デバイスからのアクセスに限定し、かつMFAを要求するポリシーをGraph API（PowerShell）で設定する例を示します。

前提条件

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

  • Microsoft Graph PowerShell SDKがインストールされていること。

  • テナント内のユーザーがMFAを登録済みであること。

  • Microsoft Intuneでデバイスコンプライアンスポリシーが構成され、デバイスが準拠状態として報告されていること[1]。

PowerShellスクリプトによる設定例

この例では、”Sales App” というクラウドアプリケーションに対して、”Sales Group” のメンバーが準拠デバイスからのみアクセス可能とし、かつMFAを要求するポリシーを作成します。

# Graph APIへの接続（管理者権限で実行）

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

# 変数の定義

$policyName = "Sales App Access - Compliant Device & MFA"
$targetUsers = @("Sales Group ID") # 対象グループのオブジェクトIDを具体的に指定してください
$targetApplications = @("Sales App Application ID") # 対象クラウドアプリのオブジェクトIDを具体的に指定してください (例: SharePoint OnlineのIDなど)

# ポリシーの構成

$conditions = @{
    users = @{
        includeGroups = $targetUsers
    }
    applications = @{
        includeApplications = $targetApplications
    }
    devices = @{
        filter = @{
            mode = "include"
            rule = "device.isCompliant -eq true" # 準拠デバイスを要求
        }
    }
}

$grantControls = @{
    operator = "AND"
    builtInControls = @("mfa") # MFAを要求
}

$conditionalAccessPolicy = @{
    displayName = $policyName
    state = "enabled" # テスト中は "reportOnly" を推奨
    conditions = $conditions
    grantControls = $grantControls
}

# ポリシーの作成


# 実行前にstateを "reportOnly" に設定し、レポートで影響を確認することを強く推奨します。


# New-MgIdentityConditionalAccessPolicy -Body $conditionalAccessPolicy | Format-List

  • スクリプトの解説:

    • Connect-MgGraph: Microsoft Graph APIに接続します。Policy.ReadWrite.ConditionalAccessスコープが必要です。

    • $targetUsers, $targetApplications: 対象とするグループおよびアプリケーションのオブジェクトIDを具体的に指定します。Azure Portalで確認できます。

    • conditions.devices.filter.rule: この行が、デバイスが準拠デバイスであること(device.isCompliant -eq true)を条件としています[1]。

    • grantControls.builtInControls: ここで"mfa"を指定することで、多要素認証を要求します[4]。

    • state = "enabled": 新規ポリシー作成時は"reportOnly"（レポートのみモード）から開始し、影響範囲を評価した上で"enabled"に切り替えるのがベストプラクティスです。

運用と監視

Conditional Accessポリシーは一度設定したら終わりではありません。組織の変化に合わせて継続的に監視・調整が必要です。

可観測性

  • サインインログ: Microsoft Entra管理センターの「監視」セクションにある「サインインログ」で、CAポリシーの適用状況を詳細に確認できます。各サインインイベントには、どのCAポリシーが適用され、その結果どうなったか（アクセス許可、ブロック、MFA要求など）が記録されます[5]。

  • 監査ログ: CAポリシー自体の作成、変更、削除などの管理操作は「監査ログ」で確認できます。

  • Conditional Access Insights and reporting: CAポリシーの「レポートのみ」モードを使用すると、ポリシーが「有効」であった場合にどのような影響があったかをシミュレーションし、Azure Monitor Log Analyticsワークスペースで詳細なレポートを確認できます。これはポリシーを本番環境に展開する前のリスク評価に不可欠です。

SLAとDR

Microsoft Entra ID自体は、Microsoftが提供する高可用性サービスであり、一般的に99.9%または99.99%のSLAが設定されています。Conditional Accessもこのインフラストラクチャ上で動作するため、個別のSLAは明示されていませんが、Entra IDのSLAに準じると考えられます。災害復旧（DR）については、Entra IDは地理的に分散されたデータセンターにデプロイされており、自動的に可用性を確保します。CAポリシーの設定自体はEntra IDテナント内に保存されるため、別途バックアップの仕組みは不要ですが、変更履歴は監査ログで追跡可能です。

セキュリティ考慮事項

  • 緊急アクセスアカウントの除外: すべてのCAポリシーから、最低2つ以上の緊急アクセスアカウント（クラウドブレイクグラスアカウント）を除外することが必須です。これにより、ポリシー設定ミスやIDプロバイダーの障害時でも、管理者アクセスが完全に失われることを防ぎます。

  • ゼロトラスト原則の適用: CAは「決して信頼せず、常に検証する」というゼロトラストの原則を具現化します。ユーザーID、デバイスの状態、場所、サインインリスクといった複数のシグナルを組み合わせることで、アクセス要求の信頼性を高めます。

  • Microsoft Entra Identity Protectionとの連携: Microsoft Entra ID P2ライセンスに含まれるIdentity Protectionは、ユーザーリスクとサインインリスクを自動的に検出し、CAポリシーと連携してリスクベースのアクセス制御を可能にします。例えば、リスクレベルが高いサインインに対してMFAを強制したり、アクセスをブロックしたりできます[5]。

  • デバイスのリスク評価: Microsoft Defender for EndpointとIntuneを統合することで、デバイスのセキュリティ状態だけでなく、リアルタイムの脆弱性や脅威レベルに基づいてデバイスのリスクを評価し、CAポリシーでその情報を使用できます。

コストとライセンス

Conditional Accessを利用するには、ユーザーにMicrosoft Entra ID P1またはP2ライセンスが割り当てられている必要があります[6]。

  • Microsoft Entra ID P1: 条件付きアクセスの中核機能を提供します。

  • Microsoft Entra ID P2: P1の機能に加えて、Microsoft Entra Identity ProtectionによるリスクベースCAや、Privileged Identity Management（PIM）などの高度なIDガバナンス機能が含まれます。

  • Microsoft Intune: デバイスのコンプライアンス管理にはIntuneが必要であり、通常はMicrosoft 365 E3/E5ライセンスに含まれるか、単体で契約します。

コスト最適化:

  • ライセンスの適切な選択: 組織のセキュリティ要件に応じて、P1かP2かを選択します。高度なリスクベースCAが必要なければP1で十分な場合があります。

  • ユーザー範囲の最適化: CAポリシーの適用対象となるユーザー数に応じてライセンスコストが発生するため、不必要なユーザーにP1/P2ライセンスを割り当てないよう管理します。

  • 「レポートのみ」モードの活用: ポリシー展開前に影響を正確に把握することで、誤ったポリシーによる障害を回避し、運用コストを削減します。

落とし穴とベストプラクティス

  • 過剰なポリシーによるロックアウト: CAポリシーは強力であるため、安易に適用するとユーザーがロックアウトされる可能性があります。特に「すべてのユーザー」や「すべてのクラウドアプリ」に適用するポリシーは慎重に計画し、常に「レポートのみ」モードでテストしてください。

  • ポリシーの競合と評価順序: 複数のCAポリシーが適用される場合、その評価順序や競合により予期せぬ結果を招くことがあります。特に「ブロック」ポリシーは「許可」ポリシーよりも優先されるため、注意が必要です[5]。ポリシー数を最小限に保ち、明確な目的を持つように設計します。

  • MFAの登録とユーザー教育: MFAを要求するポリシーを展開する前に、ユーザーがMFAを適切に登録しているか確認し、登録を促す計画を立てます。MFAの仕組みや重要性についてユーザーに教育することも重要です。

  • デバイス登録とコンプライアンスの仕組み: デバイスベースのCAを導入する場合、Azure AD 参加、ハイブリッド Azure AD 参加、Azure AD 登録、Intuneによるコンプライアンスポリシーの適用といったデバイス登録と管理の仕組みを十分に理解し、正しく設定する必要があります。

  • 継続的な見直し: 組織のIT環境や脅威の状況は常に変化します。CAポリシーも定期的に見直し、最新のセキュリティ要件に合わせて更新することが不可欠です。

まとめ

Microsoft Entra IDのConditional Accessは、多要素認証とデバイスの状態を組み合わせることで、現代の脅威に対応する堅牢なアクセス制御を実現する基盤です。この機能は、Microsoft Entra ID P1/P2ライセンスで利用可能であり、Microsoft Intuneとの連携によりデバイスコンプライアンスをアクセス条件に組み込むことができます。

アーキテクチャ設計では、ユーザー、デバイス、アプリケーション、条件といったシグナルを考慮し、Mermaid図のようなフローで評価ロジックを可視化することが有効です。設定時には、Graph API（PowerShell）を活用したIaC的なアプローチも推奨されますが、必ず「レポートのみ」モードで十分なテストを実施し、緊急アクセスアカウントの除外を徹底してください。運用段階では、サインインログや監査ログを活用した監視が不可欠であり、定期的なポリシーの見直しを通じて、変化するビジネス要件とセキュリティ要件に対応していく必要があります。これらのベストプラクティスを遵守することで、組織はセキュリティを強化しつつ、ユーザーの利便性を損なわないアクセス環境を構築できるでしょう。

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

コメント

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