はじめに
境界型防御（社内ネットワークと社外ネットワークを分ける考え方）が限界を迎えた現代、すべてのアクセスを疑い、検証する「ゼロトラスト（Zero Trust）」モデルへの移行が急務となっています。
そのゼロトラストを実現するための最も重要な要素の一つが、デバイスの正常性確認（Device Health Attestation: DHA）です。単に「正しいIDとパスワードを知っているから」という理由だけでアクセスを許可するのではなく、「アクセスしてきている端末が、今本当に安全な状態か」をハードウェアレベルで検証します。
この記事では、ゼロトラストの第一歩となるデバイスの正常性確認の仕組みと、Windows環境における実装について解説します。
1. なぜ「アイデンティティ」の検証だけでは不十分なのか？
従来のVPNやクラウドアクセスでは、多要素認証（MFA）などでユーザーの身元（アイデンティティ）さえ確認できれば、社内リソースへのアクセスを許可することが一般的でした。
しかし、以下のケースではアイデンティティ認証だけでは防御できません。
- マルウェア感染端末: ユーザー自身は本物だが、PCがマルウェアに感染しており、キーロガーやリモート操作によってセッションが乗っ取られている。
- パッチ未適用・セキュリティ機能無効化端末: OSのアップデートが未適用だったり、EDR（ウイルス対策ソフト）が停止していたりする「脆弱な状態」の私用PCからアクセスされる。
ゼロトラストでは、ユーザーの認証に加えて、「デバイスの健全性（Health）」が組織のセキュリティポリシーを満たしていることをアクセスの絶対条件とします。
2. デバイスの正常性確認（Health Attestation）の仕組み
Windows 10/11では、ハードウェアに搭載されたセキュリティチップである TPM（Trusted Platform Module） を利用して、偽装不可能な端末状態のレポートを作成します。この仕組みを デバイスの正常性確認（DHA） と呼びます。
測定されたブート（Measured Boot）
端末が起動する際、ファームウェア（UEFI）、ブートローダー、OSカーネル、セキュリティドライバーなどが起動していく順序に従って、それぞれのプログラムのハッシュ値をTPM内の「PCR（Platform Configuration Registers）」と呼ばれるレジスタに記録（測定）していきます。
検証のフロー
端末が起動を完了すると、以下のフローで正常性が検証されます。
- レポートの作成: 端末（クライアント）は、TPMに記録されたログ（ブート測定値）を暗号化署名付きのレポートとして出力します。
- 検証サーバーへの送信: レポートは、Microsoftの「Device Health Attestationサービス（DHA-Service）」、または組織内で構成された検証サーバーに送信されます。
- ポリシー評価: 検証サーバーはレポートを解析し、「BitLocker（暗号化）が有効か」「セキュアブートが有効か」「コード整合性ポリシーが適用されているか」などをチェックし、健全性ステートメントを発行します。
- アクセス制御（MDM/IdPとの連携）: Microsoft IntuneなどのMDMや、Microsoft Entra IDなどのIdP（アイデンティティプロバイダー）がこの結果を受け取り、「正常性が確認された端末のみ、Microsoft 365や社内システムへのアクセスを許可する（条件付きアクセス）」という制御を行います。
3. Health Attestationで検証される主な項目
DHAによって、ソフトウェアによる偽装（レジストリの書き換えなど）が不可能な、以下のハードウェア・OS根拠のステータスが検証されます。
| 検証項目 | 概要 | 狙われるリスクへの対策 |
|---|---|---|
| Secure Boot（セキュアブート） | UEFIが信頼されたブートローダーのみを起動しているか。 | OS起動前に割り込むルートキット（Bootkit）の検知。 |
| BitLocker（ドライブ暗号化） | 端末のストレージが暗号化されているか。 | 端末紛失・盗難時のデータ物理抜き出し対策。 |
| Early Launch Anti-Malware（ELAM） | OS起動の最初期段階でアンチマルウェアが動作しているか。 | セキュリティソフトより先に起動しようとするマルウェアの阻止。 |
| Code Integrity（コード整合性） | 署名された正当なシステムファイルのみが実行されているか。 | システムファイルの改ざんや未承認ドライバーの実行検知。 |
4. ゼロトラスト環境への組み込み例（Intune と条件付きアクセス）
この機能を実際の運用に落とし込む場合、Microsoft Intune（MDM）とMicrosoft Entra IDの「条件付きアクセス」を組み合わせるのが一般的です。
構成ステップ
-
Intuneでコンプライアンスポリシーを作成
- ポリシー設定内で「セキュアブートの必須化」「BitLockerの必須化」等のデバイス正常性（DHA）関連項目を有効にします。
-
端末による正常性レポートの提出
- 端末が起動・同期する際、TPMベースのデータを検証サービスへ送り、Intuneがその端末を「準拠（Compliant）」ステートに設定します。
-
Entra IDの条件付きアクセスでブロック
- 「Microsoft 365へのアクセスは、『準拠しているとマークされたデバイス』からのみ許可する」というポリシーを強制します。
これにより、万が一マルウェアによってセキュアブートが破られたり、BitLockerが解除されたりした端末は、即座にクラウドサービスから締め出されます。
まとめ：ハードウェアを起点とした信頼の確立（Root of Trust）
ゼロトラストにおいて「デバイスを信用する」とは、アンケートのように「ウイルス対策ソフトは入っていますか？」と端末に自己申告させることではありません。
TPMという「Root of Trust（信頼の起点）」となるハードウェアから、起動プロセスのログを暗号学的に証明させるDevice Health Attestationこそが、デバイス偽装や高度なサイバー攻撃を防ぐ強力な盾となります。
アイデンティティ（人）とデバイス（端末）の両輪を検証する体制を整えること。これこそが、ゼロトラストへの確実な第一歩です。