お問い合わせ
SECURITY NOTE — 078

Google Workspace MDMとWindows TPMでデバイス信頼性を高める設計

PUBLISHED2026.05.15
READ9 分
CATEGORYSECURITY

Google Workspace MDM (モバイルデバイス管理) が提供するWindowsデバイス管理機能は、企業のセキュリティ基盤を強化する上で重要です。本記事では、このGoogle Workspace MDMとWindowsのTPM (Trusted Platform Module) チップを連携させ、デバイスの信頼性を高めるための設計について解説します。

この記事を読んだほうが良い人

  • Google Workspace MDMでWindowsデバイスを管理している情シス担当者
  • Windowsデバイスのセキュリティをさらに強化したいと考えている方
  • TPMチップの活用方法やGoogle Workspace MDMとの連携について知りたい方
  • Context-Aware Access (CAA) とデバイスの信頼性に基づくアクセス制御を検討している方

Google Workspace MDMとWindowsデバイス管理の現状

Google Workspace MDMは、Google Workspaceを利用する組織が従業員のデバイスを管理し、セキュリティポリシーを適用するためのツールです。Windowsデバイスに関しては、GCPW（Google Credential Provider for Windows）と連携することで、以下のような管理機能を提供します。

  • デバイス登録とプロビジョニング: ユーザーがGoogleアカウントでWindowsにログインすると、自動的にデバイスが登録され、組織のポリシーが適用されます。
  • セキュリティポリシーの適用: パスワードの複雑さ、画面ロック、BitLockerによるディスク暗号化、Windows Updateの管理など、様々なセキュリティ設定を強制できます。
  • アプリケーション管理: Google Chromeの拡張機能や特定のWindowsアプリケーションの展開・管理が可能です。
  • デバイス情報の収集とレポート: OSバージョン、シリアル番号、セキュリティ状態などのデバイス情報を管理コンソールで確認できます。

これらの機能は、Windowsデバイスの基本的なセキュリティと管理をカバーしますが、ハードウェアレベルでの信頼性の基盤となるTPM (Trusted Platform Module) チップとの直接的な連携については、その詳細が不明瞭な場合があります。

TPMとは？デバイス信頼性の基盤を理解する

TPM (Trusted Platform Module) は、デバイスに搭載されるセキュリティ専用のマイクロチップです。暗号鍵の生成・保存、デバイスの起動プロセスの整合性検証など、ハードウェアレベルでセキュリティ機能を提供します。

TPMの主な役割

  • 暗号鍵の保護: BitLockerなどのディスク暗号化で使われる鍵をTPM内に安全に保管し、改ざんから守ります。
  • セキュアブートの支援: OS起動時にファームウェアやブートローダーが改ざんされていないかを検証し、信頼された環境でのみOSが起動するようにします。
  • デバイスの整合性検証: デバイスの状態（ハードウェア、ファームウェア、OS）を測定し、その測定値をTPMに記録することで、デバイスが不正に変更されていないことを証明できます。

TPM 1.2と2.0の違い

現在主流となっているのはTPM 2.0です。TPM 1.2と比較して、TPM 2.0はより強力な暗号アルゴリズムに対応し、柔軟な管理が可能です。Windows 10/11の多くのセキュリティ機能はTPM 2.0を前提としています。

TPM 2.0対応の確認コマンド

お使いのWindowsデバイスがTPM 2.0に対応しているかを確認するには、以下の手順を実行します。

  1. Windowsキー + R を押して「ファイル名を指定して実行」を開きます。
  2. tpm.msc と入力してEnterキーを押します。

これにより、TPM管理コンソールが開きます。「TPMのバージョン」の項目で、バージョンが「2.0」と表示されていれば対応しています。

また、PowerShellコマンドでも確認できます。

Get-Tpm

実行結果の TpmPresent が True であり、TpmManufacturerVersion や TpmVersion が 2.0 に近い値であればTPM 2.0に対応しています。

Google Workspace MDMが参照するWindowsデバイスの信頼情報

Google Workspace MDMは、Windowsデバイスに直接搭載されているTPMチップのバージョンやヘルス状態を、管理コンソール上で直接的な属性として表示する機能は持っていません。しかし、TPMが提供するセキュリティ機能によって担保されるOSレベルのセキュリティ状態を把握することで、間接的にデバイスの信頼性を判断できます。

Google Workspace管理コンソールで確認できるWindowsデバイスの主な状態フィールドは、以下の通りです。

  • OSバージョン: Windows 10/11などのOSバージョンとビルド番号。
  • モデルとシリアル番号: デバイスのハードウェア識別情報。
  • 最終アクティビティ / 最終同期: デバイスがGoogle Workspaceと通信した最終時刻。
  • セキュリティステータス:
    • パスワード: 画面ロックパスワードの設定状況。
    • 画面ロック: 画面ロックが有効になっているか。
    • セキュアブート: セキュアブートが有効になっているか。これはTPMと密接に関連しており、OSの起動プロセスが改ざんされていないことを保証します。
    • BitLocker: BitLockerによるディスク暗号化が有効になっているか。TPMはBitLockerの暗号鍵を保護するために利用されます。

これらの情報の中で特に「セキュアブート」と「BitLocker」は、TPMチップが正常に機能していることによってセキュリティが強化される項目です。Google Workspace MDMはこれらのOSが報告する状態を収集し、管理者はそれに基づいてデバイスの信頼性を判断します。

Context-Aware Access (CAA) を活用したデバイス信頼性設計

Context-Aware Access (CAA) は、ユーザーの身元だけでなく、デバイスの状態、IPアドレス、地理的位置などの「コンテキスト」に基づいてGoogle Workspaceリソースへのアクセスを制御する機能です。Google Workspace MDMが収集したデバイス情報をCAAポリシーに活用することで、よりきめ細やかなアクセス制御を実現できます。

CAAとTPMが間接的に影響するデバイス信頼性連携の考え方

CAAは、Google Workspace MDMが報告するデバイスの「セキュリティステータス」を利用してポリシーを適用します。TPMが直接参照されるわけではありませんが、TPMによって有効化・保護されている「セキュアブート」や「BitLocker」の状態をCAAの条件として利用することで、実質的にTPMが機能している信頼性の高いデバイスのみにアクセスを許可できます。

以下の表に、CAAが参照可能なデバイス属性と、TPMとの関連性を示します。

CAAで参照可能なデバイス属性 TPMとの関連性
デバイスの承認済みステータス 管理者が承認したデバイスのみアクセス許可。TPMの有無とは直接関係しないが、信頼されたデバイスの基盤となる。
OSバージョン 特定のOSバージョン以上を要求。TPMの有無とは直接関係しない。
画面ロックが有効 画面ロック設定を要求。TPMの有無とは直接関係しない。
BitLockerが有効 ドライブ暗号化を要求。TPMがBitLockerの鍵を保護するため、TPMが機能しているデバイスはこれを満たしやすい。
セキュアブートが有効 セキュアブートを要求。TPMがOS起動時の整合性検証を支援するため、TPMが機能しているデバイスはこれを満たしやすい。
会社所有デバイス 管理者が所有者として登録したデバイスのみアクセス許可。TPMの有無とは直接関係しないが、信頼されたデバイスの基盤となる。

CAAポリシー設計の例

例えば、「Google Driveにアクセスできるのは、会社が承認したデバイスで、かつBitLockerとセキュアブートが有効なWindowsデバイスのみ」というポリシーを設定できます。

  1. 管理コンソール > セキュリティ > アクセスとデータ管理 > コンテキストアウェア アクセス に移動します。
  2. 「アクセスレベル」を作成し、以下の条件を設定します。
    • デバイスプラットフォーム: Windows
    • 会社所有デバイス: はい
    • デバイスの承認済みステータス: 承認済み
    • BitLocker: 有効
    • セキュアブート: 有効
  3. このアクセスレベルをGoogle Driveなどの対象アプリに適用します。

これにより、TPMが正常に機能し、セキュアブートとBitLockerが有効になっている信頼性の高いWindowsデバイスからのみ、機密情報へのアクセスを許可することが可能になります。

導入前のチェックリストと考慮事項

Google Workspace MDMとWindows TPMを活用したデバイス信頼性設計を導入する前に、以下の項目を確認し、計画を立てることが重要です。

  • TPM 2.0対応状況の確認:
    • 管理対象とするすべてのWindowsデバイスがTPM 2.0に対応しているか、tpm.msc コマンドなどで確認します。
    • 非対応デバイスへの対応方針（除外、交換、別のセキュリティ対策適用など）を決定します。
  • 既存ポリシーとの整合性:
    • 既に設定されているGoogle Workspace MDMポリシー、Windowsグループポリシー、Microsoft Intuneポリシーなどとの競合がないかを確認します。
    • 特にBitLockerやセキュアブートの設定が重複したり、矛盾したりしないよう注意します。
  • ユーザーへの影響と周知:
    • CAAポリシーを適用することで、条件を満たさないデバイスからのアクセスがブロックされる可能性があります。ユーザーへの事前周知と、対応方法（例: デバイスのセキュアブートを有効にする手順）の案内が必要です。
    • ヘルプデスクへの問い合わせ増加に備えた体制も検討します。
  • テストと段階的導入:
    • 少数のテストユーザーやテストデバイスでポリシーを適用し、予期せぬ問題が発生しないかを確認します。
    • 問題がなければ、部署ごとなど段階的に適用範囲を広げていくことを推奨します。
  • 監視と監査:
    • CAAのログを定期的に確認し、アクセス拒否が発生していないか、ポリシーが意図通りに機能しているかを監視します。
    • Google Workspaceの監査と調査ログを活用し、デバイスのセキュリティ状態の変化を追跡します。

まとめ

Google Workspace MDMは、Windowsデバイスの管理においてTPMチップの情報を直接参照する機能は持ちませんが、TPMによって実現される「セキュアブート」や「BitLocker」といったOSレベルのセキュリティ状態を管理コンソールで把握できます。この情報をContext-Aware Access (CAA) と連携させることで、TPMが機能している信頼性の高いデバイスからのアクセスのみを許可する、強固なセキュリティ環境を構築することが可能です。

情シス担当者としては、TPMの基本的な理解を深め、既存のGoogle Workspace MDMの機能を最大限に活用し、TPMに支えられたデバイスの信頼性をセキュリティポリシーに組み込む設計が求められます。この設計は、組織のデータセキュリティを強化し、安全な働き方を推進する一歩となります。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る
一社ずつ、一から。