はじめに
当記事は、先日開催された Google Cloud Next Tokyo 2025 の中で行われたセッションのレポートとなります。
タイトル:Chrome Enterprise Premium で実現するゼロトラストモデル事例 ~運用セキュリティと開発アジリティの両立~
登壇:パーソルキャリア株式会社 砂川 鉄雄氏、戸田 尚希氏
セッション概要
本セッションでは、Chrome Enterprise Premium (CEP) を活用して「開発アジリティ」と「運用セキュリティ」という相反する課題を解決しようとしているのか、その具体的な取り組みについてご紹介いただきました。
従来の境界型防御モデルについての課題
従来の境界型防御を中心とした環境では、以下のような課題があるとのことです。
- 境界前提の制御
- 内部ネットワークが安全という前提のため、SaaS利用時のIPアドレス制限やリモートワーク時にはVPNを介して社内ネットワークへの接続が必須となる。
- 生産性阻害
- インターネットアクセスについて、閲覧可能なWebサイトなどに制限が入ることで情報収集活動が阻害される。
- 機密情報の管理
- 顧客情報などの機密データが個人のPCに保存されるリスクがある。
- ソフトウェア導入の非効率性
- エンジニアが必要とするソフトウェア(コンテナやVMなど)の導入にも煩雑な承認プロセスが必要で、開発のデリバリーが遅れる原因となる。
新環境および新たなる課題
上記課題を解決するため、「ゼロトラストセキュリティモデル」を基盤とした新環境の整備を検討を進められたとのことです。
この新環境では、Google Workspace、Google Cloud、およびPC上のChromeブラウザをベースとし、データをできる限りローカルに置かずクラウド上でのみ取り扱い、開発者の生産性向上とセキュリティとアジリティの両立を目標としています。
しかし、この新しいコンセプトでは「自由と統制のジレンマ」という新たな課題が発生します。自由な環境では、デバイスの信頼性をどう担保するか、また、機密情報が意図せずダウンロード・アップロードされないかというセキュリティリスクへの対応が必要となるためです。
CEPの導入およびCAAとDLPの活用
「自由と統制のジレンマ」を解決するため、Chrome Enterprise Premium (CEP)を導入し、CEPは主に以下の2つの機能で課題解決に貢献したとのことです。
- Context-Aware Access (CAA: コンテキストアウェアアクセス)
- 機能概要
- アクセスしてくるユーザーの様々な状況(デバイスの信頼性、アクセス地域、デバイスのセキュリティ状態など)を評価し、アクセスの可否を動的に判断。
- 導入効果
- 主要なサービスへのアクセスを、企業が管理する「信頼できるデバイス」のみに限定することで、IDとパスワード認証のみに依存していた状態から脱却。
- 設定ステップ
- デバイスコンテキストの収集→アクセスレベルの定義→CAAポリシーの設定。
- 機能概要
- Data Loss Prevention (DLP: データ損失防止)
- 機能概要
- ユーザーが機密情報を許可された範囲外へ共有しようとした際に、その操作を検知し、ブロックや警告を行うことで情報漏洩を未然に防止。
- 導入効果
- 機密情報の転送をリアルタイムで制御できるようになり、アラートセンターへの集約により、機密情報の利用状況の全体像を把握可能とした。
- 設定ステップ
- ルールの作成→アクションの設定→アラートとレポートの設定。
- 機能概要
- その他の構成
- MDM
- 企業が支給したデバイスを一元的に管理し、必要なセキュリティ対策の導入や設定を強制。
- EDR
- デバイス上で外部からの攻撃や不正なソフトウェアの実行を防止。
- CASB
- 特定のウェブサイトへのアップロードやダウンロードを制限し、利用するクラウドサービスのアクセス範囲を企業が管理する範囲に限定。(自社の Google Cloud、Google Workspace)
- SSO
- 複数のSaaSへのアクセス認証をGoogle WorkspaceからのSSOに絞ることで、認証の強度を向上。
- Google Workspaceへの認証は物理的なセキュリティキーによるMFA認証を必須とすることで、信頼デバイスからのアクセスを担保。
- 複数のSaaSへのアクセス認証をGoogle WorkspaceからのSSOに絞ることで、認証の強度を向上。
- MDM
運用の中で直面した課題
CEPの導入後、運用の中で課題が発生したとのことで、共有いただきました。
- CAAにおける課題
- 事象
- Google Cloud Shell や GAS (Google Apps Script) といった仮想基盤からのアクセスが「信頼できないデバイス」と誤認され、ブロックされる事象が発生。
- Google Cloud Shell や GAS (Google Apps Script) といった仮想基盤からのアクセスが「信頼できないデバイス」と誤認され、ブロックされる事象が発生。
- 対策
- Google認証も CAA の対象であったため、CAA 適用を部分的に除外する設定を行うことで解決。
- Google認証も CAA の対象であったため、CAA 適用を部分的に除外する設定を行うことで解決。
- 事象
- DLPにおける課題
- 業務フローによっては機密情報を扱う必要があり、DLPの適用を動的に除外したいケースがある
- 宛先に指定可能なメールアドレス数についてのルールを定めていることにより、Google カレンダーからの会議招待(多数のメールアドレスを含む)がDLPの検出対象となり、招待が送れずにブロックされる想定外の動作が発生。
- 動的なブロックの実現や柔軟な制御が今後の課題となっている。
- 業務フローによっては機密情報を扱う必要があり、DLPの適用を動的に除外したいケースがある
さいごに
CEP の CAA と DLP によって従来の境界型防御モデルとは異なるゼロトラストモデルでの制御の実現が可能になるということがイメージできました。また、CAA 設定の際に直面した課題を共有いただいたことで、実際に CAA を設定する際の考慮事項についても把握できました。DLP の動的かつ柔軟な制御については今後に向けた課題があるとのことで、実際に導入する際はこの部分の運用や制御の検討が重要になると思いました。