Entra ID条件付きアクセス: デバイスコンプライアンスとMFAによるゼロトラストアプローチ

Tech

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

Entra ID条件付きアクセス: デバイスコンプライアンスとMFAによるゼロトラストアプローチ

はじめに

現代の企業環境では、従業員が多様なデバイスから様々な場所に存在するクラウドアプリケーションにアクセスするため、従来のネットワーク境界型セキュリティモデルでは不十分です。この課題に対応するため、「ゼロトラスト」セキュリティモデルが注目されています。ゼロトラストの核となるのは「決して信頼せず、常に検証する」という原則であり、その実現にはアイデンティティとデバイスの検証が不可欠です。 、Microsoft Entra ID（旧Azure Active Directory）の条件付きアクセス（Conditional Access）を活用し、デバイスコンプライアンスと多要素認証（MFA）を組み合わせることで、強固なゼロトラスト環境を構築する方法について、クラウドアーキテクトの視点から解説します。

アーキテクチャ

Entra ID条件付きアクセス、デバイスコンプライアンス、MFAを組み合わせたアーキテクチャは、ユーザー、デバイス、アプリケーション、そしてアクセス制御のポリシーエンジンが連携する形で構成されます。

  1. ユーザー: Microsoft Entra IDに登録されたアイデンティティ。

  2. デバイス: ユーザーが認証に利用するデバイス（PC、スマートフォン、タブレットなど）。これらのデバイスはMicrosoft Intuneによって管理され、組織のセキュリティポリシーに準拠しているか評価されます。

  3. Microsoft Entra ID: アイデンティティプロバイダーであり、認証サービスを提供します。また、条件付きアクセスがここで評価されます。

  4. Microsoft Intune: モバイルデバイス管理 (MDM) およびモバイルアプリケーション管理 (MAM) サービス。デバイスの登録、構成、コンプライアンス評価を担います。

  5. 条件付きアクセス: Entra IDの機能であり、特定の条件（ユーザー、アプリケーション、デバイス状態、場所、サインインリスクなど）に基づいて、アクセスを許可、ブロック、または追加の制御（MFAの強制、準拠デバイスの要求など）を適用するポリシーエンジンです。

  6. クラウドアプリケーション: ユーザーがアクセスしようとするSaaSアプリケーションやカスタムアプリケーション。

このアーキテクチャでは、ユーザーがクラウドアプリケーションへのアクセスを試みると、まずEntra IDが認証リクエストを受け取ります。その後、条件付きアクセスが構成されたポリシーを評価し、以下を順次検証します。

  • ユーザーがポリシーの対象か？

  • デバイスがIntuneによって管理され、組織のセキュリティポリシーに「準拠済み」とマークされているか？

  • 要求されたアクセスに対してMFAが必要か？

これら全ての条件が満たされた場合にのみ、ユーザーはアプリケーションへのアクセスを許可されます。

以下に、認証フローと条件付きアクセスの評価プロセスを示すMermaidフローチャートを記載します。

graph TD
    A["ユーザー"] --> B("認証リクエスト");
    B --> C["Microsoft Entra ID"];
    C --> D{"条件付きアクセス ポリシー評価"};
    D -- |ユーザー,アプリ,場所,リスクなどの条件に合致| --> E{"付与制御評価"};
    E -- |「多要素認証を必須とする」| --> F["MFA実行"];
    E -- |「準拠済みデバイスを必須とする」| --> G["デバイス状態の確認 (Intune連携)"];
    F -- |MFA成功| --> H{"すべての付与制御を満たすか?"};
    G -- |デバイス準拠済み| --> H;
    H -- |はい| --> I["アクセス許可"];
    H -- |いいえ (MFA失敗 または デバイス非準拠)| --> J["アクセス拒否"];
    D -- |条件に合致しない| --> I;

設定手順

Entra ID条件付きアクセスでデバイスコンプライアンスとMFAを適用するには、以下のステップが必要です。

1. ライセンスの確認

  • Microsoft Entra ID P1 または P2: 条件付きアクセス機能を利用するために必須です。

  • Microsoft Intune: デバイスコンプライアンスポリシーの作成と適用、デバイスの登録と管理のために必須です。 これらのライセンスは通常、Microsoft 365 E3/E5やEnterprise Mobility + Security (EMS) E3/E5サブスクリプションに含まれます[2]。

2. Microsoft Intuneでのデバイスコンプライアンスポリシーの作成

Intuneで、組織のセキュリティ要件に合わせたデバイスコンプライアンスポリシーを作成します。 例:

  • OSの最小/最大バージョン

  • ディスク暗号化の必須化

  • パスワード/PINの複雑性と有効期限

  • Microsoft Defender for Endpointとの連携による脅威レベルの評価

# Intune デバイスコンプライアンスポリシー作成 (概念的なGraph API Betaエンドポイントとボディ例)


# 実際の実装は、特定のコンプライアンス設定（パスワード要件、OSバージョンなど）によって複雑になります。


# 以下の例は概念的なものであり、具体的なポリシー設定はIntuneのドキュメントを参照してください。


# APIドキュメント: https://learn.microsoft.com/ja-jp/graph/api/intune-deviceconfig-devicecompliancepolicy-create

# 注意: Graph API Betaエンドポイントを使用する場合、本番環境での利用には十分な検証が必要です。

# 変数の設定（環境に合わせて変更）


# $tenantId = "YOUR_TENANT_ID"


# $appId = "YOUR_APPLICATION_ID" # Graph APIにアクセスするためのアプリケーションID


# $appSecret = "YOUR_CLIENT_SECRET" # アプリケーションシークレット (または証明書認証)

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


# $body = @{


#     grant_type    = "client_credentials"


#     client_id     = $appId


#     client_secret = $appSecret


#     scope         = "https://graph.microsoft.com/.default"


# }


# $tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Method Post -Body $body


# $accessToken = $tokenResponse.access_token

# デバイスコンプライアンスポリシーのJSONボディ例 (Windowsの場合)


# この例は非常に単純化されており、実際のポリシーは多くの設定を含みます。


# 例えば、passwordRequired, osMinimumVersion, securityFeatures.firewallEnabledなど。


# 実際のポリシータイプは、platform (Windows, iOS, Androidなど) に応じて異なります。

$policyJson = @'
{
  "@odata.type": "#microsoft.graph.windows10CompliancePolicy",
  "displayName": "Windows Corporate Device Compliance Policy",
  "description": "企業用Windowsデバイスは最低限のセキュリティ基準を満たす必要があります。",
  "passwordRequired": true,
  "passwordMinimumLength": 8,
  "osMinimumVersion": "10.0.19041",
  "deviceThreatProtectionRequired": true,
  "deviceThreatProtectionMinimumLevel": "secured",
  "firewallEnabled": true,
  "storageRequireEncryption": true
}
'@ | ConvertTo-Json -Depth 10 # ConvertTo-Jsonで適切にエスケープ

# ポリシーの作成 (Graph API v1.0 エンドポイント)


# $headers = @{


#     "Authorization" = "Bearer $accessToken"


#     "Content-Type"  = "application/json"


# }


# try {


#     $result = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies" -Method Post -Headers $headers -Body $policyJson


#     Write-Host "Intuneデバイスコンプライアンスポリシーが作成されました: $($result.displayName)"


# }


# catch {


#     Write-Error "Intuneポリシー作成中にエラーが発生しました: $($_.Exception.Message)"


#     Write-Error "詳細: $($_.ErrorDetails.ToString())"


# }

3. Microsoft Entra IDでの条件付きアクセス ポリシーの作成

Azureポータルから条件付きアクセス ポリシーを作成します。

  1. ポリシー名: 例: RequireMFA_and_CompliantDevice_for_CloudApps

  2. ユーザーとグループ:

    • 含める: 全てのユーザー、または特定のユーザー/グループ。

    • 除外する: 緊急アクセスカウント（ブレークグラスアカウント）など、ポリシーの適用外とするアカウントを必ず設定します。

  3. クラウドアプリまたはアクション:

    • 含める: 全てのクラウドアプリ、または特定のアプリケーション。

  4. 条件:

    • デバイスの状態:

      • 構成: はい

      • 含める: すべてのデバイス

      • 除外する: 準拠済みとしてマークされているデバイス (これを選択すると、非準拠デバイスからのアクセスがブロックされます)。

      • または、「含める」で「準拠済みとしてマークされているデバイス」のみを選択し、非準拠を自動的にブロックする構成も可能。

  5. 付与:

    • アクセス権の付与: アクセスを許可する を選択。

    • 以下の制御をチェック:

      • 多要素認証を必須とする

      • 準拠済みデバイスを必須とする

    • 次の選ばれた制御をすべて要求する を選択。

  6. セッション:

    • 必要に応じて、セッション制御（MFAのサインイン頻度、永続的なブラウザセッションなど）を構成します。

  7. ポリシーを有効にする:

    • レポート専用 モードで開始し、影響を評価した後に オン に切り替えることを強く推奨します。
# 条件付きアクセス ポリシー作成 (概念的なGraph API Betaエンドポイントとボディ例)


# APIドキュメント: https://learn.microsoft.com/ja-jp/graph/api/conditionalaccesspolicy-post-policies?view=graph-rest-beta


# 注意: 条件付きアクセスAPIは現在betaエンドポイントでのみ利用可能です。本番環境での利用には十分な検証が必要です。

# # アクセストークンはIntuneポリシー作成と同じものを使用できます（適切な権限があれば）

# 条件付きアクセス ポリシーのJSONボディ例


# このポリシーは「すべてのユーザーが、承認済みクラウドアプリに、準拠済みデバイスからアクセスする場合、MFAを必須とする」設定を示しています。


# 'state' は enabled, disabled, enabledForReportingButBlocked (レポート専用モード) のいずれかを指定します。

$caPolicyJson = @'
{
  "displayName": "CA_RequireMFAAndCompliantDevice_AllUsers_AllApps",
  "state": "enabledForReportingButBlocked", 
  "conditions": {
    "users": {
      "includeUsers": [ "All" ],
      "excludeUsers": [
        "e5860d62-671c-43dd-9244-63852077976e" # 緊急アクセスカウントのユーザーIDなど
      ]
    },
    "applications": {
      "includeApplications": [ "All" ],
      "excludeApplications": []
    },
    "clientAppTypes": [ "all" ],
    "platforms": {
      "includePlatforms": [ "all" ],
      "excludePlatforms": []
    },
    "devices": {
        "includeStates": [ "compliant" ] # 準拠デバイスのみを対象とする
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": [ "mfa", "compliantDevice" ] # MFAと準拠デバイスを必須とする
  }
}
'@ | ConvertTo-Json -Depth 10

# ポリシーの作成 (Graph API Betaエンドポイント)


# $headers = @{


#     "Authorization" = "Bearer $accessToken"


#     "Content-Type"  = "application/json"


# }


# try {


#     $result = Invoke-RestMethod -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies" -Method Post -Headers $headers -Body $caPolicyJson


#     Write-Host "条件付きアクセス ポリシーが作成されました: $($result.displayName)"


# }


# catch {


#     Write-Error "条件付きアクセス ポリシー作成中にエラーが発生しました: $($_.Exception.Message)"


#     Write-Error "詳細: $($_.ErrorDetails.ToString())"


# }

運用監視

Entra ID条件付きアクセスとデバイスコンプライアンスの運用監視は、ポリシーの効果とユーザーエクスペリエンスの維持に不可欠です。

  • サインインログ: Entra IDのサインインログでは、各サインイン試行に対してどの条件付きアクセス ポリシーが適用され、結果がどうなったかを確認できます。これにより、意図しないブロックやアクセス許可を特定できます。

  • 監査ログ: 条件付きアクセス ポリシーの作成、変更、削除などの管理操作は監査ログに記録され、変更履歴を追跡できます。

  • レポート専用モード: ポリシーを本番環境に適用する前に、レポート専用モードで数週間から数ヶ月間運用し、その影響を詳細に分析することが非常に重要です。これにより、予期せぬアクセス拒否を防ぎ、影響を受けるユーザーを特定できます[3]。

  • Microsoft Sentinel / Log Analytics: Entra IDのログをMicrosoft SentinelやAzure Monitor Log Analyticsに統合することで、高度な脅威検出、カスタムアラート、ダッシュボードによる可視化が可能になります。

  • SLA: Microsoft Entra ID P1/P2のSLAは99.9%であり、基盤サービスの可用性はMicrosoftが保証します[1]。Intuneについても同様の可用性が期待できます。

  • バックアップ/DR: Entra IDの構成データ（ユーザー、グループ、ポリシーなど）はMicrosoftによって複数地域に冗長化され、バックアップが自動的に行われます。テナント管理者としては、条件付きアクセス ポリシーの定義やカスタムロール定義などをIaC (Infrastructure as Code) としてバージョン管理し、外部に保存することで、設定の誤操作からの復旧やディザスタリカバリ戦略の一部とすることができます。

セキュリティ

デバイスコンプライアンスとMFAを組み合わせた条件付きアクセスは、ゼロトラストセキュリティモデルの基盤を強化します。

  • ゼロトラスト原則の適用: 「明示的に検証する」「最小特権アクセスを使用する」「侵害を想定する」というゼロトラストの3原則を、アイデンティティとデバイスのレベルで具体的に適用します。

  • 多層防御の実現: ユーザー認証（MFA）とデバイス状態（コンプライアンス）という異なるセキュリティレイヤーで検証を行うことで、単一のセキュリティメカニズムが破られた場合でも、次の層で防御する多層防御が実現されます。

  • Identity Protectionとの連携: Entra ID Identity Protectionは、サインインリスクとユーザーリスクを検出します。これらのリスクレベルは条件付きアクセスの条件として利用でき、「高リスクのサインイン時にはMFAを必須とする」「ユーザーリスクが高い場合はパスワードリセットを強制する」といった自動化されたポリシーを適用できます。

  • Defender for Endpoint / Cloudとの連携: Microsoft Defender for Endpointによって収集されたデバイスのセキュリティ状態（脅威レベル）は、Intuneを介してデバイスコンプライアンス評価に利用できます。これにより、より詳細でリアルタイムなデバイスの健全性に基づいたアクセス制御が可能になります。

  • 継続的な評価と改善: 脅威の状況は常に変化します。定期的に条件付きアクセス ポリシーとデバイスコンプライアンスポリシーを見直し、現在のセキュリティ要件とビジネスニーズに合致しているか評価し、改善を続けることが重要です。

コスト

条件付きアクセス、デバイスコンプライアンス、MFAの導入には、Microsoft Entra IDとMicrosoft Intuneのライセンス費用が発生します。

  • Microsoft Entra ID P1 / P2:

    • P1: 条件付きアクセス、MFA、セルフサービスパスワードリセットなどが含まれます。

    • P2: P1の機能に加えて、Identity ProtectionやPrivileged Identity Management (PIM) などの高度なアイデンティティ管理機能が含まれます。

  • Microsoft Intune: デバイスの登録、コンプライアンスポリシーの適用、アプリケーション管理などの機能を提供します。 これらのライセンスは、通常、Microsoft 365 E3/E5やEnterprise Mobility + Security E3/E5といった統合されたサブスクリプションプランの一部として提供されます。個別に購入することも可能ですが、統合プランの方がコスト効率が良い場合が多いです。

コスト最適化

  • 適切なライセンスの選択: 必要な機能とユーザー数に基づいて、適切なEntra IDおよびIntuneのライセンスプランを選択します。全てのユーザーにP2ライセンスが必要とは限りません。

  • グループベースのポリシー適用: 全てのユーザーに全てのポリシーを適用するのではなく、特定のグループ（例: 役員、開発者）にのみ高度なセキュリティポリシーを適用することで、ライセンスコストを最適化できます。

  • レポート専用モードの活用: ポリシー導入前にレポート専用モードで影響を評価することで、不必要なライセンス追加や、誤ったポリシーによるビジネス影響を未然に防ぎ、コストのかかる修正作業を削減できます。

落とし穴

強力なセキュリティ機能である条件付きアクセスですが、設計や実装を誤ると、ユーザーの生産性を著しく阻害したり、管理者がシステムからロックアウトされるなどの重大な問題を引き起こす可能性があります。

  • ポリシー設計の複雑性: ポリシーが多すぎると、相互に競合したり、意図しないアクセスブロックが発生したりする可能性があります。シンプルかつ明確なポリシー設計を心がけ、最小限のポリシーで最大限の効果を得ることを目指しましょう。

  • レポート専用モードの軽視: 本番環境に適用する前にレポート専用モードで十分にテストしないと、予期せぬユーザーへの影響が発生します。少なくとも数週間はレポート専用モードで運用し、サインインログを確認して影響を分析することが不可欠です[3]。

  • ユーザーエクスペリエンスとのバランス: MFAの頻度やデバイス登録の手順が複雑すぎると、ユーザーの生産性が低下したり、セキュリティ対策を回避しようとする行動を誘発したりする可能性があります。セキュリティとユーザビリティのバランスを見極めることが重要です。

  • デバイス登録状態の確認: 準拠済みデバイスを必須とするポリシーでは、デバイスがIntuneに正しく登録され、「準拠済み」とマークされていることが前提となります。Hybrid Azure AD JoinやAzure AD Joinの構成ミス、あるいはデバイスの登録漏れがないかを確認する必要があります。

  • 緊急アクセスカウントの確保: 管理者アカウントが条件付きアクセス ポリシーによってロックアウトされる事態を避けるため、少なくとも2つ以上の緊急アクセスアカウント（ブレークグラスアカウント）をポリシーから除外しておくことが推奨されます。これらのアカウントは厳重に管理し、通常の運用には使用しないようにします。

まとめ

Microsoft Entra IDの条件付きアクセスとデバイスコンプライアンス、MFAの組み合わせは、今日のクラウド環境におけるゼロトラストセキュリティモデルの構築に不可欠な要素です。ユーザーのアイデンティティとデバイスの状態を常に検証することで、リスクベースのインテリジェントなアクセス制御を実現し、組織のリソースを保護します。

この強固なセキュリティフレームワークを効果的に導入するためには、綿密な計画、適切なライセンスの選択、そしてレポート専用モードを活用した徹底的なテストが不可欠です。本記事で解説したアーキテクチャ、設定手順、運用監視、セキュリティ、コスト、そして落とし穴への理解を深めることで、より安全で効率的なクラウド環境の実現に貢献できるでしょう。

[1] Microsoft Learn. 「Azure のサービス レベル アグリーメント (SLA)」。最終更新: 2024年5月14日 JST。 [2] Microsoft Learn. 「Microsoft Entra のライセンス要件」。最終更新: 2024年5月14日 JST。 [3] Microsoft Learn. 「条件付きアクセス ポリシーのレポート専用モードとは」。最終更新: 2024年5月14日 JST。

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

コメント

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