Check Point マーケティング 大植です。
この記事について
Qiitaの読者層として、Web開発やSaaS開発に携わる方々とその情シス/IT管理者が多いことを前提に、「Chromeの中で仕事が完結する会社」のセキュリティについて書いてみました。
ただし、クラウドセキュリティ領域（CNAPPやWAF等）ではなく、情シスに関わる視点を纏めてみます。
一般的なセキュリティ記事の多くは大企業向けで、Windowsを標準機として、ExcelやPowerPointで情報共有を行いつつ、ワークロードはSaaSに移行しはじめたハイブリッド環境を想定しています。
一方、スタートアップやWeb開発系の企業では、Chromeの中で仕事が完結している会社が多いのではないでしょうか。
以降、 「ブラウザOS化企業」 と呼ぶことにします。
ブラウザOS化企業の特徴
- Google Workspace、Slack、Notion、Figma、GitHub、Jira
- 経費や財務、人給などの機密情報は、多くは国産SaaSに保管
- AWS/GCP/Azureのコンソールもブラウザ経由
- オンプレサーバーなし、VPNなし
- 気づけばChromeタブの中で仕事が完結している
そんな企業です。
「ブラウザOS化企業は、EDR採用の優先順位がエンタープライズと比較すると低い」
ゼロトラストとSSE
多くがリモートワークだし、オンプレミスのサーバーもないので、VPNはないし、境界セキュリティ（ファイアウォール等）は必要ないという考えの方もいると思います。
私の前職のグローバル企業でも、Mac、Google Workspace、Slack、SaaSオンリーの環境で、オフィスがない国のエンジニアもたくさんいました。ZTNA＋Okta＋Yubikeyを利用していました。
ブラウザOS化企業には、フルスタックのSASEが必要とは思いません。拠点間通信やオンプレミス環境を持たないSD-WANやフル機能のFWaaSは過剰投資です。
SASEの中でも、SSEと呼ばれる ZTNA（ゼロトラストネットワークアクセス）とSWG、メッシュ化されたグローバルPoPは必要です。
ZTNA
繋ぎっぱなしを辞める流れの中でZTNAです。VPNはレイヤー2/3レベルでトンネルを構築するため、廃止しようという議論になっていますが、パブリッククラウドであってもSaaSであっても繋ぎっぱなしは避ける流れです。
空港で例えてみるとIdPやMFAで「パスポート確認」を行い、デバイスポスチャー管理で「手荷物チェック」は行えますが、ZTNAを採用することでパスした後に特定の目的地（SaaS）への接続を実施する「送迎バス」の役割を果たします。
一度入国してしまえば何でもできる「フリーパス」の時代は終わりました。
ログイン時だけ確認するのではなく、ログイン後も行動を監視し、異常があれば即座にアクセスを遮断する。このZTNAの採用が、現代のセキュリティにおける不可欠な要素となっています。
回想：2022年8月「Oktapus」事件の教訓 - MFAは突破される
約130以上の組織を標的とした大規模なフィッシング・キャンペーンの名称で、私が当時在籍していた会社もZTNAを利用していましたが、その標的となりMFAは突破されたので、今でも強い印象が残っています。
「リアルタイム・フィッシング」と呼ぶべき攻撃でした。
まずメールで攻撃対象の会社ロゴが掲載された「偽のOktaログインサイトに誘導」し、従業員にID・パスワードを入力させます。
攻撃者は裏側でリアルタイムに本物のOktaサイトに入力し、SMS経由のMFAコードを発行。SMSを受け取った従業員が偽サイトにMFAコードを入力することで、MFAも突破されました。
テクノロジー企業2社(Twilio社とCloudflare社)が詳細を公表しましたが、明暗が分かれました。当時なのでSMSを利用したMFAを両社とも採用していましたが、一方はMFAだけたったためシステムを侵害され情報漏えいを報告しました。
もう一方は物理パス（Yubikey）を採用していたことで認証情報の漏えいは起きたものの他システムへの侵入を防ぐことができました。
物理パスの運用は苦労することも多いため、MFAだけでなく「デバイスポスチャー（端末状態）管理」と連携させて、UEM（JamfやIntune）との連携で「会社支給の管理PC」からのアクセスに制限し、EDRと連携することでセキュリティリスクのあるデバイスからのログインを自動で防ぐ設定を行うことが多いと思います。
IDaaS
ブラウザOS化企業では、利用するSaaSが増えやすく、いわゆるSaaSスプロールが課題になりがちです。
Google Identity利用の段階から、利用状況の可視化やアクセス統制を目的として、比較的早い段階からIDaaSを採用する企業が多い傾向にあります。
セキュリティ強化目的に海外製を採用することもあれば、国産SaaSへのシングルサインオン等を目的に国産IDaaSの採用という考えもあると思います。
SaaS Security - CASB or SSPM
ブラウザOS化企業では、SaaSスプロール課題に対しては、「OAuth / SaaS連携」の可視化と制御を求めるセキュリティも必要になってきています。
- CASB (Cloud Access Security Broker) は10年以上前に定義されましたが単一で市場を作れず、現在はSASEのSSEを構成する機能として定義されています。
-
SSPM (SaaS Security Posture Management) は、SaaSの設定ミスを見つけ修正するという機能として発展してきました。
どちらも「OAuth/SaaS連携」の可視化や制御といった機能実装が増え、SSE/CASBのようなインライン型のOAuth管理（通信を横取りして可視化）なのか、SSPMのようなAPI型のOAuth管理（設定と連携をAPIから可視化）なのか、実装方法や効果は異なるものの、このニーズは確実に高まっています。
回想：2025年8月 Salesloft/Driftの「OAuthトークン窃取」事件
弊社もSalesLoftを利用していましたが、Salesforceへの侵害は発生せず、ただしSalesLoftツールが長期間使えなかった事で、この事件は強く記憶にあります。
ZTNAを利用しているであろうZscaler、Palo Alto Networks、Cloudflare、Tanium、Proofpointなどを含む700社以上の企業に被害が及びました。
攻撃の流れはこうです。まず、Salesloft（正確には同社が買収したDrift社）の開発環境（GitHub）への不正アクセスが2025年3月から6月にかけて行われました。攻撃者は開発環境から得た情報を足がかりにクラウド基盤へ侵入を拡大し、SalesforceやGoogle Workspaceと連携するために顧客が発行した「OAuthリフレッシュトークン」を窃取。
そして盗んだトークンを使って8月8日から18日にかけてデータを一斉に搾取しました。主な標的はSalesforce上の顧客データでした。
「ZTNAは人間の入口を守る」のに有効ですが、アプリ同士のやり取りであるAPI/OAuthがノーガード だったことがこの事件の原因でした。
- SaaSとAPI接続の管理： 「SSPMを採用しておくこと」で回避できたと言われています。
-
SaaS連携に最小権限化： OAth連携時のアクセス許可を最小限に制限が重要です。
SASE/SSE（固定IPのプライベートGW設定）からSalesforceにアクセスを制限していた企業は回避できたとも言われてます。
イメージ図： SASE、SSPMはクラウドサービスですが、次はオンデバイスについてです。
セキュリティの「クラウド集中」から「ブラウザ分散」へ
SASEのトレンドの中には、GartnerがSSEを提唱する以前の「SD-WANを含む包括的なSASE」と、リモートアクセスを主とした「SSE」の流れがありました。そして今、次の流れが生まれつつあります。
クラウド上のSASEに全てのセキュリティ機能を集約し続けるべきなのか——この問いが浮上しています。
通信のほとんどがTLSで暗号化されている現在、すべてを復号・検査・再暗号化するプロセスは、遅延とコストの両面で負担が大きくなっています。
特に開発者が多用するクラウドIDEやリアルタイムコラボレーションツールでは、遅延がユーザー体験を損なう要因にもなりえると言われて、SASE/SSEが敬遠されたりします。
Check Point Harmony SASEでは、オフィス・拠点に設置する UTM+SD-WAN は「ローカルブレイクアウト」することでSASEの負荷を下げるだけでなく、エージェントアクセス（オンデバイス）においても「ローカルブレイクアウト」することでSASE/SSEの負荷を軽減させ、高いユーザー体験を維持できる工夫をしています。
エンタープライズブラウザ
この流れの中で注目されているのが「エンタープライズブラウザ」です。
国内では CACHATTO がセキュアブラウザとして人気ですが、 エンタープライズブラウザとして Island、Talon（Palo Altoが買収）、SURFなどのベンダーがでてきています。
代表的な製品はどれもChromiumベースの専用セキュアブラウザ内にDLP、脅威防御、セッション隔離などの機能が組み込まれています。
ブラウザをリプレイスし、セキュリティ実装製品にすることで、SaaSへのアクセス制御からデータ漏洩防止まで、一貫したポリシーを適用できます。
Check Pointでは、SURF Security社との技術提携により、Check Point Enterprise Browserを2025年9月から開始しています**。
Gartnerも「エンタープライズブラウザが、管理・非管理デバイスでの生産性とセキュリティのコアプラットフォームになる」と予測しており、大企業を中心に導入が進んでいます。
しかし、ブラウザOS化企業——特に開発者を多く抱える企業には、別の現実があります。
開発者にとってのChromeは開発環境
ブラウザOS化企業には、このトレンドが通用しないケースがあります。
Chrome DevToolsはネットワーク監視、パフォーマンス分析、JavaScriptデバッグの標準ツールであり、Firebase、Vercel、GitHub等のダッシュボードとの統合、各種開発用拡張機能のエコシステムが揃っています。
蓄積されたワークフローを捨てることは容易ではありません。エンタープライズブラウザは同じChromiumベースとはいえ、既存の拡張機能がすべて動作する保証はなく、細かな挙動の違いがデバッグ作業に影響を与える可能性もあります。
「明日から専用ブラウザを使ってください」と言われても、開発者にとっては生産性の低下に直結するため、受け入れられる可能性は低いでしょう。
ブラウザ拡張型セキュリティ
そこで選択肢となるのが、「ブラウザ拡張型セキュリティ」です。
既存のChromeやSafariをそのまま使いながら、セキュリティ拡張機能を追加するアプローチです。
エンタープライズブラウザほどの隔離性能はありませんが、開発者の生産性を維持しながら、ブラウザレベルでのリアルタイム脅威防止やデータ漏洩防止（DLP）を実現できます。
代表的なベンダーとしては、LayerX Security（イスラエル）、Seraphic Security、そしてCheck Point Harmony Browseがあります。
特徴： Harmony Browseのゼロデイフィッシング
Chrome、Edge、Firefox、Safari、Braveに対応。ユニークな機能としてZero-Phishing技術は、ユーザが認証情報を入力する直前（ログインにカーソルを合わせたタイミング）に、サイトのソースコード解析を行い、ブランドなりすまし検知を行い、Domainに関わるセキュリティを評価するなど、未知（作りたて）のフィッシングサイトであってもリアルタイムで検知・ブロックする機能を提供しています。
エンタープライズブラウザとブラウザ拡張型セキュリティは、どちらが優れているという話ではなく、対象者によって使い分けることがポイントです。
管理デバイスを使う正社員や開発者にはブラウザ拡張型で生産性を維持しながらセキュリティを追加し、BYODや委託先など非管理デバイスからのアクセスにはエンタープライズブラウザで隔離環境を提供する——このような組み合わせが現実的な解になります。
生成AIの安全な利用を促進するセキュリティ
開発者やユーザーが外部の生成AIサービスを利用する際の視点におけるセキュリティ for AIの分野についてです。
ブラウザOS化企業では、外部の生成AIを多用しており、既に「生成AI利用のガイドライン」や社内ルールの整備を進めている方々も多いと思います。
ユーザー起点に生成AI向けセキュリティを考えれば以下が上げられます。
- アクセス制御（許可・禁止・条件つき）
- シャドーAIの可視化
- プロンプトやアップロードに対するDLP
- ログ・証跡・ガバナンス
※外部脅威「プロンプトインジェクション」などの脅威対策はここでは扱いません。
実装の場所は様々
SASEベンダーは、全てをクラウド化しているためSASE内にGenAIセキュリティも実装。
エンタープライズブラウザベンダーは、ブラウザ側に実装します。
Check Pointは、Harmony SASEを提供しますが、GenAI保護はHarmony Browseに実装です。
エンドポイントセキュリティベンダーの実装は確認が必要です。エンドポイントセキュリティが行うファイルや端末の振る舞い監視とは異なるため、純粋なエンドポイントセキュリティの拡張とは異なります。
デモ： GenAI Protect - センシティブデータ保護
開発者がChatGPTに上で、うっかり、aws_secret_key をコピーペーストするミスです。
マスクをかけて [Credentials]に変換 、DLP（データ漏洩防止）デモです。
メールセキュリティ
上記に書いてきた内容が、今どきの 「Webに関わるセキュリティ」 とすれば、攻撃ベクターとしてもう一つの重要なポイントは、メールです。以前の記事にまとめています、ご参照ください。
Google Workspaceでも同じことが言える内容です。
追記 - 簡易の脅威インテリジェンスサービス
開発会社が利用するツールの数は、非常に多くなります。それらベンダーの一つ一つが情報漏えいを起こしたか把握することは容易ではありません。
Harmony Email & Collaboration セキュリティのオプションの一つにおいて、ダークWeb上に、従業員のメールアドレスとパスワードの組み合わせが落ちていないか、監視と報告をするサービスは、開発系の企業の方に向いたリスク管理と考えます。
さいごに
「ブラウザOS化企業は、EDR採用の優先順位がエンタープライズと比較すると低い」 を前提にして記事を書きました。
この理由は、攻撃対象領域（アタックサーフェス）の違いにあります。
従来のエンタープライズでは、ローカルにインストールされたアプリケーション、ファイルサーバー、Active Directory、VPN接続など、エンドポイント上で動作する多くのコンポーネントが攻撃の入口となります。
EDRはこれらのエンドポイント上の挙動を監視し、不審なプロセスやファイル操作を検知することで価値を発揮します。
一方、ブラウザOS化企業では、業務のほとんどがブラウザ内で完結しています。ローカルにインストールするアプリケーションは最小限で、ファイルはGoogle DriveやDropboxに保存され、認証はIdP経由で行われます。
攻撃者がエンドポイントを侵害しても、そこには守るべき資産がほとんど存在しません。
つまり、ブラウザOS化企業にとっての本当のアタックサーフェスは 「ブラウザそのもの」 です。
フィッシングサイトへのアクセス、悪意ある拡張機能、OAuth認可の悪用、生成AIへの機密情報の貼り付け——これらはすべてブラウザ内で発生し、従来のEDRでは検知が困難です。
だからこそ、ブラウザレベルでのセキュリティ——ブラウザ拡張型セキュリティやエンタープライズブラウザ——が、ブラウザOS化企業にとってはより直接的な防御策となります。
限られたセキュリティ予算をどこに投資すべきか。その答えは、自社のアタックサーフェスがどこにあるかによって変わります。
ーークリスマス最後のコンテンツとして投稿させていただきました。Qiita Advent Calenderに非常に多くの投稿が集まりました。外部の方のご協力にも感謝いたします。関係者の皆様、Qiitaの読者の皆様、メリークリスマス！
★
/\
/ \
/ \
/ 🎄 \
/________\
/ \
/ 🎁 \
/______\
||
||
============
参考
-
The Evolution of Enterprise Browsers
https://softwareanalyst.substack.com/p/the-evolution-of-enterprise-browsers -
Hardening browser security with zero-trust controls
https://www.csoonline.com/article/4101173/hardening-browser-security-with-zero-trust-controls.html -
Bloomberg Quicktake: The Rise of the Secure Enterprise Browser
https://www.bloomberg.com/quicktake/the-rise-of-the-secure-enterprise-browser -
SaaS Security
https://www.grip.security/glossary/saas-security -
The Okta Incident: What We Know and What We’re Doing（Okutapas事件:Cloudflare）
https://blog.cloudflare.com/2022-okt-a-incident/ -
Security Incident Update（Okutapas事件:Twilio）
https://www.twilio.com/blog/august-2022-social-engineering-attack -
Okta Security Incident: 記事の抄訳（Salesloft / OAuth 関連言及）
https://scan.netsecurity.ne.jp/article/2025/09/09/53582.html
Check Point 働く環境のためのセキュリティ - Harmony Series