エンタープライズブラウザとは何か、そして現代の企業にとってセキュアなブラウジングがなぜ重要なのか

ウェブブラウザは、企業において最も影響力の大きい――そして最も保護が不十分な――アプリケーションへと、知らぬ間に変貌を遂げています。SaaSへのログイン、AIへのプロンプト入力、ファイルのアップロードやダウンロード、社内ポータルにアクセスする外部契約者――これらすべてが、ブラウザのタブ内で実行されています。ガートナーは、セキュアなエンタープライズブラウザについて、「エンドポイントやネットワーク層に後付けの制御機能を追加するのではなく、カスタマイズされたブラウザや既存のブラウザ用拡張機能を用いて、ネイティブなウェブブラウジング体験にエンタープライズセキュリティ制御を組み込む」と指摘しています。 しかし、依然として多くの組織はブラウザを単なる汎用ツールとして扱い、セッションレベルでのポリシー適用が行われていない一般消費者向けのChromeやEdgeに依存しています。このギャップこそが、今日のエンタープライズセキュリティアーキテクチャにおける最大の盲点となっています。

エンタープライズブラウザとは何ですか？

エンタープライズブラウザとは、ユーザーがWebアプリケーション、SaaSプラットフォーム、およびオープンインターネットを利用する際に、data loss prevention、アクセス制御、脅威の検知、セッション管理といった組織のポリシーを適用するために設計された、ブラウザレベルのセキュリティ制御機能です。

ガートナーは、SEBを「一元管理されるブラウザ拡張機能、およびオプションとしてフルスタックのカスタムWebブラウザを通じて、エンタープライズセキュリティポリシーと制御機能を提供するソリューション」と定義しています。 SEBは、Web、SaaS、およびプライベートアプリケーションに対するセキュリティとポリシーの適用を実現するほか、エンドポイントOSやネットワークレベルではなく、ブラウザを通じてブラウザの強化（ハードニング）を提供します。また、Webトラフィックのインライン復号を必要とすることなく、管理対象、軽微な管理対象、または非管理対象のデバイスからエンドユーザーがアクセスするWebアプリケーションデータの可視性、制御、および監査可能性を実現します。

実際には、エンタープライズ向けブラウザのカテゴリーには、根本的に異なる2つのアプローチが含まれています：

完全なブラウザ代替：Chrome や Edge を完全に置き換える Chromium ベースのアプリケーション。例としては、Island Enterprise Browser や Palo Alto Networks の Prisma Access Browser などがある。これらは、DLP、ID 統合、セッション制御機能を独自のブラウザに直接組み込んでいる。

既存のブラウザアプローチを強化する：ブラウザ拡張機能、 remote browser isolation、SWGによる検査、およびCASBポリシーを、従業員が既に使用しているブラウザに適用します。このアプローチにより、Chromeを完全に排除することなく、データ制御の実施、悪意のあるコンテンツのブロック、およびリスクのあるセッションの隔離を実現できます。

具体的な例を考えてみましょう。ある保険会社の損害査定担当者は、Chrome を使用して Salesforce や社内の引受ポータルにアクセスし、時折、案件メモを要約するために生成型 AI アシスタントを利用しています。 「置き換えモデル」の場合、IT部門は損害査定担当者に、専用ブラウザへの切り替え、ブックマークや拡張機能の再設定、そして一部の社内Webアプリで表示が異なる可能性があることを受け入れるよう求めることになります。一方、「既存のブラウザを維持するモデル」では、IT部門はリスクのあるURLや分類されていないURLに対してRBIを適用し、DLPを用いてAIツールへの個人識別情報（PII）の貼り付けを防止し、SWGを使用して悪意のあるダウンロードをブロックします。これらすべてを、損害査定担当者の日常業務のワークフローを変更することなく実現します。

今、セキュアブラウジングが重要である理由

3つの要因が相まって、ブラウザのセキュリティは「あれば望ましい」ものから、「運用上不可欠」なものへと変化しました。

1. ブラウザこそが新たな境界線である。ガートナーの2025年4月発行の「イノベーション・インサイト」では、ウェブブラウザが現代の企業向けアプリケーションの大部分における主要なアクセス手段であり、エンドポイントに依存しないエンタープライズセキュリティの制御ポイントを提供していると指摘されている。外回りの営業担当者がホテルのWi-FiネットワークからCRMにログインする場合、そのセッションと認証情報を盗み出すプロキシとの間を隔てるのはブラウザだけである。従来のファイアウォールやVPNコンセントレータは、そのセッションを一切検知しない。

2. ブラウザを標的とした攻撃が急増している。 Menlo Securityの「2025年ブラウザセキュリティ状況レポート」によると、ゼロアワーフィッシング攻撃は前年比で130％増加したことが明らかになった。2024年のブラウザを標的とした攻撃の5件に1件は、従来のネットワークやエンドポイントベースのセキュリティ対策を回避するように設計された回避手法を使用していた。これらは単なるURLブロックの問題ではない。攻撃者は、正規のSaaSドメイン、ブラウザ内オーバーレイ、AI生成のフィッシング餌などを利用しており、従来のWebゲートウェイではこれらを検知するのが困難である。

3. 認証情報の盗難はブラウザから始まる。ベライゾンの「2025年DBIR」によると、基本的なWebアプリケーション攻撃の88％で、盗まれた認証情報が利用されていた。あるマーケティングマネージャーが、SalesforceのパスワードをChromeの自動入力機能に保存していた。 彼女が仕事でも使用している個人端末に潜む情報窃取型マルウェアが、保存されているすべての認証情報をコピーし、ダークウェブのマーケットプレイスで販売に出品した。6週間後、攻撃者が有効なセッショントークンを用いてCRMに侵入した。データの持ち出しがすでに完了するまで、警報は鳴らなかった。

IBMの「2024年データ侵害コスト報告書」によると、認証情報の盗難を伴う侵害の特定と封じ込めには平均292日を要しており、これはあらゆる攻撃ベクトルの中で最も長い期間でした。侵入後の潜伏期間は10ヶ月近くに及びます。異常なセッション動作を検知し、フィッシング攻撃に強い認証を強制し、管理対象外のデバイスでの認証情報のキャッシュを防止するブラウザレベルの制御を導入することで、この期間を数ヶ月から数分に短縮することができます。

エンタープライズ向けブラウザセキュリティの仕組み

企業のブラウザセキュリティは、4つの機能層にわたって運用されています。これらを理解することで、ベンダーのアプローチを評価し、誇大広告を見抜くことができます。

レイヤー1：脅威の隔離と検査

Remote browser isolation 、Webコンテンツをクラウド上のサンドボックス内でRemote browser isolation 、安全なピクセル（またはサニタイズされたDOM要素）のみをユーザーのエンドポイントにストリーミングします。 ある金融アナリストが、メール内のリンクをクリックしたところ、これまで見たことのないドメインに誘導されました。RBI により、そのページは隔離されたコンテナ内で実行されます。たとえそのページにドライブバイ型エクスプロイトや認証情報収集型マルウェアが含まれていたとしても、悪意のあるコードがアナリストのマシンに接触することは決してありません。ユーザーには通常通りのページが表示され、セキュリティ担当者は封じ込められた脅威を確認することになります。

A secure web gateway が上流に配置され、TLS復号化されたトラフィックを検査し、URLカテゴリポリシーを適用し、ブラウザがページをリクエストする前に既知の悪意ある宛先をブロックします。RBIとSWGを組み合わせることで、既知の脅威とゼロアワー脅威の両方のギャップを埋めることができます。

レイヤー2：セッションレベルData loss prevention

ブラウザ層でのDLPは、ブラウザセッション内でのコピー・貼り付け、ファイルのアップロード、ダウンロード、および印刷操作を遮断します。例えば、管理されたブラウザセッションを通じて貴社の人事情報システム（HRIS）にアクセスできる契約制の採用担当者を想像してみてください。この採用担当者は候補者の記録を閲覧することはできますが、CSVファイルをダウンロードしたり、社会保障番号を個人のメールタブに貼り付けたり、ページのスクリーンショットを撮ったりすることはできません。これは、DLPポリシーがネットワークの出口だけでなく、レンダリング層でも適用されるためです。

レイヤー3：IDおよびアクセス制御

ブラウザのセキュリティ機能は、IDプロバイダー（Okta、Entra ID）やCASBポリシーと連携し、条件付きアクセスを適用します。例えば、契約社員が管理対象外の個人用ノートPCからログインした場合、ポリシーエンジンは、SaaSへの完全なアクセス権を付与したりセッションを完全にブロックしたりするのではなく、アップロード／ダウンロードの制限、クリップボードのブロック、透かし入れなどの制限を適用した上で、そのセッションをRBI経由でルーティングします。これにより、契約社員は業務を遂行でき、組織はデータの管理権限を維持できます。

レイヤー4：可視化と分析

セッションテレメトリ（どのユーザーがどのアプリケーションにアクセスしたか、どのデバイスの状態からアクセスしたか、どのような操作を試みたかといった情報）は、セキュリティ運用ワークフローに組み込まれます。このレイヤーによって、ブラウザは「死角」から「センサー」へと変貌を遂げるのです。

ブラウザのセキュリティがエンタープライズアーキテクチャにどのように組み込まれるか

ブラウザのセキュリティは、孤立した状態で機能するものではありません。それは、既存のセキュリティスタックのあらゆる層と統合されるか、あるいはそれらと競合することになります。アーキテクチャ上の課題は、「ブラウザのセキュリティは必要か？」ということではなく、「SSE、CASB、DLP、エンドポイント、およびアイデンティティに対して、ブラウザのセキュリティはどのような位置づけにあるのか？」ということです。

NIST SP 800 46 Rev. 2 は、リモートアクセスソリューションに関するセキュリティ上の考慮事項について基本的な指針を示しており、組織に対し、テレワーク技術のすべての構成要素を保護するとともに、デバイスの種類、アクセスレベル、およびBYOD の管理に関するポリシーを策定するよう推奨しています。現在、ブラウザはテレワーク技術の主流となっていますが、多くの組織のリモートアクセスアーキテクチャでは、依然としてブラウザを透過的で制御不能な「パイプ」として扱っています。

しっかりと統合された security service edge （SSE）プラットフォームは、SWG、CASB、DLP、ZTNA、およびRBIを単一のポリシーエンジン下に統合します。ユーザーがSaaSアプリケーションを開くと、SSEプラットフォームは、ID、デバイスの状態、位置情報、およびデータの機密性を評価し、セッションを直接許可するか、RBIを経由させるか、DLP制限を適用するか、あるいはアクセスを完全にブロックするかを決定します。ブラウザは適用ポイントであり、SSEプラットフォームはポリシーの中枢です。

その代替案が現実の世界で引き起こす摩擦について考えてみましょう。ある医療機関では、EHRシステムにアクセスする500人の看護師向けに、スタンドアロンのエンタープライズブラウザを導入しています。このユースケースにおいては、このブラウザは問題なく機能しています。しかし、同じ看護師たちは、患者の予約管理用SaaSアプリにはChromeを、州のメディケイドポータルにはEdgeを、そしてシフトのスケジュール管理には個人のスマートフォン上のSafariも使用しています。その結果、IT部門は、セキュリティ態勢が異なる4つのブラウザ環境を管理することになっています。スタンドアロンのエンタープライズブラウザは、ある1つの問題を解決した一方で、セキュリティアーキテクチャを分断してしまったのです。

SSEの統合アプローチにより、ブラウザの入れ替えを必要とすることなく、4つのブラウザ環境すべてで一貫したポリシーが適用されます。DLPポリシーは、どのブラウザでセッションが開かれたかに関係なく、データに追従します。Webおよびクラウドのセキュリティ制御が統一的に適用されます。

「採用の障壁」問題：ブラウザの置き換え vs. ブラウザのセキュリティ強化

ガートナーは、SEB（セキュリティエンドポイントブリッジ）により、プライバシーやメンテナンス上の理由からエンドポイントエージェントの導入が不適切な、管理対象外または管理が不十分なエンドユーザーデバイスやBYOD環境からのセグメント化されたアクセスが可能になると指摘しています。このユースケースは説得力があります。戦略的な課題は、こうした制御をどのように実現するかという点です。

この代替モデルでは、従業員はデフォルトのブラウザの使用をやめ、ベンダー独自のアプリケーションを使用する必要があります。ベンダーがレンダリングエンジン、拡張機能のエコシステム、および更新サイクルを管理します。セキュリティチームは、セッションレベルでの詳細な制御が可能になります。

その代償は、導入時の抵抗感です。Chromeは世界のデスクトップ市場シェアの65%以上を占めています。従業員は長年にわたり、Chromeに慣れ親しんだ操作習慣、保存されたパスワード、同期されたブックマーク、そしてChromeを軸に構築された拡張機能のワークフローを身につけています。彼らに切り替えを求めることは、ヘルプデスクへの問い合わせの増加、「うまく動かないもの」を処理するために従業員が結局Chromeを開いてしまうといったシャドーITによる回避策の横行、そして社内Webアプリケーションすべてに対する絶え間ないブラウザ互換性テストを招くことになります。

これら2つのモデルの比較をさらに深く掘り下げるため、Skyhigh Security「エンタープライズ向けブラウザ」と「RBI」の分析では、それぞれの長所、短所、および企業への最適な適用場面について検証しています。

このセキュアな既存のブラウザモデルでは、Chrome、Edge、Safariといったブラウザをそのまま利用しつつ、SSEプラットフォームを通じて提供されるRBI、SWG、DLP、CASB、ZTNAの各制御機能を用いて、セッション全体をセキュリティで保護します。ユーザー体験はこれまでと変わりません。ユーザーが、AIツールに個人識別情報（PII）を貼り付けたり、シャドウSaaSアプリからファイルをダウンロードしたり、フィッシングページにアクセスしたりといったリスクのある操作を試みるまで、ポリシーの適用はユーザーには気づかれません。

その代償として、SSEアプローチではTLSインスペクションが必要となり（これには独自の証明書管理やプライバシーに関する考慮事項が伴う）、プロプライエタリなブラウザほどDOMレベルで詳細な制御を強制することはできません。SaaSへのアクセスの保護、DLPの適用、リスクの高いブラウジングの隔離、外部委託業者へのアクセス保護など、ほとんどの企業でのユースケースにおいて、SSE統合モデルは導入負担を伴わずに同等の保護を実現します。

評価基準：ブラウザのセキュリティ戦略の選定

企業のブラウザセキュリティを評価する際は、ベンダーと話し合う前に、以下の質問を自問してみてください：

サードパーティ製ブラウザとSSE統合ブラウザのセキュリティ比較

ブラウザのセキュリティにおけるゼロトラストの役割

ブラウザのセキュリティとゼロトラストは、別々の取り組みではなく、異なる角度から見た同じ取り組みなのです。

CISAの「ゼロトラスト成熟度モデル v2.0」は、急速に進化する技術環境において、ゼロトラストに関連する継続的な近代化に向けたアプローチを提供し、行政機関が大統領令第14028号に従って移行計画を策定・実施するための指針となるものです。このモデルは、「アイデンティティ」、「デバイス」、「ネットワーク」、「アプリケーションおよびワークロード」、「データ」という5つの柱に加え、「可視化と分析」、「自動化とオーケストレーション」、「ガバナンス」という3つの横断的機能を中心に構成されています。

これらの柱はすべて、ブラウザという一点で交わっています：

ID：認証トークンとセッショントークンはブラウザ内に保存されます。中間者攻撃を行う攻撃者は、ブラウザを通じてセッションクッキーを盗み出します。

デバイス：ブラウザは、セキュリティ侵害の恐れがあるエンドポイントに最初にアクセスするアプリケーションです。デバイスのセキュリティ状態の確認により、ブラウザ経由のアクセスが制御されます。

ネットワーク：SWG での TLS インスペクションにより、ブラウザのトラフィックが SaaS アプリケーションに到達する前に傍受されます。

アプリケーションとワークロード：SaaSアプリケーションはブラウザを通じて利用されます。CASBポリシーにより、承認済みアプリへのアクセスと未承認アプリへのアクセスが管理されます。

データ：機密データは、ブラウザを通じて閲覧、コピー、ダウンロード、アップロードされます。ブラウザ層でのDLPは、データが組織外に流出する前の最後の防衛線となります。

具体的なシナリオ：地方銀行の融資担当者が、カフェにPrivate Access ZTNA／Private Access 介して社内融資アプリケーションにアクセスする。 Skyhigh SSEプラットフォームは、担当者の本人確認（Okta MFA）を行い、デバイスの状態（管理対象のノートPC、暗号化されたディスク、最新のOSパッチレベル）を確認し、脅威の検査のためにSWGを経由してセッションをルーティングし、顧客の個人識別情報（PII）を含む融資書類のダウンロードを防止するDLPルールを適用し、監査のためにすべての操作をログに記録します。VPNも、専用ブラウザも不要です。担当者が普段使用しているブラウザを通じて、ポリシーに基づいてアクセスが強制されるだけです。

ブラウザのセキュリティを無視するとどうなるか

ベライゾンの「2025年DBIR」によると、情報漏洩事件における第三者の関与は前年比で2倍に増加し、現在では全情報漏洩事件の30％を占めていることが明らかになった。こうした第三者による侵害の多くは、請負業者やパートナーが、DLP（データ漏洩防止）機能やセッション管理、隔離機能のない管理対象外のブラウザを通じてSaaSアプリケーションにアクセスしたことが発端となっている。

次のような一連の出来事を想像してみてください。あるコンサルティング会社のアナリストが、管理対象外の個人用ノートパソコンから貴社のWorkdayインスタンスにアクセスします。そのアナリストのChromeプロファイルは、認証情報を個人のGoogleアカウントに同期しています。その後、そのアナリストの家族が、同じノートパソコンに情報窃取型マルウェアを含むゲームのMODをダウンロードします。この情報窃取型マルウェアは、Workdayの認証情報を含む、ブラウザに保存されているすべてのパスワードを収集してしまいます。 6週間後、攻撃者がその認証情報を使用して貴社のWorkday環境にアクセスし、8,000人の従業員のW-2データを抽出しました。

これは単なる仮説上のシナリオではなく、VerizonのDBIRが「Snowflake侵害クラスター」で記録したパターンと一致しています。そこでは、情報窃取型マルウェアに感染したデバイスから流出した認証情報により、多要素認証（MFA）が適用されていなかったクラウド環境へのアクセスが可能となっていました。

NIST SP 800-46 Rev. 2 では、テレワーク用端末に保存され、外部ネットワークを経由したリモートアクセスを通じて送信される機密情報のセキュリティ確保の重要性が強調されています。現在、ブラウザは主要なテレワーク用端末となっています。ブラウザには、認証情報、セッショントークン、キャッシュデータ、クリップボードの内容などが保存されています。これを管理しないままにしておくことは、認証なしに VPN トンネルを常時開いたままにしておくことと同じです。