お問い合わせ
SECURITY NOTE — 037

CAAの「デバイス認証」を徹底解説！情シスがGoogle Workspaceへのアクセスを許可するデバイスを厳選する方法

PUBLISHED2026.04.26
READ12 分
CATEGORYSECURITY

Google Workspaceのセキュリティを強化する上で、Context-Aware Access (CAA) は重要な機能です。この記事では、特にCAAの「デバイス認証」に焦点を当て、情シス担当者がGoogle Workspaceへのアクセスを許可するデバイスを厳選し、情報漏洩リスクを低減するための具体的な設定方法と運用上のポイントを解説します。

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

  • 100名規模の企業でGoogle Workspaceを運用している情シス担当者
  • Context-Aware Access (CAA) を利用してデバイスからのアクセスセキュリティを強化したいと考えている方
  • 特定のセキュリティ要件を満たさないデバイスからのGoogle Workspaceアクセスをブロックしたいが、具体的な設定方法が不明な方
  • デバイス認証を強化した際のユーザー影響や運用負担を最小限に抑えたい方
  • 情報漏洩リスク低減のため、デバイスの状態に基づいたアクセス制御に関心がある方

Context-Aware Access (CAA)とは何か？デバイス認証の重要性

Context-Aware Access (CAA) は、Google Workspaceのセキュリティ機能の一つで、ユーザーのID、ロケーション（IPアドレス）、デバイスの状態、時間帯などの「コンテキスト」に基づいて、Google Workspaceアプリケーションへのアクセスを制御する仕組みです。これにより、従来の社内ネットワーク境界に依存しない、よりきめ細やかなアクセス制御を実現します。これはGoogleが提唱するゼロトラストセキュリティモデル「BeyondCorp Enterprise」の中核をなす要素です。

CAAの中でも特に重要なのが「デバイス認証」です。これは、アクセス元のデバイスが組織のセキュリティポリシーに準拠しているかを確認し、その状態に応じてアクセスを許可または拒否する機能です。例えば、以下の項目をチェックできます。

  • OSのバージョン: 最新のセキュリティパッチが適用されているか
  • ディスク暗号化: デバイスのストレージが暗号化されているか
  • 画面ロック: 画面ロックが有効になっているか
  • デバイス所有権: 組織が所有するデバイスであるか
  • セキュリティパッチレベル: Androidデバイスのセキュリティパッチ適用状況

これらの項目をチェックすることで、セキュリティリスクの高いデバイスからのアクセスを制限し、情報漏洩のリスクを大幅に低減できます。例えば、個人所有の未管理デバイスや、OSが古く脆弱性のあるデバイスからの機密情報へのアクセスを防ぐことが可能になります。

デバイス認証で制御できる項目と種類

Google WorkspaceのContext-Aware Access (CAA) では、デバイスの状態に関する多様な属性に基づいてアクセスレベルを定義できます。これらの情報は、主に「Endpoint Verification (エンドポイント確認機能)」と呼ばれるGoogle Chromeブラウザ拡張機能（またはChromeOSに組み込みの機能）を通じて収集されます。

具体的に制御できる主な項目は以下の通りです。

1. OSのタイプとバージョン

  • OSタイプ: Chrome OS、iOS、Android、macOS、Windows、Linuxなど、アクセス元のオペレーティングシステムを指定できます。
  • OSバージョン: 特定のOSについて、最小バージョンや最大バージョンを設定し、古すぎるOSや、特定のバージョンに限定してアクセスを許可できます。例えば、「Windows 10 22H2以降」や「macOS Sonoma以降」といった条件を設定可能です。

2. デバイスのセキュリティ状態

  • ディスク暗号化: デバイスのストレージが暗号化されているかどうかを判別します。情報漏洩対策として必須の項目です。
  • 画面ロック: デバイスに画面ロック（パスワード、PIN、生体認証など）が設定されているかどうかを判別します。
  • セキュリティパッチレベル (Androidのみ): Androidデバイスの場合、適用されているセキュリティパッチの最終日付を基準にアクセスを制御できます。
  • 検証済みブート (Chrome OSのみ): Chrome OSデバイスがセキュアブートプロセスを経ているかを判別します。

3. デバイスの管理状態と所有権

  • デバイスが会社所有であること: Google Workspaceの管理対象デバイスとして登録され、組織が所有しているデバイスからのアクセスのみを許可できます。個人のBYOD (Bring Your Own Device) を制限したい場合に有効です。
  • デバイスポリシーへの準拠: Google Workspaceのデバイス管理機能やサードパーティのMDM (Mobile Device Management) ソリューションと連携し、デバイスが組織のセキュリティポリシーに準拠しているかをチェックします。

これらの詳細な属性を組み合わせることで、「会社が所有し、最新のWindows OSで、ディスク暗号化されているデバイスからのみ、特定の機密情報にアクセスを許可する」といった厳格なポリシー設計が可能になります。

Google Workspace管理コンソールでの設定手順

Context-Aware Access (CAA) のデバイス認証を設定するには、主に「アクセスレベルの作成」と「アプリケーションへのアクセスレベルの適用」の2ステップが必要です。

ステップ1：アクセスレベルの作成

アクセスレベルは、どのようなコンテキスト（条件）を満たすデバイスやユーザーにアクセスを許可するかを定義するものです。

  1. Google Workspace管理コンソールにログインします。
  2. 「セキュリティ」>「Context-Aware Access」>「アクセスレベル」に移動します。
  3. 「アクセスレベルを作成」をクリックします。
  4. アクセスレベル名（例: Secure_Corporate_Devices）と、必要に応じて説明を入力します。
  5. 条件を設定します。ここではデバイス認証に関する条件を追加します。
    • 条件モードの選択: 「条件をすべて満たす」または「いずれかを満たす」を選択します。厳格なポリシーには「すべて満たす」が推奨されます。
    • 「属性を追加」をクリックし、以下のデバイス属性を選択し、値を設定します。
      • オペレーティングシステム:
        • 「OSタイプ」で Windows を選択。
        • 「OSバージョン」で 10.0.19045 (Windows 10 22H2のビルド番号) 以上を指定。
      • ディスク暗号化:
        • 「デバイスにディスク暗号化が必要」にチェックを入れる。
      • 画面ロック:
        • 「デバイスに画面ロックが必要」にチェックを入れる。
      • デバイス所有権:
        • 「企業所有のデバイスが必要」にチェックを入れる。
    • これらの条件を追加したら、「アクセスレベルを作成」をクリックして保存します。

ステップ2：アプリケーションへのアクセスレベルの適用

作成したアクセスレベルを、Google Workspaceの特定のアプリケーション（例: ドライブ、Gmailなど）に適用します。

  1. 管理コンソールで「セキュリティ」>「Context-Aware Access」>「アクセスレベルを割り当て」に移動します。
  2. 左側のリストから、アクセス制御を適用したい組織部門（OU）を選択します。通常はトップレベルの組織を選択し、必要に応じて下位のOUで上書きします。
  3. アクセス制御を適用するGoogle Workspaceサービス（例: Google ドライブ）を選択します。
  4. 「アクセスレベルを割り当て」をクリックし、先ほど作成したアクセスレベル（例: Secure_Corporate_Devices）を選択します。
  5. アクセスレベルを適用できないユーザーに対して表示されるカスタムメッセージを設定できます。ユーザーがアクセスを拒否された際に、なぜ拒否されたのか、どうすればアクセスできるようになるのかを案内するメッセージを設定することが重要です。
  6. 「保存」をクリックして設定を適用します。

この設定により、指定した組織部門に属するユーザーは、Secure_Corporate_Devices の条件を満たすデバイスからのみ、Google ドライブにアクセスできるようになります。条件を満たさないデバイスからのアクセスはブロックされ、設定したカスタムメッセージが表示されます。

ポリシー適用がユーザー体験に与える影響と対策

Context-Aware Access (CAA) のポリシー、特にデバイス認証を適用する際には、ユーザー体験に大きな影響を与える可能性があります。情シス担当者としては、セキュリティ強化とユーザーの利便性のバランスを取り、スムーズな移行を促すための対策が不可欠です。

予期せぬアクセスブロックとユーザーの混乱

最も直接的な影響は、ポリシーに準拠しないデバイスからのアクセスがブロックされることです。これにより、以下のような混乱が生じる可能性があります。

  • 業務中断: 必要な情報にアクセスできず、業務が滞る。
  • 問い合わせの増加: 情シスへの問い合わせが殺到し、対応に追われる。
  • 不満の増大: ユーザーがセキュリティ強化の意図を理解できず、不満を感じる。

対策

  1. 事前の十分な告知と説明:
    • ポリシー適用前に、対象ユーザーに対して、なぜこの変更が必要なのか、どのようなデバイスがアクセスできなくなるのか、どうすればアクセスできるようになるのかを具体的に説明します。
    • 社内ポータルやメールで、FAQや対応手順を公開し、ユーザー自身で問題を解決できるように導きます。
  2. 段階的な導入:
    • 全ユーザーや全サービスに一斉に適用するのではなく、まずは一部の部署や特定の機密性の高いサービスから試行的に導入し、影響を確認しながら徐々に拡大します。
    • 「レポートモード」や「アラートのみ」の設定があれば、それを利用して実際のブロックなしに影響を事前に把握します。
  3. 除外グループの設定:
    • 特定の部署や役割を持つユーザー（例: 経営層、開発者など）で、一時的にポリシーの適用を除外するグループを設定し、柔軟な運用を可能にします。ただし、セキュリティリスクを考慮し、最小限に留めるべきです。
  4. カスタムメッセージの最適化:
    • アクセスが拒否された際に表示されるカスタムメッセージは、非常に重要です。単に「アクセスが拒否されました」と表示するだけでなく、「このデバイスは会社のセキュリティポリシーを満たしていません。詳細はこちらのFAQをご確認ください」といった形で、次のアクションに繋がる具体的な情報を提供します。
  5. Endpoint Verificationの展開とサポート:
    • デバイス認証にはEndpoint Verificationの導入が不可欠です。ユーザーがスムーズに拡張機能をインストールし、正しく動作するよう、導入手順の提供やトラブルシューティングのサポート体制を整えます。特に、macOSやWindowsでは別途ヘルパーアプリのインストールが必要になる場合があるので、その点も周知します。

これらの対策を講じることで、セキュリティ強化の目的を達成しつつ、ユーザーの負担を最小限に抑え、スムーズな運用を実現できます。

運用上の注意点とトラブルシューティング

Context-Aware Access (CAA) のデバイス認証は強力なセキュリティ機能ですが、導入後も継続的な運用と監視が不可欠です。

運用上の注意点

  1. Endpoint Verificationの展開と維持:
    • デバイス認証の基盤となるEndpoint Verificationが、対象デバイスに正しくインストールされ、常に最新の状態に保たれているかを確認します。ブラウザ拡張機能の更新や、ヘルパーアプリの導入状況を定期的にチェックしましょう。
    • ユーザーが誤って拡張機能を無効化したり、アンインストールしたりしないよう、ポリシーで制御することも検討します。
  2. OSアップデートへの対応:
    • OSの最小バージョンを条件に設定している場合、新しいOSバージョンがリリースされた際に、既存のポリシーが影響を受ける可能性があります。例えば、「Windows 10 22H2以上」としていたポリシーが、Windows 11へのアップグレード後にどうなるか、新しいWindows 10のバージョンがリリースされた際に、そのバージョンも許可範囲に含めるべきかなどを考慮し、適宜ポリシーを更新する必要があります。
    • OSアップデートの計画とポリシー更新のサイクルを同期させることが重要です。
  3. 組織変更やデバイスライフサイクルへの対応:
    • 社員の異動、退職、デバイスの買い替えなど、組織やデバイスの状況が変わるたびに、ポリシーへの影響がないか確認します。特に、デバイス所有権を条件としている場合、デバイスの登録解除や再登録の手順を明確にしておく必要があります。
  4. ポリシーの定期的な見直し:
    • ビジネス要件やセキュリティ脅威の状況は常に変化します。導入後も年に一度など定期的にアクセスレベルとポリシーを見直し、現在の状況に最適化されているかを確認します。

トラブルシューティングのポイント

  1. アクセスレベルのレポート機能の活用:
    • Google Workspace管理コンソールには、アクセスレベルがどのように適用されているか、どのユーザーがどの理由でブロックされたかを確認できるレポート機能があります。これを活用して、問題の原因を特定します。
  2. ユーザーからの情報収集:
    • アクセスが拒否されたユーザーからは、以下の情報を詳しく収集します。
      • いつ、どのデバイスで、どのGoogle Workspaceサービスにアクセスしようとしたか。
      • 表示されたエラーメッセージの全文。
      • デバイスのOSバージョン、ディスク暗号化状況、Endpoint Verificationのインストール状況。
  3. テスト用アクセスレベルの活用:
    • 新しいポリシーを導入する際や、トラブルシューティングを行う際には、特定のテストユーザーやテストデバイスにのみ適用されるアクセスレベルを作成し、影響範囲を限定して検証します。
  4. Endpoint Verificationの状態確認:
    • ユーザーのデバイスでEndpoint Verificationが正しく動作しているかを確認します。Chromeブラウザの拡張機能ページで有効になっているか、アイコンが正常に表示されているかなどをチェックします。必要に応じて、拡張機能の再インストールやヘルパーアプリの再起動を指示します。
    • 管理コンソールの「デバイス」>「エンドポイント」からも、各デバイスのEndpoint Verificationの状態や収集されたデバイス属性を確認できます。

これらの運用上の注意点とトラブルシューティングの知識を持つことで、CAAデバイス認証を安定して運用し、Google Workspaceのセキュリティを継続的に強化できます。

まとめ：デバイス認証で実現する強固なGoogle Workspaceセキュリティ

Context-Aware Access (CAA) のデバイス認証は、Google Workspace環境における情報漏洩リスクを大幅に低減するための強力な手段です。OSバージョン、ディスク暗号化、デバイス所有権といった詳細な条件に基づいてアクセスを制御することで、組織が求めるセキュリティ基準を満たさないデバイスからの不正アクセスを効果的にブロックできます。

導入にあたっては、管理コンソールでのアクセスレベル作成とアプリケーションへの適用が主な手順となりますが、それ以上に重要なのは、ユーザーへの事前の十分な説明と、導入後の継続的な運用・監視です。ポリシー適用がユーザー体験に与える影響を最小限に抑えるための段階的導入やカスタムメッセージの最適化、そしてOSアップデートやデバイスライフサイクルに合わせたポリシーの見直しは、情シス担当者にとって欠かせない業務です。

この記事が、Google Workspaceのセキュリティ強化を目指す情シス担当者の皆様にとって、Context-Aware Accessのデバイス認証を理解し、実際に導入・運用するための一助となれば幸いです。強固なセキュリティ基盤を構築し、安全なデジタルワークプレイスを実現しましょう。

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

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

CONTACT

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

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

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