Google Workspace の Context-Aware Access(CAA)では、場所・デバイス状態・時間帯・リスクシグナルという 4 種の条件を AND/OR で組み合わせてアクセスポリシーを設計できます。本記事では、単一条件の運用から複合条件設計へ進む際の判断フレームワークと段階展開ロードマップを整理します。
この記事を読んだほうが良い人
- CAA を IP 制限や管理対象デバイスなど単一条件で運用中の情シス担当者
- 複数条件を AND/OR でどう組み合わせるか、判断基準が整理できていない方
- ハイブリッドワーク環境でより精緻なアクセス制御設計を検討している方
- 条件を追加する際にモニターモードを活用したい方
Context-Aware Access 複合条件設計が必要になるタイミング
CAA 導入初期は、「オフィスの IP からしかアクセスさせない」「管理対象デバイスのみ許可」といった単一条件でも十分に機能します。ただし、ハイブリッドワークが定着した環境では、単一条件だけでは対応しきれない設計上の矛盾が生じてきます。
たとえば、次のような状況がその典型です。
- 在宅勤務中に管理対象デバイスを使う正規ユーザーが IP 制限でブロックされる
- 管理対象デバイスからのアクセスであっても深夜帯の接続を制限したい
- BYOD(個人所有デバイス)を一部業務に限定許可したいが、適切な絞り込み手段がない
こうした要件への対応には、複数の条件を組み合わせた「複合アクセスレベル」の設計が必要です。複合条件の設計で問われるのは「どの条件をどの論理で組み合わせるか」という判断であり、ここを間違えると制御が不必要に緩くなるか、誤検知が増えるかのどちらかに振れます。
もう一つ重要な観点として、アプリケーションごとにリスクレベルが異なる点があります。経費精算ツールと Google Vault(電子情報保全)、管理コンソールでは、それぞれ求められる制御の厳格さが異なります。複合条件設計を始める前に、守るべきリソースをリスク分類しておくことが設計の起点になります。リスク分類ができていないまま条件を足していくと、厳しすぎる制御と甘すぎる制御が混在した状態になりがちです。
4つの条件カテゴリと特性
CAA で利用できる条件は大きく 4 カテゴリに分類できます。
| カテゴリ | 代表的な条件例 | 使用できるモード |
|---|---|---|
| 場所(Location) | 社内 IP サブネット、国・地域ホワイトリスト | Basic / Advanced |
| デバイス健全性(Device) | 管理対象デバイス、OS バージョン、画面ロック・暗号化 | Basic / Advanced |
| 時間(Time) | 業務時間帯(曜日・時刻範囲)、期間指定 | Advanced(CEL)のみ |
| リスクシグナル(Risk) | EDR のリスクスコア・コンプライアンス状態(カスタム属性経由) | Advanced(CEL)のみ |
Basic mode は管理コンソールの GUI から設定できます。一方、時間条件とリスクシグナルは Advanced mode(CEL: Common Expression Language)で記述する必要があり、設定の複雑度が上がります。
デバイス健全性の条件に含まれる「管理対象デバイス」の判定には、Endpoint Verification(エンドポイント検証)が前提となります。Endpoint Verification は Chrome 拡張またはシステム管理ポリシーによってデバイス情報を Google Workspace に報告する仕組みです。デバイス状態の同期には最大で 1〜2 時間かかることがあるため、デバイス系条件を AND に組み込む際はこの同期ラグを前提にした設計が必要です。「デバイスを登録したばかりなのにブロックされる」という問い合わせの大半は、このラグが原因です。
EDR(Endpoint Detection and Response:エンドポイント検出・対応ツール)のリスクシグナルを CAA で参照するには、EDR から Google Workspace のカスタムユーザー属性にデータを連携する仕組みを別途構築する必要があります。ネイティブ機能として組み込まれているわけではなく、追加の設計と実装コストがかかる点は把握しておく必要があります。
CAA アクセスレベルの複数条件:AND/OR の設計判断
CAA アクセスレベルでは、同一のアクセスレベル内で複数の条件を AND または OR で結合できます。また、1 つのサービスに複数のアクセスレベルを割り当てた場合、ユーザーがいずれかのアクセスレベルを満たせばアクセス許可(OR)として動作します。これは公式ドキュメントで「a logical OR of the access levels in the list」と明記されています。
設計判断の基準を表でまとめます。
| パターン | 実現方法 | 制御の強さ | 向いている場面 |
|---|---|---|---|
| 条件A AND 条件B | 同一アクセスレベル内で AND 結合 | 強(全条件が必要) | 機密データ・管理者操作 |
| 条件A OR 条件B | 同一アクセスレベル内で OR 結合 | 緩(どちらかで OK) | 複数の正当な接続経路を許容する場合 |
| (A AND B) OR C | アクセスレベルを 2 つ用意してサービスに割り当て | 中間 | 「社内 IP」または「リモート+管理対象デバイス」 |
| A AND B AND C | 同一アクセスレベル内で 3 条件 AND | 最強 | 特権アカウント操作・最重要機密データ |
AND を増やすほど制御は堅固になりますが、正規ユーザーが意図せずブロックされる誤検知リスクも上がります。設計の基本軸は「守りたいリソースのリスクレベルに応じて AND の数を決め、多様な接続パターンに対応するために OR を使う」という考え方です。
具体例として、100 名規模の企業で「Google Vault へのアクセスを情報システム担当者に限定したい」ケースを考えます。想定する正当な接続経路は、オフィス内 PC からの接続と、在宅勤務時の管理対象デバイスからの接続の 2 パターンです。この場合、「社内 IP からのアクセス」を条件 A、「管理対象デバイス AND 社外 IP」を条件 B とした 2 つのアクセスレベルをサービスに割り当てることで、(A) OR (B) の構成が成立します。単一の OR 条件よりも意図が明確で、監査ログでの分類もしやすくなります。
見落としがちな落とし穴として「意図しない OR の緩み」があります。複数のアクセスレベルを同一サービスに割り当てると自動的に OR になるため、「厳格な新しいアクセスレベルを追加したつもりが、緩い旧レベルがそのまま残っていてセキュリティが下がった」という設定ミスが起きやすいです。条件を追加・変更する際は、既存のアクセスレベル割り当てを棚卸ししてから着手することが重要です。
条件追加の段階展開ロードマップ
単一条件から複合条件へ移行する際は、4 段階で段階的に進めることを推奨します。
Phase 1: 場所(Location)から始める
IP 制限または国・地域制限から始めるのが最もシンプルです。誤検知の判定が直感的で、例外対応(VPN 利用者の追加など)も管理しやすく、CAA の挙動に慣れるのに適しています。部門単位またはサービス単位でパイロット適用し、運用フローを確認するのが安全です。アクセスレベルの設計と例外グループの管理手順をドキュメント化しておくことが、後続フェーズの工数削減につながります。
Phase 2: デバイス健全性を AND で追加する
Phase 1 の Location 条件に、管理対象デバイスや OS バージョン条件を AND で組み合わせます。「社内 IP からのアクセス」だけでなく「社内 IP かつ管理対象デバイス」に絞ることで、第三者が社内ネットワークに接続しても Google Workspace へのアクセスを制限できます。BYOD が存在する場合は、BYOD 向けに別のアクセスレベルを作って OR で並べる設計か、アクセス先アプリを限定した別ポリシーを検討します。Endpoint Verification の同期ラグを考慮し、モニター期間を 2〜4 週間は取ることを推奨します。
Phase 3: 時間条件を Advanced mode で追加する
業務時間外(深夜帯・土日)のアクセスを制限したい場合、Advanced mode(CEL 式)に移行して時間条件を追加します。Phase 2 が安定稼働してから着手するのが無難です。グローバルチームや海外出張がある環境では、タイムゾーン設定と例外グループの設計を同時に検討します。なお、Basic mode で構築した既存のアクセスレベルに時間条件を追加する場合は CEL 式への書き直しが必要になるため、既存ポリシーへの影響範囲を先に確認します。
Phase 4: EDR リスクシグナルを組み込む
EDR ツールが提供するリスクスコアやコンプライアンス状態をカスタムユーザー属性として連携し、Advanced mode(CEL 式)で参照する設計です。デバイスのリアルタイムな脅威状態をアクセス判断に組み込めます。ただし、EDR 側の API 連携設計と属性の定期更新の仕組みが別途必要で、実装コストは高くなります。Phase 3 まで安定した後のステップとして位置づけることを推奨します。
モニターモードを使って安全に展開する方法
CAA にはアクセスレベルを「モニターモード」で適用する仕組みがあります。このモードでは実際にアクセスをブロックせず、「ポリシーが有効だった場合の影響範囲」を監査ログに記録します。複合条件を追加する際は、以下の流れで進めることが基本です。
- 新しいアクセスレベルをまずモニターモードで適用する — 2 週間〜1 ヶ月程度、実際のアクセスパターンを監査ログで観察します
- ブロックされるはずのアクセスを分類する — 「正規ユーザーが誤ってブロックされる(誤検知)」と「本来ブロックすべき不正アクセス」を区別します
- 例外グループを確定してから Active モードへ切り替える — 除外すべきグループの確定を先に終わらせることが、ロックアウト防止の鉄則です
条件を 1 つ追加するたびにモニター期間を挟む習慣を持つことで、ユーザーへの突然のロックアウトを防げます。特に Phase 2 から Phase 3 へ移行する際(Basic mode から Advanced mode への移行を伴う場合がある)は、モニター期間を長めに取ることを推奨します。
モニターモード中の監査ログは、管理コンソールの「監査と調査」セクションから確認できます。CAA 関連のアクセスイベントをフィルタで絞り込み、誤検知候補のアクセスパターンを抽出します。この分析を週次で定例化しておくと、「条件を追加しても問題なさそうか」という判断が担当者に依存しにくくなり、引き継ぎ時の属人化も防げます。
複合条件で陥りやすい設計ミス
AND の連鎖による誤検知の増加
AND 条件が 3 つ以上になると、いずれか 1 つが判定エラーを起こしただけで正規ユーザーがブロックされます。Endpoint Verification によるデバイス状態の同期には最大で 1〜2 時間かかることがあるため、AND に含める条件は「安定して判定できる条件」に絞ることが重要です。実務上は AND を最初は 2 条件までに抑え、安定稼働を確認してから 3 つ目を追加する段階アプローチが無難です。
時間条件のタイムゾーン設定ミス
Advanced mode の時間条件(CEL 式)では、タイムゾーンを関数の引数として明示的に指定します。"Asia/Tokyo" を正しく指定しない場合(例: "UTC" を指定するなど)、実際の日本標準時から 9 時間ずれた時刻で条件が評価されます。JST での制限を意図する場合は、CEL 関数の引数に "Asia/Tokyo" を必ず指定します。グローバルチームが存在する組織や夏時間のある地域との業務がある場合は、設計段階でタイムゾーン要件を明文化しておくことで、設定ミスを防げます。
EDR 属性の更新遅延がアクセスに影響する
Phase 4 の EDR リスクシグナルをカスタム属性で参照する設計では、EDR からカスタム属性への更新頻度がアクセス判断の鮮度に直結します。更新頻度を高くしすぎると API 呼び出し上限の影響が出て、低くしすぎると脅威検知からアクセス遮断までのラグが生まれます。設計段階で更新間隔とリスク許容レベルのバランスを定義しておくことが必要です。
条件の OR が意図せず緩い設定になる
前述した通り、複数のアクセスレベルを同一サービスに割り当てると OR で動作します。ポリシーの棚卸し時には「どのアクセスレベルがどのサービスに割り当てられているか」を一覧で確認し、不要な古いアクセスレベルが残っていないかチェックする習慣が必要です。3 ヶ月に 1 度を目安に定期棚卸しのスケジュールを設定しておくと、設定の形骸化を防げます。
まとめ
CAA の複合条件設計は、「AND/OR の使い分けルール」と「条件を追加する順序」の 2 点を押さえることで、ゼロトラスト環境を段階的に強化できます。
設計の原則は単純です。場所(Location)から始め、デバイス健全性を AND で追加し、安定したら時間条件、最終段階で EDR リスクシグナルを組み込む——この順序を守ることで、運用コストと誤検知リスクを抑えながら制御精度を高められます。
AND 条件を増やすことは制御を堅固にする半面、例外設計の複雑さも増します。モニターモードで実際の影響範囲を確認しながら進めることで、正規ユーザーへの影響を最小化できます。
CAA の複合条件設計はゴールではなく、ゼロトラスト成熟度を育てていくプロセスです。どのフェーズから始め、どの順序で条件を追加するかを決めることが、情シスとしての最初の設計判断になります。セキュリティポリシーを「設定して終わり」にせず、モニターログを定期的に確認しながら条件を精緻化していく運用サイクルを組むことが、長期的な成果につながります。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。