ゼロトラストにおけるデバイス信頼性の確立 - エンドポイント管理の基礎

ゼロトラストセキュリティでは、「誰が」アクセスしているかだけでなく、「何から」アクセスしているかも重要な検証ポイントです。正規のユーザーであっても、マルウェアに感染したデバイスや、セキュリティパッチが適用されていないデバイスからのアクセスは、組織に重大なリスクをもたらします。

本記事では、ゼロトラストにおけるデバイス信頼性の確立について以下の内容を解説します。

• デバイス信頼性評価の考え方とゼロトラストにおける位置づけ
• MDM（Mobile Device Management）とUEM（Unified Endpoint Management）の役割
• デバイス登録とコンプライアンスチェックの仕組み
• BYOD（Bring Your Own Device）環境でのセキュリティ対策
• EDR（Endpoint Detection and Response）とXDR（Extended Detection and Response）による脅威検知

この記事を読むことで、デバイス信頼性の重要性を理解し、エンドポイント管理の基本設計ができるようになります。

前提知識

本記事を理解するために、以下の知識があることを前提としています。

• ゼロトラストの基本原則を把握している
• 条件付きアクセスの概念を理解している
• 基本的なネットワークセキュリティの知識がある

ゼロトラストの基本原則についてはゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを、条件付きアクセスについては条件付きアクセスポリシーの設計と実装を先に読むことをお勧めします。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

1. デバイス信頼性がゼロトラストにおいて重要な理由を説明できる
2. MDMとUEMの違いと役割を理解できる
3. デバイスコンプライアンスポリシーの設計指針を策定できる
4. BYOD環境でのセキュリティ対策を検討できる
5. EDRとXDRの違いと脅威検知の仕組みを理解できる

なぜデバイス信頼性が重要なのか

ゼロトラストの7つの柱の中で、デバイスはアイデンティティに次いで重要な検証ポイントです。従来の境界型セキュリティでは、社内ネットワークに接続されたデバイスは暗黙的に信頼されていました。しかし、現代のIT環境では、この前提が成り立ちません。

デバイス起点の脅威

デバイスを起点とした脅威は多岐にわたります。

flowchart TB
    subgraph threats["デバイス起点の脅威"]
        A["マルウェア感染<br/>エンドポイントへの侵入"]
        B["脆弱性の悪用<br/>未パッチのOS/アプリ"]
        C["設定不備<br/>暗号化無効・弱いパスワード"]
        D["紛失・盗難<br/>物理的なデバイス喪失"]
        E["不正デバイス<br/>シャドーITの接続"]
    end
    
    subgraph impact["組織への影響"]
        F["データ漏洩"]
        G["ランサムウェア被害"]
        H["横展開攻撃"]
        I["コンプライアンス違反"]
    end
    
    A --> F
    A --> G
    B --> H
    C --> F
    D --> F
    E --> H
    E --> I

特に注目すべきは、正規ユーザーの認証情報が窃取された場合、攻撃者は「正規ユーザーとして」アクセスを試みます。このとき、アクセス元のデバイスの状態を検証することで、不正アクセスを検知できる可能性が高まります。

ゼロトラストにおけるデバイス検証の位置づけ

ゼロトラストでは、すべてのアクセス要求に対して「デバイスは信頼できるか」を継続的に検証します。

flowchart LR
    subgraph request["アクセス要求"]
        User["ユーザー"]
        Device["デバイス"]
        Network["ネットワーク"]
    end
    
    subgraph pdp["ポリシー決定ポイント"]
        IdVerify["アイデンティティ検証"]
        DevVerify["デバイス検証"]
        CtxVerify["コンテキスト検証"]
    end
    
    subgraph decision["アクセス判断"]
        Allow["許可"]
        Deny["拒否"]
        Limited["制限付き許可"]
    end
    
    User --> IdVerify
    Device --> DevVerify
    Network --> CtxVerify
    
    IdVerify --> decision
    DevVerify --> decision
    CtxVerify --> decision

デバイス検証では、以下の観点から信頼性を評価します。

MDMとUEMによるデバイス管理

デバイス信頼性を確立するためには、組織がデバイスを適切に管理する仕組みが必要です。この役割を担うのがMDMとUEMです。

MDM（Mobile Device Management）とは

MDMは、モバイルデバイス（スマートフォン、タブレット）を組織が一元管理するためのソリューションです。主に以下の機能を提供します。

• デバイスの登録と棚卸し
• セキュリティポリシーの配布と適用
• アプリケーションの配布と管理
• リモートワイプ（遠隔データ消去）
• 位置情報の追跡

flowchart TB
    subgraph org["組織"]
        Admin["IT管理者"]
        MDMServer["MDMサーバー"]
        Policy["セキュリティポリシー"]
    end
    
    subgraph devices["管理対象デバイス"]
        iOS["iPhone/iPad"]
        Android["Androidデバイス"]
    end
    
    Admin --> MDMServer
    Policy --> MDMServer
    MDMServer -->|"ポリシー配布<br/>アプリ配布<br/>構成プロファイル"| iOS
    MDMServer -->|"ポリシー配布<br/>アプリ配布<br/>構成プロファイル"| Android
    iOS -->|"コンプライアンス状態<br/>デバイス情報"| MDMServer
    Android -->|"コンプライアンス状態<br/>デバイス情報"| MDMServer

UEM（Unified Endpoint Management）とは

UEMは、MDMの概念を拡張し、モバイルデバイスだけでなく、PC、Mac、さらにはIoTデバイスまで含めたすべてのエンドポイントを統合管理するソリューションです。

Microsoft Intuneは代表的なUEMソリューションであり、以下のような機能を提供します。

ユーザーとデバイスの管理

• Android、iOS/iPadOS、Linux、macOS、Windowsデバイスの管理
• 組織所有デバイスと個人所有デバイス（BYOD）の両方に対応
• デバイス登録とコンプライアンスチェック

アプリケーション管理

• アプリの展開、更新、削除
• Microsoft 365アプリの配布
• Win32アプリとLOB（Line of Business）アプリの管理
• アプリ保護ポリシーによるデータ保護

ポリシーの自動展開

• セキュリティポリシー、デバイス構成、コンプライアンスポリシーの作成
• 条件付きアクセスとの連携
• ユーザーグループ・デバイスグループへの自動適用

脅威防御との統合

• Microsoft Defender for Endpointとの統合
• サードパーティMTD（Mobile Threat Defense）との連携
• リアルタイムのリスク分析と自動修復

MDMとUEMの使い分け

MDMとUEMは排他的な関係ではなく、UEMはMDMの上位概念として捉えることができます。

現代のゼロトラスト環境では、UEMを採用し、すべてのエンドポイントを統一的なポリシーで管理することが推奨されます。

デバイス登録とコンプライアンスチェック

UEMを活用したデバイス信頼性の確立において、中核となるのがデバイス登録とコンプライアンスチェックです。

デバイス登録の方式

組織がデバイスを管理下に置く方法は、デバイスの所有形態によって異なります。

flowchart TB
    subgraph corporate["組織所有デバイス"]
        AutoPilot["Windows Autopilot<br/>ゼロタッチ展開"]
        DEP["Apple DEP/ABM<br/>自動登録"]
        AndroidZT["Android Zero-touch<br/>自動登録"]
    end
    
    subgraph personal["個人所有デバイス（BYOD）"]
        UserEnroll["ユーザー登録<br/>Company Portal経由"]
        MAM["MAMのみ<br/>デバイス登録なし"]
    end
    
    subgraph result["管理レベル"]
        Full["フルデバイス管理<br/>MDM"]
        App["アプリ管理のみ<br/>MAM"]
    end
    
    AutoPilot --> Full
    DEP --> Full
    AndroidZT --> Full
    UserEnroll --> Full
    MAM --> App

組織所有デバイスの登録

組織が購入・支給するデバイスは、ゼロタッチ展開（Zero-touch Deployment）により、ユーザーの手を介さずに自動的にUEMに登録されます。

• Windows Autopilot: 新しいWindowsデバイスを開封してインターネットに接続するだけで、自動的にMicrosoft Entra IDに参加し、Intuneに登録されます
• Apple DEP/ABM: Apple Business Managerと連携し、iPhoneやMacを自動登録します
• Android Zero-touch: Android Enterprise対応デバイスを自動登録します

個人所有デバイス（BYOD）の登録

従業員が私物デバイスを業務に使用する場合、以下の選択肢があります。

1. デバイス登録（MDM）: Company Portalアプリ経由でデバイスを登録し、組織のポリシーを適用
2. アプリ保護のみ（MAM）: デバイス登録なしで、業務アプリ内のデータのみを保護

コンプライアンスポリシーの設計

デバイスが組織のセキュリティ要件を満たしているかを評価するのがコンプライアンスポリシーです。以下は、一般的なコンプライアンス要件の例です。

Windowsデバイスのコンプライアンス要件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# コンプライアンスポリシーの例（概念的な構成）
platform: Windows
requirements:
  os_version:
    minimum: "10.0.19045"  # Windows 10 22H2以上
  security:
    bitlocker_required: true
    secure_boot_required: true
    code_integrity_required: true
    tpm_required: true
    tpm_version_minimum: "2.0"
  password:
    required: true
    minimum_length: 12
    complexity: true
  defender:
    antivirus_enabled: true
    real_time_protection: true
    definitions_up_to_date: true
  firewall:
    enabled: true

iOS/iPadOSデバイスのコンプライアンス要件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

platform: iOS
requirements:
  os_version:
    minimum: "17.0"
  device_health:
    jailbroken: false  # 脱獄禁止
  passcode:
    required: true
    minimum_length: 6
    simple_passwords: false
  encryption:
    required: true  # iOSはデフォルトで暗号化

コンプライアンス状態と条件付きアクセスの連携

コンプライアンスチェックの真価は、条件付きアクセスと連携したときに発揮されます。デバイスがコンプライアンスに準拠していない場合、リソースへのアクセスを制限できます。

sequenceDiagram
    participant User as ユーザー
    participant Device as デバイス
    participant Intune as Microsoft Intune
    participant EntraID as Microsoft Entra ID
    participant App as 業務アプリ
    
    User->>Device: アプリにアクセス
    Device->>EntraID: 認証要求
    EntraID->>EntraID: ユーザー認証
    EntraID->>Intune: デバイスコンプライアンス確認
    
    alt コンプライアンス準拠
        Intune-->>EntraID: 準拠
        EntraID-->>Device: アクセストークン発行
        Device->>App: アクセス許可
    else コンプライアンス非準拠
        Intune-->>EntraID: 非準拠
        EntraID-->>Device: アクセス拒否
        Device->>User: 修復手順を表示
    end

非準拠デバイスに対しては、以下のようなアクションを設定できます。

1. アクセス拒否: 企業リソースへのアクセスを完全にブロック
2. 制限付きアクセス: 一部のリソースのみアクセス許可
3. 通知: ユーザーに修復を促すメール送信
4. 猶予期間: 一定期間内に修復すればアクセス継続

BYOD環境でのセキュリティ対策

BYOD（Bring Your Own Device）は、従業員の利便性と生産性を高める一方で、セキュリティ上の課題をもたらします。ゼロトラストの観点からBYODセキュリティを設計する方法を解説します。

BYODのリスクと対策

flowchart LR
    subgraph risks["BYODのリスク"]
        R1["データ漏洩<br/>個人アプリへのコピー"]
        R2["マルウェア感染<br/>管理外アプリ経由"]
        R3["デバイス紛失<br/>業務データ流出"]
        R4["可視性の欠如<br/>シャドーIT化"]
    end
    
    subgraph controls["対策"]
        C1["MAMポリシー<br/>アプリ間データ分離"]
        C2["MTD連携<br/>脅威検知"]
        C3["選択的ワイプ<br/>業務データのみ削除"]
        C4["条件付きアクセス<br/>登録デバイスのみ許可"]
    end
    
    R1 --> C1
    R2 --> C2
    R3 --> C3
    R4 --> C4

MAM（Mobile Application Management）によるアプリレベル保護

BYODデバイスでは、デバイス全体を管理するMDMではなく、業務アプリのみを保護するMAMが有効です。Microsoft Intuneのアプリ保護ポリシーでは、以下のような制御が可能です。

データ保護の設定例

アクセス要件の設定例

組織所有とBYODの統合管理戦略

組織所有デバイスとBYODを統合的に管理するには、デバイスの所有形態に応じた段階的なアクセスレベルを設計します。

flowchart TB
    subgraph tier1["Tier 1: フルアクセス"]
        Corp["組織所有デバイス<br/>MDM登録・コンプライアンス準拠"]
    end
    
    subgraph tier2["Tier 2: 標準アクセス"]
        BYOD_MDM["BYODデバイス<br/>MDM登録・コンプライアンス準拠"]
    end
    
    subgraph tier3["Tier 3: 制限付きアクセス"]
        BYOD_MAM["BYODデバイス<br/>MAMのみ"]
    end
    
    subgraph tier4["Tier 4: Webのみ"]
        Unmanaged["未管理デバイス<br/>ブラウザアクセスのみ"]
    end
    
    subgraph resources["アクセス可能リソース"]
        All["すべての業務リソース"]
        Standard["一般業務リソース"]
        Limited["メール・カレンダー"]
        WebOnly["Web版Office・ポータル"]
    end
    
    Corp --> All
    BYOD_MDM --> Standard
    BYOD_MAM --> Limited
    Unmanaged --> WebOnly

この段階的アプローチにより、デバイスの信頼性レベルに応じた適切なアクセス制御を実現できます。

EDRとXDRによる脅威検知と対応

デバイスコンプライアンスだけでは、高度な脅威からの保護は十分ではありません。EDR（Endpoint Detection and Response）とXDR（Extended Detection and Response）により、エンドポイントにおける脅威を検知・対応する仕組みが必要です。

EDR（Endpoint Detection and Response）とは

EDRは、エンドポイントを継続的に監視し、脅威の兆候を検知して自動的に対応するセキュリティ技術です。従来のアンチウイルスが既知のマルウェアをシグネチャベースで検知するのに対し、EDRは行動分析により未知の脅威も検知できます。

EDRの主要機能

flowchart LR
    subgraph monitor["継続的監視"]
        A["プロセス実行"]
        B["ファイル操作"]
        C["ネットワーク接続"]
        D["レジストリ変更"]
    end
    
    subgraph analyze["分析・検知"]
        E["行動分析<br/>AI/ML"]
        F["IoC照合<br/>脅威インテリジェンス"]
        G["相関分析"]
    end
    
    subgraph respond["対応"]
        H["アラート生成"]
        I["自動隔離"]
        J["プロセス停止"]
        K["フォレンジックデータ保存"]
    end
    
    A --> E
    B --> E
    C --> E
    D --> E
    E --> F
    F --> G
    G --> H
    G --> I
    G --> J
    G --> K

EDRが検知する脅威の例

• ランサムウェアによる大量ファイル暗号化
• 不審なPowerShellスクリプトの実行
• メモリ内での悪意あるコード実行（ファイルレス攻撃）
• クレデンシャルダンプの試行
• 横展開（Lateral Movement）の兆候

XDR（Extended Detection and Response）とは

XDRは、EDRの概念をエンドポイント以外にも拡張し、ネットワーク、クラウド、メール、アイデンティティなど複数のセキュリティドメインを統合的に監視・対応するプラットフォームです。

flowchart TB
    subgraph sources["データソース"]
        Endpoint["エンドポイント<br/>EDR"]
        Network["ネットワーク<br/>NDR"]
        Cloud["クラウドワークロード"]
        Email["メール"]
        Identity["アイデンティティ"]
    end
    
    subgraph xdr["XDRプラットフォーム"]
        Ingest["データ収集・統合"]
        Correlate["相関分析<br/>インシデント生成"]
        Detect["AI駆動の脅威検知"]
        Respond["自動対応<br/>攻撃の遮断"]
    end
    
    subgraph output["出力"]
        Alert["統合アラート"]
        Incident["インシデント<br/>攻撃チェーン可視化"]
        Action["自動修復"]
    end
    
    Endpoint --> Ingest
    Network --> Ingest
    Cloud --> Ingest
    Email --> Ingest
    Identity --> Ingest
    
    Ingest --> Correlate
    Correlate --> Detect
    Detect --> Respond
    
    Respond --> Alert
    Respond --> Incident
    Respond --> Action

XDRの主な利点

EDRとXDRの使い分け

ゼロトラスト環境では、XDRを採用することで、デバイスだけでなくアイデンティティやネットワークを含めた包括的な脅威検知・対応が可能になります。

デバイス信頼性と脅威スコアの連携

EDR/XDRで検知された脅威情報は、デバイスの信頼性評価に反映されます。Microsoft Defender for Endpointでは、デバイスごとにリスクレベルが算出され、条件付きアクセスと連携できます。

sequenceDiagram
    participant Device as デバイス
    participant Defender as Microsoft Defender<br/>for Endpoint
    participant Intune as Microsoft Intune
    participant EntraID as Microsoft Entra ID
    participant App as 業務アプリ
    
    Device->>Defender: テレメトリデータ送信
    Defender->>Defender: 脅威検知・リスク評価
    Defender->>Intune: リスクレベル連携
    Intune->>Intune: コンプライアンス評価に反映
    
    Note over Device,App: ユーザーがアプリにアクセス
    
    Device->>EntraID: 認証要求
    EntraID->>Intune: コンプライアンス確認
    
    alt リスクレベル: 低
        Intune-->>EntraID: 準拠
        EntraID-->>Device: アクセス許可
    else リスクレベル: 中〜高
        Intune-->>EntraID: 非準拠
        EntraID-->>Device: アクセス拒否
        Defender->>Device: 脅威の修復を促すアラート
    end

この連携により、マルウェアに感染したデバイスからのアクセスを自動的にブロックし、脅威が修復されるまでアクセスを制限できます。

デバイス信頼性確立のベストプラクティス

ゼロトラストにおけるデバイス信頼性を確立するためのベストプラクティスをまとめます。

段階的な導入アプローチ

デバイス管理の導入は、一度にすべてを実施するのではなく、段階的に進めることを推奨します。

フェーズ1: 可視化と基盤構築

• UEMソリューション（Microsoft Intuneなど）の導入
• 既存デバイスの棚卸しと登録
• 基本的なコンプライアンスポリシーの策定

フェーズ2: ポリシー適用

• コンプライアンスポリシーの展開
• 条件付きアクセスとの連携開始
• BYODポリシーの策定とMAM導入

フェーズ3: 脅威検知と対応

• EDR/XDRの導入
• リスクベースの条件付きアクセス設定
• 自動修復ワークフローの構築

フェーズ4: 継続的な改善

• コンプライアンスレポートの分析
• ポリシーの最適化
• 新たな脅威への対応

コンプライアンスポリシー設計のポイント

コンプライアンスポリシーを設計する際は、以下のポイントを考慮します。

1. ビジネス要件との整合: 厳しすぎるポリシーはユーザーの生産性を低下させます。リスクとのバランスを取りましょう
2. プラットフォーム間の一貫性: Windows、macOS、iOS、Androidで可能な限り同等のセキュリティレベルを維持します
3. 猶予期間の設定: 非準拠時に即座にブロックするのではなく、修復のための猶予期間を設けます
4. ユーザーへの通知: 非準拠の理由と修復手順を明確に伝えるメカニズムを用意します
5. 例外処理の定義: 特殊なデバイスや一時的な例外に対応する手順を定めます

モニタリングと継続的改善

デバイス管理は導入して終わりではなく、継続的なモニタリングと改善が必要です。

flowchart LR
    subgraph monitor["モニタリング"]
        A["コンプライアンス準拠率"]
        B["脅威検知件数"]
        C["インシデント対応時間"]
        D["登録デバイス数"]
    end
    
    subgraph analyze["分析"]
        E["傾向分析"]
        F["根本原因分析"]
        G["ベンチマーク比較"]
    end
    
    subgraph improve["改善"]
        H["ポリシー調整"]
        I["ユーザー教育"]
        J["プロセス最適化"]
    end
    
    A --> E
    B --> E
    C --> F
    D --> G
    E --> H
    F --> I
    G --> J
    H --> A
    I --> B
    J --> C

まとめ

ゼロトラストセキュリティにおいて、デバイス信頼性の確立は、アイデンティティ検証と並ぶ重要な柱です。本記事で解説した内容を振り返ります。

デバイス信頼性の重要性

• 正規ユーザーであっても、侵害されたデバイスからのアクセスはリスクとなる
• デバイスの登録状態、コンプライアンス、健全性、構成を継続的に検証する

MDM/UEMによるデバイス管理

• UEMですべてのエンドポイントを統合管理
• デバイス登録とコンプライアンスチェックにより信頼性を確立
• 条件付きアクセスとの連携でアクセス制御を実現

BYOD対応

• MAMによるアプリレベルの保護でプライバシーとセキュリティを両立
• デバイスの所有形態に応じた段階的なアクセスレベル設計

EDR/XDRによる脅威検知

• EDRでエンドポイントの脅威を検知・対応
• XDRで複数ドメインを統合した包括的なセキュリティ運用
• 脅威スコアと条件付きアクセスの連携で動的なアクセス制御

次の記事では、ネットワークセキュリティの観点から、マイクロセグメンテーションとZTNA（ゼロトラストネットワークアクセス）について解説します。

参考リンク

• Microsoft Intune とは - Microsoft Learn
• Microsoft Intune のデバイスコンプライアンスポリシー - Microsoft Learn
• Microsoft Defender for Endpoint - Microsoft Learn
• XDR（Extended Detection and Response）とは - Microsoft Security
• EDR（Endpoint Detection and Response）とは - Microsoft Security
• NIST SP 800-207 Zero Trust Architecture
• CISA Zero Trust Maturity Model