デバイス信頼とポスチャー管理

ゼロトラストアーキテクチャでは「ネットワーク境界を信頼しない」原則のもと、すべてのアクセス要求をリソースへの到達前に検証する。その中でデバイスは「誰が（ユーザー identity）」と並ぶ主要な信頼シグナルであり、デバイスの健全性・準拠状態（posture）を継続的に評価することがゼロトラスト実装の中核をなす。本記事はデバイス posture チェック・証明書認証・MDM 連携・BYOD 区別という四つの柱を俯瞰し、各実装上の落とし穴を整理する。

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

従来の境界型セキュリティは「社内ネットワークにいれば信頼」という前提に立つが、クラウド移行・リモートワーク普及・BYOD 拡大によりこの前提は成立しなくなった。ゼロトラストモデルでは 「Never Trust, Always Verify」 を原則とし、各リソースアクセスを評価する際に少なくとも次の二軸を検証する。

1. ユーザー identity — 認証されたアカウントか、MFA は完了しているか（→ authentication-methods tech-125 参照）
2. デバイス posture — アクセス端末は組織のセキュリティ基準を満たしているか

この二軸を組み合わせたポリシーエンジン（例: Microsoft Entra ID Conditional Access、Google BeyondCorp Enterprise）がアクセス可否を動的に決定する。デバイス posture の評価が抜ければ、正当な認証済みユーザーがマルウェア感染端末からアクセスしても許可されてしまう。

情報カットオフ ~2025-08、confidence: medium 固定。以下は 2026-05 時点で要確認の事項: 各プラットフォームの最新 posture シグナル仕様（Google / Microsoft の具体的 API バージョン）。

デバイス Posture チェック

Posture チェックとは、エンドポイントの健全性・コンプライアンス状態を評価するプロセスである。評価項目は組織ポリシーにより異なるが、一般的な観点を以下に整理する。

主要な評価シグナル

評価タイミング

• 初回認証時のみ評価: シンプルだが、認証後にデバイス状態が悪化した場合（例: 認証後にマルウェア感染）を検知できない。
• 継続的評価（Continuous Adaptive Trust）: セッション中も定期的に posture を再評価し、基準を満たさなくなった場合はセッションを切断またはアクセスを制限する。これがゼロトラスト本来の姿であり、より高いセキュリティを実現する。

実装例

Microsoft Intune と Entra ID Conditional Access を連携させる場合、Intune がデバイスのコンプライアンス状態を評価し、Entra ID がそのシグナルをポリシー判定に組み込む。Google BeyondCorp Enterprise（旧 Chrome Enterprise）も同様のアーキテクチャをクロスプラットフォームで提供する。

証明書認証とデバイスバインド

ユーザーのパスワード・トークンに頼らず、デバイス自体に証明書を発行して認証する手法がデバイス証明書認証である。

デバイス証明書の仕組み

1. PKI（Public Key Infrastructure） による証明書発行: 組織内 CA または クラウド CA（Microsoft Intune SCEP、NDES など）がデバイスごとに証明書を発行する。
2. 秘密鍵の保護: 証明書の秘密鍵を TPM（Trusted Platform Module）または Apple Secure Enclave にバインドすることで、鍵がデバイスの外に持ち出せない状態にする。これにより証明書の複製・盗用を防ぐ。
3. mTLS（Mutual TLS）: サーバーがクライアント証明書を要求し、デバイス identity を検証する双方向 TLS。ゼロトラストネットワーク・アクセスプロキシが mTLS を使ってデバイスを認証するケースが多い。

TPM・Secure Enclave バインドの意義

ソフトウェアのみで秘密鍵を管理する場合、OS やアプリからの鍵抽出リスクがある。TPM（Windows デバイスに広く搭載）や Apple の Secure Enclave（iOS・macOS）は、鍵をハードウェアセキュリティチップに閉じ込め、チップ外への秘密鍵エクスポートを物理的に不可能にする。これにより、証明書を盗んでも別のマシンで使用できない。

注意点

• 失効管理（CRL / OCSP）: 証明書を発行するだけでなく、退職者や紛失端末の証明書を速やかに失効させる仕組みが必要。
• 有効期限の設計: 証明書の有効期限が長すぎると管理リスク、短すぎると更新の煩雑さが増す。多くの組織は 1〜2 年を選択する。

MDM / UEM 連携

MDM（Mobile Device Management）または UEM（Unified Endpoint Management）は、組織がエンドポイントを一元管理するプラットフォームであり、デバイス信頼実装の中核となる。

主要プラットフォーム

Microsoft Intune: Windows・macOS・iOS・Android を横断的に管理。Entra ID（旧 Azure AD）との深い統合により、Conditional Access でのデバイスコンプライアンス評価が容易。Microsoft 365 環境との親和性が高い。

Jamf: macOS・iOS 専門の MDM として高い評価を持つ。Apple Business Manager との統合が優れ、Apple デバイス中心の企業で広く採用される。Jamf Pro（フルMDM）と Jamf Now（SMB 向け）がある。

MDM の主要機能

1. デバイス登録（Enrollment）: ユーザーまたは IT 管理者がデバイスを MDM プロファイルに登録する。Apple DEP（Device Enrollment Program）/ Apple Business Manager による自動登録が普及している。
2. ポリシー配信: パスワードポリシー・暗号化要件・禁止アプリリストなどを端末に自動適用する。
3. コンプライアンス評価: 登録デバイスの posture を継続的に評価し、不準拠デバイスを検出する。
4. 条件付きアクセス連携: Intune の場合、コンプライアンス状態を Entra ID に伝達し、非準拠デバイスからの M365 リソースアクセスをブロックできる。
5. リモートワイプ: 紛失・盗難時にデバイス上のデータを遠隔消去する。

登録 = 信頼ではない

MDM への登録は管理可能性を確保するが、それ自体がセキュリティを保証するわけではない。登録済みデバイスでもパッチ未適用・EDR 無効化などによりリスクが生じる。MDM 登録と posture チェックを組み合わせて初めて意味のある信頼評価が成立する。

BYOD と管理デバイスの区別

組織デバイス（Corporate-owned）と個人デバイス（BYOD: Bring Your Own Device）はセキュリティ要件が大きく異なる。

管理デバイス（Corporate-owned）

• MDM フル管理が可能
• デバイス証明書の発行・管理が容易
• より厳格な posture チェックを要求できる
• 全アプリ・設定の把握が可能

BYOD

• フル MDM 管理にはプライバシーの懸念が伴う（個人データへのアクセス）
• MAM（Mobile Application Management）または「ワークプロファイル」（Android Enterprise）で業務データを個人データから分離する手法が主流
• posture チェックは限定的になりがち（例: OS バージョン・証明書存在のみ）
• 高機密リソースへのアクセスは BYOD では禁止するポリシーも多い

アクセスポリシーの段階化

よくある落とし穴（Anti-Pattern）