【Google Cloud Next Tokyo 2025】Chrome Enterprise Premium で実現するゼロトラストモデル事例～運用セキュリティと開発アジリティの両立～：講演レポート

Google Cloud Next Tokyo 2025とは？

Google Cloud Next は、Google Cloud が主催する大規模なオンサイトイベントです。2025年8月5(火)と6日(水)の2日間、東京ビッグサイトで開催され、オンラインでのライブ配信も行われます。

本イベントでは、最新のクラウド技術や生成 AI ソリューションが紹介され、業界リーダーによるセッション、革新的なデモ、ネットワーキングの機会を通じて、Google Cloud が実現する未来を体験可能です。

セッション情報

セッション名	Chrome Enterprise Premium で実現するゼロトラストモデル事例～運用セキュリティと開発アジリティの両立～
セッション概要	私たちパーソルキャリアのサービス共通基盤グループでは、エンジニアが開発を行うための基盤を提供・管理しています。エンジニアはサービスの開発および本番環境の運用を担当しており、開発の迅速さや自由度を確保するため、エンジニア向け端末には管理者権限を付与しています。端末にはマルウェア対策、モバイルデバイス管理（MDM）、Google Workspace の外部共有制御などを実施していましたが、開発者によるデータの移動に関してはシステム的な制御を行っておらず、ルールの徹底や意識づけによる対応にとどまっていました。端末の管理者権限剥奪や監視型ソフトウェアの導入も検討されましたが、エンジニアが端末を自由に扱える環境や心理的安全性を維持したまま、より高度なセキュリティ課題の解決を目指していました。そこで私たちは、端末の自由度を保ったまま、Google Workspace（GWS）や Google Cloud からの機密データの外部流出を防止し、かつ端末のアジリティを低下させない施策を取りました。具体的には、Google Workspace による認証・認可と Chrome Enterprise Premium の Context-Aware Access を組み合わせ、信頼されたデバイスとブラウザのみを利用可能とする仕組みを導入しました。さらに、DLP（データ損失防止）を活用し、データ移動の制御を徹底しました。その結果、端末の自由度や開発の迅速性を損なうことなく、機密データの漏洩リスクを大きく低減できました。本セッションでは、この取り組みの背景、具体的な手法、得られた知見を事例として詳しくご紹介します。

セッション名

Chrome Enterprise Premium で実現するゼロトラストモデル事例～運用セキュリティと開発アジリティの両立～

セッション概要

私たちパーソルキャリアのサービス共通基盤グループでは、エンジニアが開発を行うための基盤を提供・管理しています。エンジニアはサービスの開発および本番環境の運用を担当しており、開発の迅速さや自由度を確保するため、エンジニア向け端末には管理者権限を付与しています。

端末にはマルウェア対策、モバイルデバイス管理（MDM）、Google Workspace の外部共有制御などを実施していましたが、開発者によるデータの移動に関してはシステム的な制御を行っておらず、ルールの徹底や意識づけによる対応にとどまっていました。端末の管理者権限剥奪や監視型ソフトウェアの導入も検討されましたが、エンジニアが端末を自由に扱える環境や心理的安全性を維持したまま、より高度なセキュリティ課題の解決を目指していました。

そこで私たちは、端末の自由度を保ったまま、Google Workspace（GWS）や Google Cloud からの機密データの外部流出を防止し、かつ端末のアジリティを低下させない施策を取りました。具体的には、Google Workspace による認証・認可と Chrome Enterprise Premium の Context-Aware Access を組み合わせ、信頼されたデバイスとブラウザのみを利用可能とする仕組みを導入しました。

さらに、DLP（データ損失防止）を活用し、データ移動の制御を徹底しました。その結果、端末の自由度や開発の迅速性を損なうことなく、機密データの漏洩リスクを大きく低減できました。

本セッションでは、この取り組みの背景、具体的な手法、得られた知見を事例として詳しくご紹介します。

セッション詳細

このセッションでは、Chrome Enterprise Premiumを導入により、運用セキュリティと開発のアジリティをいかにして両立させたかが語られました。この取り組みは、従来の境界型防御の限界を超え、ゼロトラストモデルを実現するための具体的なステップを示しています。

本セッションでは、特にContext-Aware AccessとDLPの活用に焦点を当て、その導入効果と実践から得られた知見が共有されました。

開発現場が直面した、生産性とセキュリティのジレンマ

登壇企業では、お客様から預かる情報を最優先で保護する一方、開発エンジニアの生産性をいかに向上させるかという課題に直面していました。従来の境界型防御モデルは、セキュリティは強固なものの、エンジニアの業務効率を低下させる側面がありました。

例えば、社内ネットワークを安全とみなす考え方から、リモートワークではVPN接続が必須となり、特定のウェブサイトへのアクセスが厳しく制限されていました。エンジニアが必要とする技術情報が掲載された個人のブログやSNSへのアクセスも難しく、情報収集の妨げとなるケースがありました。

また、PCにソフトウェアを導入する際には、都度管理者の承認を得て権限を昇格させる必要があり、開発のスピード感を損なう一因となっていました。

新たな開発環境のコンセプトと、そこに生まれた課題

こうした状況を打開するため、同社は新たな開発環境のコンセプトを策定しました。

コンセプト	説明
ゼロトラストセキュリティモデル	内部ネットワークに依存せず、「すべてを信頼しない」ことを前提としたセキュリティを構築する。
クラウド中心のデータ管理	データは原則としてローカルに置かず、クラウド上で管理・操作することで、デバイスへの依存をなくす。
開発者の生産性向上	ソフトウェア導入やウェブサイトアクセスの自由度を高め、セキュリティとアジリティを両立させる。

しかし、この新しい環境は「自由と統制」という新たなジレンマを生み出しました。開発者に高い自由度を与えると、それに伴うセキュリティリスクへの対策が不可欠です。

信頼性が担保されていないデバイスからのアクセスや、意図しない機密情報のダウンロード・アップロードをいかに防ぐか。利用者のリテラシー向上だけに頼るのではなく、仕組みとして情報資産を保護する必要がありました。この課題に対する解決策として導入されたのが、Chrome Enterprise Premiumでした。

Chrome Enterprise Premiumが実現する、柔軟で効率的な制御

Chrome Enterprise Premiumの導入により、これまで課題となっていた部分を埋め、より柔軟で効率的なセキュリティ制御が可能になりました。特に中心的な役割を果たしたのが、Context-Aware Access (CAA) と Data Loss Prevention (DLP) という二つの機能です。

Context-Aware Access (CAA) による動的なアクセス認可

CAAは、ユーザーの様々な状況、つまりコンテキストを評価し、アクセスの可否を動的に判断するセキュリティの仕組みです。これにより、IDとパスワードによる認証だけでなく、アクセス元の状況に応じたきめ細やかな制御が実現します。

評価されるコンテキストの例	説明
信頼できるデバイスか	企業が管理・配布した正規のデバイスからのアクセスか。
アクセス元の地域は適切か	日本国内からのアクセスか、それとも予期せぬ国からのアクセスか。
デバイスのステータスは安全か	OSやブラウザのバージョンは最新か、セキュリティソフトは正常に動作しているか。

これらのコンテキストを満たさないアクセスに対しては、アクセスをブロックしたり、警告を表示したりすることが可能です。これにより、たとえIDとパスワードが漏えいしたとしても、信頼できない環境からの不正アクセスを水際で防ぐことができます。

CAAの導入は大きく3つのステップで進められました。

ステップ	内容
1. デバイスコンテキストの収集	デバイスに登録トークンを配布し、Chromeブラウザとデバイスを紐づけて情報を収集できるようにする。
2. アクセスレベルの定義	収集したコンテキスト情報をもとに、「どのような条件を満たせばアクセスを許可するか」というルールを定義する。
3. CAAポリシーの設定	定義したアクセスレベルを、Google CloudやGoogle Workspaceなどの各サービスに適用する。

この実装により、同社が管理していない個人所有のデバイスなどからのアクセスをブロックすることに成功しました。

CAA導入後、想定外の事象が発生

しかし、導入後には想定外の事象も発生しました。Google CloudのCloud ShellやGoogle Apps Script (Apps Script) のような仮想基盤から実行された操作が、CAAによって「信頼できないデバイスからのアクセス」と誤認され、ブロックされてしまったのです。調査の結果、これはCAAがアクセス元を物理的なデバイスではなく、仮想基盤そのものと認識したために発生したと判明しました。

この問題は、特定のクライアントアプリケーションからの認証をCAAの適用から除外する設定を追加することで解決できました。これは、同様の構成を検討する多くのエンジニアにとって価値ある知見と言えるでしょう。

Data Loss Prevention (DLP) による情報漏えい対策

DLPは、ユーザーが機密情報を許可なく外部と共有しようとした際に、その操作を検知してブロックや警告を行うことで、情報漏えいを未然に防ぐ仕組みです。ファイルの内容をリアルタイムでスキャンし、あらかじめ定義されたルールに基づいてアクションを自動で実行します。

例えば、「メールアドレスが10件以上含まれるファイル」を機密情報と定義し、そのようなファイルのダウンロードや外部へのアップロードを強制的にブロックするといった制御が可能です。

DLPの導入ステップも、CAAと同様にシンプルです。

ステップ	内容
1. DLPルールの作成	何を機密情報とみなすか（例: メールアドレスの件数、特定のキーワードなど）を定義する。
2. アクションの設定	ルールに違反した場合に、ブロック、警告、監査ログの記録といった、どの対応をとるかを設定する。
3. レポートの設定	アラートを管理者に通知し、インシデント対応後の分析に活用できるようレポートを集約する。

DLPの導入により、機密情報がどのように扱われているかを可視化し、ポリシーに反する操作を自動で制御できるようになりました。