クラウドセキュリティの中でも注目されるゼロトラストセキュリティモデルの実装において、デバイスの信頼性検証は最重要な要素です。すべてのデバイスが「安全である」と自動的に信頼されるのではなく、継続的に検証されるべきという原則が、ゼロトラストの根本的な考え方です。本記事では、デバイスの信頼性をどのように検証し、リスクベースのアクセス制御をどのように実装するかについて、詳しく解説します。
デバイス信頼性の検証方法
デバイスコンプライアンスチェックの基礎
ゼロトラストモデルでは、デバイスがセキュリティ基準を満たしているかを継続的に検証します。これは、デバイスが企業ネットワークに接続する際の初期認証だけでなく、接続中の継続的な監視も含みます。
デバイスコンプライアンスの主要チェック項目：
- OS更新状況 - 最新のセキュリティパッチが適用されているか
- セキュリティソフトの状態 - ウイルス対策ソフトが有効で、定義ファイルが最新か
- ファイアウォール - デバイスレベルのファイアウォールが有効か
- 暗号化 - ディスク全体の暗号化（BitLockerまたはFileVault）が有効か
- スクリーンロック - 自動ロック設定が有効か
- データ保護設定 - 企業データをデバイスにキャッシュしないよう設定されているか
2024年のセキュリティ調査では、企業管理下のデバイスであっても、平均的に25～35%がこれらの基本的なコンプライアンス要件を満たしていない状態で稼働しており、これが企業侵害の重大なリスク要因となっています。
リアルタイムヘルスチェック機能
デバイスコンプライアンスの検証は、一度の認証で終わるのではなく、継続的に実施される必要があります。多くのゼロトラストソリューションは、以下のようなリアルタイムヘルスチェック機能を提供しています。
継続的監視の要素：
- 定期的なチェック実行 - 15分～1時間ごとにデバイス状態を検証
- コンプライアンス要件の更新 - セキュリティ脅威の変化に応じて検証項目を動的に変更
- 非準拠検出時のアクション - ポリシー違反検出時に自動的にアクセス制限を実施
実装企業の事例では、リアルタイムヘルスチェック導入により、パッチ未適用デバイスの検出を平均3日から数時間に短縮し、セキュリティインシデント予防率を45%向上させています。
デバイス識別と追跡
デバイスの信頼性を検証するには、まずデバイスが何かを一意に識別する必要があります。これは従来のネットワークアプローチとは異なり、より詳細な識別を必要とします。
デバイス識別の手法：
-
ハードウェアベース識別
- UUID（Universally Unique Identifier）
- MAC アドレス
- SN（シリアルナンバー）
-
ソフトウェアベース識別
- クライアント証明書
- デバイスID（Windows Deviceid等）
- MDM/EMM登録ID
-
機械学習ベース識別
- デバイスの振る舞いパターン
- ネットワーク通信パターン
- アプリケーション使用パターン
多数のデバイスが利用される環境では、複数の識別方法を組み合わせることが重要です。
ゼロトラスト実装の現実
ゼロトラストの理想と現実のギャップを分析。段階的な実装アプローチと、ID管理・デバイス管理から始める現実的なロードマップを提示します。
エンドポイント検証の技術
証明書ベース認証
デバイスの真正性を確認するための最も確実な方法は、デバイス証明書の使用です。PKI（Public Key Infrastructure）基盤により、デバイスは一意のデジタル証明書を持ち、これにより身元を証明します。
証明書ベース認証の実装：
- デバイス証明書の自動展開 - 企業管理下のデバイス全台に証明書を配布
- 証明書のライフサイクル管理 - 有効期限前の更新、失効時の処理
- 証明書ピンニング - 特定のサーバーとの通信では指定された証明書のみを受け入れ
- クライアント証明書認証 - VPN、Wi-Fi、クラウドサービスへのアクセス認証
実装企業では、証明書ベース認証導入により、デバイスなりすまし攻撃をほぼ100%排除しています。
デバイスポスチャーチェックAPI
クラウドアプリケーションへのアクセス時に、デバイスがセキュリティ要件を満たしているかを検証するAPI群があります。これにより、非準拠デバイスからのアクセスを遮断できます。
主要なデバイスポスチャーチェック仕様：
- Conditional Access（Microsoft） - Azure ADで条件付きアクセスを実装
- Okta Adaptive MFA - OKtaプラットフォームでのデバイス状態検証
- Jamf Pro - Apple製デバイスの統合管理と検証
- SCAP（Security Content Automation Protocol） - システムセキュリティ設定の標準化された検証
VPN Clientレベルの検証
リモートアクセスVPN利用時に、デバイスがセキュリティ基準を満たしているかを認証前に検証する技術も重要です。
VPN接続前の検証内容：
| 検証項目 | 合格基準 | 不合格時のアクション |
|---|---|---|
| OSバージョン | Windows 10以上、macOS 10.14以上 | 接続拒否 |
| ウイルス対策ソフト | インストール + 定義ファイル3日以内 | 接続拒否またはセグメント化 |
| ファイアウォール | 有効化確認 | 接続拒否 |
| パスワード | 8文字以上、複雑性あり | 接続拒否 |
| 最終パッチ適用日 | 90日以内 | セグメント化 |
セキュリティポスチャー評価
デバイスリスクスコアリング
すべての非準拠デバイスを同じように扱うのではなく、リスク度合いに応じた段階的なアクション（セグメンテーション）を実施することが、利便性とセキュリティのバランスを実現します。
リスクスコアリングモデルの例：
スコア範囲による分類：
| スコア | リスク度 | デバイス例 | 割り当てセグメント |
|---|---|---|---|
| 0～20 | 低リスク | OS最新、全パッチ適用、暗号化有効 | 通常セグメント（全アプリアクセス可） |
| 21～40 | 中リスク | OS古い、一部パッチ未適用 | 制限セグメント（基本アプリのみ） |
| 41～60 | 高リスク | ファイアウォール無効 | 隔離セグメント（最小限アプリのみ） |
| 61～100 | 極度リスク | ウイルス対策ソフト無効 | アクセス拒否 |
実装組織では、このようなリスクベースのセグメンテーション導入により、セキュリティを維持しながら、90%以上のユーザーが通常のネットワークアクセスを保持できるようになっています。
動的なスコア更新
デバイスリスクスコアは、静的ではなく、デバイス状態の変化に応じて動的に更新される必要があります。
スコア更新のトリガー：
- パッチの新規公開 - 新規脆弱性に対応するパッチが公開された場合
- セキュリティイベント検出 - デバイスでセキュリティインシデントが検出された場合
- ポリシー変更 - 企業が求めるセキュリティ要件が厳格化された場合
- 脅威インテリジェンス情報 - 既知の新型脅威が発見された場合
アクティブなスコア更新により、デバイスセキュリティ状態の変化に迅速に対応でき、新しい脅威への防御も効果的になります。
リスクベースアクセス制御
コンテキストベースアクセス制御（CBAC）
デバイス状態だけでなく、アクセスコンテキスト（ユーザー、ロケーション、時間、アプリケーション等）を総合的に評価してアクセス許可を判定するアプローチです。
CBAC評価の対象要素：
-
ユーザーコンテキスト
- ユーザーのロール・部門・権限レベル
- ユーザーのリスク履歴（過去のセキュリティインシデント等）
- ユーザーのアクセス行動パターン
-
デバイスコンテキスト
- デバイス種別（デスクトップ、ノート、モバイル）
- デバイス所有形態（企業支給、BYOD）
- デバイスセキュリティポスチャースコア
-
ロケーションコンテキスト
- 地理的位置（異なる国からのアクセスか等）
- ネットワーク種別（企業ネットワーク、公開Wi-Fi等）
- IPアドレスレピュテーション
-
アクセスコンテキスト
- アクセス対象リソースの機密度
- 通常と異なるアクセスパターンか
- 時間帯（夜間・休日アクセス等）
CBAC判定の例：
| シナリオ | ユーザー | デバイス | ロケーション | 判定 | 実施アクション |
|---|---|---|---|---|---|
| 通常営業時 | 営業部長 | 企業支給PC（高スコア） | オフィス | 許可 | 全権限でアクセス可 |
| テレワーク時 | 営業部長 | 企業支給PC（高スコア） | 自宅 | 許可 | 全権限でアクセス可 |
| 夜間 | 営業部長 | BYOD（低スコア） | 未知の地域 | 要追加認証 | MFA要求 |
| 異国からのアクセス | 営業部長 | 未登録デバイス | 海外 | 拒否 | アクセス遮断 |
アダプティブアクセスポリシー
リスク度合いに応じて、動的にアクセス許可条件を変更する仕組みです。
アダプティブポリシーの例：
リスク低い場合
- 認証要件：パスワードのみ
- アクセス範囲：フルアクセス
- 監視レベル：標準監視
リスク中程度の場合
- 認証要件：MFA（多要素認証）必須
- アクセス範囲：部門別に制限
- 監視レベル：強化監視（ユーザー行動分析）
リスク高い場合
- 認証要件：MFA + セキュリティキー
- アクセス範囲：最小限リソースのみ
- 監視レベル：全アクティビティ記録 + リアルタイムアラート
リスク極度に高い場合
- アクセス許可：段階的拒否
- 代替手段：セキュリティ部門への確認後に限定許可
ゼロトラストデバイス検証導入
実装ロードマップ
ゼロトラストデバイス検証の実装は、段階的に進めることが実際的です。
フェーズ1（3ヶ月）：基盤整備
- 現状デバイスの可視化と分類
- デバイスコンプライアンスベースラインの策定
- パイロット対象ユーザー・デバイスの選定
フェーズ2（6ヶ月）：試験的導入
- パイロットグループへのゼロトラスト導入
- デバイス検証ポリシーの試験運用
- ユーザーフィードバック収集と調整
フェーズ3（12ヶ月）：全社展開
- 全社員への段階的展開
- ポリシー最適化と自動化の推進
- 継続的な改善サイクル確立
LOCKED MDMによるデバイスコンプライアンス自動化
ゼロトラストアーキテクチャの実装において、デバイスのセキュリティポスチャー検証は中核的な役割を果たします。
LOCKED MDMは、以下によってデバイスコンプライアンスを統一的に管理します：
- 統一されたデバイス登録：iOS、Android、Windows、macOSを一箇所で管理
- 自動コンプライアンスチェック：OS更新状況、セキュリティソフト有効性を自動確認
- リアルタイムコンプライアンス監視：デバイス状態の変化を継続的に検証
- 非準拠時の自動アクション：コンプライアンス違反デバイスのアクセス制限、隔離
特に、月額160円/IDという低廉な価格設定により、全企業規模でのデバイス管理が実現可能です。
LOCKED DASとの連携によるアクセス制御
デバイスコンプライアンス検証だけでは不十分です。デバイス状態に基づいて、アクセス権限を動的に変更する必要があります。
LOCKED DAS × LOCKED MDMの連携：
- デバイスコンプライアンス情報の同期：LOCKED MDMが検出したデバイス状態をLOCKED DASに連携
- 動的アクセス制御：デバイス状態に基づいて、LOCKED DASのアクセス権限を自動調整
- リスクスコアの自動更新：デバイスリスクスコアを動的に更新
例：
- デバイスがOS更新状況が最新 → アクセス権限フル
- デバイスのファイアウォール無効検出 → アクセス権限制限
- デバイスにマルウェア検出 → アクセス遮断
LOCKED MSOとの連携による認証強化
デバイス検証とユーザー認証を組み合わせることで、多角的なアクセス制御が実現します。
LOCKED MSO × LOCKED MDMの連携：
- 条件付き認証：デバイス状態に応じて、認証強度を動的に調整
- デバイスベース認証：デバイス証明書による機械認証
- 生体認証の強制：高リスク環境での顔認証・指紋認証要求
例：
- 企業支給PC（高スコア）からのオフィスアクセス → パスワード認証のみ
- BYODからの自宅アクセス → MFA必須
- 未知のロケーション未登録デバイス → MFA + セキュリティキー必須
ゼロトラスト実装のベストプラクティス
ゼロトラストデバイス検証を効果的に実装するには、段階的なアプローチが重要です。
段階的実装戦略：
フェーズ1：基盤整備（1～3ヶ月）
- LOCKED MDMの導入、全デバイスの登録
- デバイスコンプライアンス基準の策定
- パイロット対象ユーザーの選定
フェーズ2：検証ポリシー導入（3～6ヶ月）
- LOCKED MSOでMFA導入
- リスクスコアリング導入
- 段階的なポリシー適用
フェーズ3：継続的改善（6ヶ月以降）
- ポリシー最適化、ユーザーフィードバック反映
- 機械学習による異常検知導入
- セキュリティ脅威に応じたポリシー更新
よくある実装課題と対策
課題1：レガシーデバイスへの対応
- 古いOSデバイスではMDM機能が完全にサポートされない
- 対策：段階的なデバイス置き換え計画、代替コンプライアンス手段の実装
課題2：ユーザー抵抗への対応
- 多要素認証等により、ユーザーの利便性が一時的に低下
- 対策：段階的な導入、ユーザー教育、セルフサービス機能充実
課題3：BYOD管理の複雑性
- 個人デバイスのセキュリティ状況が企業で制御困難
- 対策：デバイス登録ポリシーの明確化、企業データのコンテナ化
LOCKEDの詳細を見る 企業のセキュリティ対策でお悩みなら、LOCKEDシリーズの無料デモをお試しください。 資料請求・デモ依頼はこちら →
よくある課題と対策
課題1：レガシーデバイスの対応
- 古いOSのデバイスが多い場合、完全なコンプライアンスが難しい
- 対策：段階的なコンプライアンス基準の策定、デバイス置き換え計画の実施
課題2：ユーザー抵抗
- アクセス制限が厳しすぎると、ユーザーが迂回策を使用する
- 対策：十分な教育とコミュニケーション、段階的な厳格化
課題3：管理負荷の増加
- デバイスコンプライアンス維持に膨大な手作業が必要
- 対策：自動化ツール導入、統合管理プラットフォームの活用