エンタープライズ向けブラウザセキュリティソリューションの評価方法

ブラウザのセキュリティは、SSEロードマップにおいて、いつの間にか最も重要な判断事項となっています。 ガートナーは、2028年までに組織の25％が、少なくとも1つのセキュアなエンタープライズブラウザ技術を導入することで、既存のセキュアなリモートアクセスおよびエンドポイントセキュリティツールを強化すると予測しています。しかし、その大半はまだ導入に至っていません。この「導入意向」と「実際の導入」とのギャップは、ほとんどのセキュリティチームが中間的な立場にあることを意味しています。つまり、ブラウザの保護が必要であることは認識しているものの、どのアプローチを採用すべきか確信が持てず、次の侵害が発生して事態が深刻化する前に選択を迫られているのです。

この実践ガイドでは、独自の代替ブラウザ、ブラウザ拡張機能、 remote browser isolation （RBI）、SSE統合型制御など）を網羅した体系的な評価フレームワークを提供します。これにより、ベンダー主導のデモサイクルではなく、正当な根拠に基づいた選定プロセスを実施できるようになります。

前提条件：評価を行う前に準備すべきこと

前提条件を確認せずにブラウザのセキュリティ評価を行うのは、ネットワークのトポロジーも把握せずにファイアウォールを購入するようなものです。ベンダーを候補に挙げる前に、以下の4つの手順を完了させてください。

1. ブラウザ環境を把握しましょう。IT部門が導入しているブラウザではなく、従業員が実際に使用しているブラウザを把握することが重要です。ガートナー（2025年）によると、Chromiumベースのブラウザはブラウザ市場全体の約75％を占めているため、導入するソリューションはChrome、Edge、そしておそらくBraveやArcなどの派生ブラウザでも動作する必要があります。もし、Safariを使用するMacユーザーが多数いる部門がある場合、その互換性は「あれば望ましい」というレベルではなく、必須要件となります。

2. SaaSおよび自社開発アプリケーションのポートフォリオを整理します。ブラウザ上でのみ動作するアプリケーションと、シッククライアントコンポーネントを含むアプリケーションを特定します。Salesforceにアクセスし、顧客リストをキャンペーンプラットフォームにアップロードし、時折セグメントをGenAIライティングツールに貼り付けるマーケティングチームのメンバーと、ZTNA経由で内部コードリポジトリにアクセスする開発者では、リスクプロファイルが根本的に異なります。

3. 既存のセキュリティスタックを整理・把握する。現在導入されているSWG、CASB、DLP、ZTNA、およびエンドポイント検知ツールを文書化してください。ForresterのSSE評価フレームワーク（2024年第1四半期）では、ZTNA、CASB、SWGの3つの主要なセキュリティ技術と、RBIやDLPを含むいくつかの二次的な技術が特定されています。ブラウザセキュリティソリューションは、これらの制御機能を重複させるのではなく、それらと統合できるものでなければなりません。

4. 管理対象外のデバイスによるリスクを特定する。個人のノートパソコンを使用してWorkdayインスタンスにアクセスする契約社員や、ホテルのビジネスセンターからSharePointにアクセスする外部監査人は、ブラウザ関連のリスクにおいて最も深刻な脅威となります。管理対象、管理が不十分な、および完全に管理対象外のデバイスに分類されるユーザー数を把握してください。これにより、どの対策が有効であるかが直接決まります。

フェーズ1：評価基準と脅威シナリオの定義

ベンダーによるデモから評価を始めると、結局は最も声の大きい営業担当者が勝ちます。その代わりに、自社の実際のリスクを反映した脅威シナリオから検討を始めるべきです。

シナリオライブラリを作成する

発生頻度が高く、影響も大きいブラウザ関連のリスクを反映したシナリオを5～8つ作成してください。具体的な例：

外部SaaSへのアクセス：外部コンサルタントが管理対象外の端末から貴社のCRMにアクセスし、顧客の個人情報を閲覧した上で、連絡先リストを個人のドライブにダウンロードしようとした。

AIツールによるデータ漏洩：あるプロダクトマネージャーが、SharePointから競合分析文書をコピーし、承認されていない生成AIツールに貼り付けたところ、そのツールの回答に自社の収益に関する機密データが含まれていた。

ブラウザセッション内でのフィッシング：ある金融アナリストがTeamsのメッセージ内のリンクをクリックしたところ、認証済みのアクティブなセッション内で、SSOプロバイダーを装った認証情報収集ページが開いてしまいました。

コピー＆ペーストによる情報流出：退職する従業員が、あるタブでSalesforceを開き、別のタブで個人のGmailの下書きを開き、タブ間でパイプラインデータをコピーする。

これらのシナリオが、POCテストスクリプトとなります。上位5つのシナリオに対して有効な対策を提示できないベンダーは、アナリストによるクアドラントの配置にかかわらず、選考から除外されます。

ゼロトラストアーキテクチャと整合させる

CISAの「ゼロトラスト成熟度モデル v2.0（2023年）」は、アイデンティティ、デバイス、ネットワーク、アプリケーションおよびワークロード、データの5つの柱に基づいてゼロトラストを体系化し、組織に対して継続的な近代化に向けたロードマップを提供しています。 ブラウザのセキュリティ評価は、少なくとも以下の3つの柱に直接対応している必要があります。デバイス（ブラウザセッションはデバイスを認識しているか？）、アプリケーション（ブラウザレベルでアプリごとのポリシーを適用できるか？）、データ（ソリューションはブラウザ内で転送中のデータを検査・制御できるか？）。

フェーズ2：4つのブラウザのセキュリティ対策の評価

すべての組織に同じアプローチが適しているわけではありません。現在、市場には4つの異なるアーキテクチャ・モデルが存在し、それぞれに重要なトレードオフがあります。

独自開発の代替ブラウザ

フルスタックのカスタムブラウザは、Chrome、Edge、Firefoxに代わり、ベンダーが管理するChromiumのフォーク版であり、レンダリングエンジンレベルでDLP、ID管理、ポリシー適用機能を組み込んでいます。ガートナーは、セキュアなエンタープライズブラウザを、一元管理されるブラウザ拡張機能、およびオプションとしてフルスタックのカスタムWebブラウザを通じてエンタープライズセキュリティポリシーと制御機能を提供し、Web、SaaS、およびプライベートアプリケーションに対してセキュリティとポリシー適用を実現するソリューションと定義しています。

セキュリティの堅牢性は高い――レンダリングパイプライン全体を制御できるからだ。しかし、導入に伴う負担も同様に大きい。何千人ものユーザーに対し、長年使い慣れたブラウザを捨て、操作の感覚を再学習し、ブックマークや拡張機能、保存されたパスワードが完全に移行されない可能性があることを受け入れるよう求めていることになる。調達チームは、これによりIT部門が、以前はGoogleやMicrosoftが担っていたブラウザのパッチ適用、互換性テスト、バージョン管理といった新たなソフトウェアライフサイクルを管理することになることに気づく。

ブラウザ拡張機能

軽量なエージェントがユーザーの既存のブラウザにインストールされ、ブラウザ自体を置き換えることなく、ページの動作を監視し、クリップボードの操作を制御し、DLPポリシーを適用します。拡張機能を利用することで、ユーザーは慣れ親しんだ操作環境を維持でき、ブラウザの置き換えに伴う移行の負担を回避できます。しかし、拡張機能ベースのセキュリティはブラウザベンダーのAPIに依存しており、ブラウザのアップデートごとに変更される可能性があります。また、一部の重要な操作（JavaScriptエンジンの詳細な検査など）については、アーキテクチャ上の制限を受ける場合があります。

Remote browser isolation RBI）

RBIは、Webコンテンツをクラウドベースのコンテナ内で実行し、安全な視覚的出力のみをユーザーのローカルブラウザにストリーミングします。CISAの『Capacity Enhancement Guide（2023年版）』では、多層防御として、ブラウザの分離とWebコンテンツフィルタリング、DLP、セキュアゲートウェイの組み合わせを推奨しています。このセキュリティモデルはアーキテクチャ的に堅牢であり、エンドポイント上でWebコードが実行されることはありません。 SSEプラットフォームと統合された場合、RBIは段階的なポリシー対応として機能します。つまり、安全と確認されている宛先にはアクセスを許可し、悪意があると確認されている宛先はブロックし、リスクのあるサイトや分類不能なサイトは隔離します。

SSE統合型ブラウザコントロール

このアプローチでは、ブラウザのセキュリティを単体の製品として扱うのではなく、統一secure web gatewayを通じて、SWGによるURLフィルタリング、CASBによるインラインポリシー、DLPによるコンテンツ検査、および選択的なRBIを多層的に組み合わせています。ブラウザ自体には変更を加えず、セキュリティはネットワーク層およびプロキシ層で適用され、リスクに応じてポリシーに基づいたエスカレーションにより隔離措置が講じられます。これは、既存のエンタープライズセキュリティスタックの運用方法に最も近いアプローチです。

フェーズ3：8つの加重基準に基づいてベンダーを評価する

以下の評価フレームワークを用いて、候補に残った各ソリューションを採点してください。各評価項目の重み付けは、組織の優先順位に応じて調整してください。例えば、外部委託スタッフを多く抱える組織では、管理対象外のデバイスのサポートに対する重み付けが、主に管理対象のエンドポイントを持つ組織とは異なってくるでしょう。

ベンダー評価フレームワーク

各評価項目について、1～5の5段階評価（1＝要件を満たさない、5＝要件を上回る）で採点してください。その点数に重み付け係数を乗じて、加重スコアを算出します。「セキュリティの深度」または「SSE統合」のいずれかで1点となったソリューションは、総合スコアにかかわらず除外してください。

フェーズ4：実際に何かを証明できる概念実証（PoC）を実施する

POCの多くは、検証すべき事項を誤っているために失敗に終わります。クリーンな仮想マシン上でテストユーザー2名を対象に30分間行われるベンダーのデモでは、月曜日の朝に何百人もの実際のユーザーがアクセスした際に、そのソリューションがどのように動作するかについては何もわかりません。

POCの設計原則

セキュリティチームではなく、実際のユーザーを活用しましょう。財務、エンジニアリング、そしてSaaSを多用している事業部門など、少なくとも3つの部門から50～100名のユーザーを募集してください。そのツールを採用しなかったユーザーこそが、ベンダーの推進派が見落としがちな課題を浮き彫りにしてくれるでしょう。

実際に使用しているSaaSスタックをテストしてください。本番環境のSalesforceインスタンス、Workday環境、および社内アプリケーションに対してPOC（概念実証）を実行してください。Mandiantの「M-Trends 2025」レポートによると、初期感染の33%がエクスプロイトによるものであり、盗まれた認証情報は16%に増加して2番目に多い感染経路となっています。つまり、ブラウザのセキュリティ対策では、マルウェアのダウンロードだけでなく、認証情報の盗難やセッションハイジャックのシナリオにも対応する必要があります。

セキュリティと使いやすさの両方を評価します。以下の3つのカテゴリの指標を追跡します：

セキュリティ指標：阻止されたフィッシング攻撃、DLPポリシーのトリガー、隔離されたセッション、防止されたマルウェア

ユーザビリティ指標：平均ページ読み込み時間の差（ベースラインとの比較）、5つの標準ワークフローにおけるタスク完了時間、ヘルプデスクへの問い合わせ件数

導入指標：アクティブユーザー数対登録ユーザー数、バイパス試行回数、ユーザー満足度スコア（1～5段階の簡易アンケート）

あらゆる脅威を遮断するものの、ページの読み込みに毎回3秒の遅延を生じさせるようなソリューションは、ユーザーからの反発を招き、運用上の価値を失うことになる。逆に、コピー＆ペーストによるデータ流出を見逃してしまうような、セキュリティ上の障壁がまったくないソリューションは、単なる見せかけのセキュリティに過ぎない。

POCの期間と範囲

POCは最低3週間実施してください。第1週目は、初期導入時の課題やユーザーのオンボーディングに充てます。第2週目には、安定した状態でのパフォーマンスが明らかになります。第3週目には、エッジケースを捕捉します。具体的には、異常なデータ量が発生する四半期ごとの報告サイクル、制限付きアプリへの一時的なアクセスが必要な外部業者、独自データを生成AIツールに貼り付けようとするユーザーなどが挙げられます。

フェーズ5：SSEの統合とポリシーの統一を評価する

多くのブラウザのセキュリティ評価が失敗する原因はここにあります。チームはブラウザのセキュリティを単独で評価し、導入の段階で、それがSWG、CASB、DLPの制御機能とは切り離された、並行するポリシーの世界を作り出してしまうことに気づくのです。

実用的なテスト：社会保障番号が許可されていないクラウドストレージにアップロードされるのをブロックするDLPポリシーを設定してください。次に、ユーザーが隔離されたブラウザセッション内でGenAIのプロンプトにそれらの番号を入力したり、ブラウザのタブ間でコピーしたり、それらを含むページを印刷しようとしたりした場合に、同じポリシーが確実に発動することを確認してください。もしこれらのアクションのそれぞれに対して、別々のコンソールで個別のポリシーが必要になるのであれば、そのブラウザセキュリティは運用上の負債を生み出しているだけで、削減にはつながっていません。

フォレスター社のSSE評価（2024年第1四半期）によると、データ居住地は、特に米国以外において依然として重大な懸念事項であり、特定の国にデータを保持する能力にはベンダーによって差があることが明らかになりました。評価を行う際は、ブラウザ分離セッションがどこで処理されるか、検査ログがどこに保存されるか、そして特定の地域へのセッションルーティングを制御できるかどうかを確認してください。特に、GDPR、CCPA、または業界固有のデータ主権要件の下で事業を行っている場合は、この点に留意する必要があります。

現在の脅威情勢は、このレベルの統合を求めています。CSAの「SaaSセキュリティの現状レポート（2025年）」によると、56%の組織が、従業員が許可されていないSaaSアプリに機密データをアップロードしていると回答しています。 CASBやDLPとコンテキストを共有しないブラウザセキュリティでは、こうしたリスクにリアルタイムで対処することはできません。例えば、Skyhigh SecurityプラットフォームSkyhigh Security、SWG、CASB、DLP、RBIのポリシーを単一のコンソールに統合しており、スタンドアロンのブラウザセキュリティ製品にありがちな「ポリシーの二重管理」という問題を解消しています。

ブラウザのセキュリティ評価を台無しにしてしまうよくある間違い

間違いその1：ユーザー体験を検証せずにセキュリティの堅牢性を評価すること。あるCISOが、セキュリティ機能のチェックリストに基づいて代替ブラウザを選定し、数千人のユーザーに導入したところ、3つの重要なSaaSアプリケーションが正しく表示されないことが判明した。2週間も経たないうちに、シャドーITによる回避策が蔓延し、ユーザーは個人のブラウザに切り替えたり、個人端末から社内アプリにアクセスしたりするようになり、結果としてセキュリティ態勢はむしろ悪化してしまった。

間違いその2：ブラウザセキュリティを単独の購入案件として扱うこと。調達チームが、自社のSSEスタックとは別のベンダーからブラウザセキュリティソリューションを購入し、その後6か月かけて既存のSWGやCASBポリシーとの統合を試みる。 その結果、2つのポリシー管理コンソールが存在し、ロジックがわずかに異なる重複したDLPルールが生じ、矛盾するテレメトリデータによるアラート疲労が発生する。ガートナーの評価ガイダンス（2025年10月）では、ソリューションが理論上統合可能かどうかではなく、SIEM、SOAR、SSE、EDRスタックとどのように統合されるかを明確に確認するよう推奨している。

間違いその3：管理対象外のデバイスの利用ケースを無視すること。チームは、管理対象の社用ノートPCにおけるブラウザのセキュリティを評価した後、導入後に、ブラウザのリスクの相当な部分が、エージェントやMDMプロファイルをインストールできない外部委託業者やBYODユーザーに起因していることに気づきます。エンドポイント制御を必要とするソリューション（ローカル管理者によるインストールが必要な一部の代替ブラウザなど）は、最も保護を必要としているユーザーにとって、気づかれないうちに機能しなくなってしまいます。

間違いその4：コストモデル分析を省略する。RBIのコストは利用量に応じて増加するため、すべてのユーザーのすべてのWebセッションを個別に隔離するのはコストがかさみます。選択的な隔離（リスクの高いサイトや分類不能なサイトのみを対象とする）を行うことで、セキュリティ体制を維持しつつコストを大幅に削減できます。ベンダーの価格体系が、対象を絞った隔離を奨励しているか、あるいは逆に不利に扱っているかを評価してください。

間違いその5：セキュリティチームのメンバー5名だけで2日間のPOCを実施すること。これでは、管理された環境下において技術系ユーザーにとって製品が機能するかどうかは分かりますが、ヒューストン支店の買掛金担当者が、隔離中にブラウザのセッションが一時停止したり、愛用しているChrome拡張機能が動作しなくなったりした際にどう反応するかについては、何も分かりません。実際のユーザーを対象に、少なくとも3週間は本格的なPOCを実施してください。

最終決定のための評価指標と成功基準

POC終了後、これらのベンチマークを活用して、経営陣に対して説得力のある提案を行ってください：

ページの読み込み時間の差は許容範囲内です。平均ページ読み込み時間が基準値（上位20のアプリケーション全体で測定）を大幅に上回る場合、ユーザーからの苦情が発生し、導入の妨げとなる可能性があります。アプリケーションごとの読み込み時間の差をミリ秒単位で正確に追跡してください。

DLPポリシーの適用範囲と同等か、それ以上のカバー率。ブラウザセキュリティソリューションは、既存のインラインDLPが検知するDLP違反をすべて捕捉できるだけでなく、ブラウザ特有の攻撃経路（クリップボード、印刷、スクリーンキャプチャ）に対する検知機能も備えている必要があります。

5段階評価で3.5以上のユーザー満足度。この基準を下回ると、エスカレーション、バイパス試行、およびセキュリティ上の価値を損なう管理者の例外処理が発生する恐れがあります。

ヘルプデスクへのチケット件数は管理可能な範囲内です。急激な増加が見られる場合は、自然に解消されない導入上の課題が存在することを示しています。登録ユーザー100人あたりの週次チケット件数を追跡してください。

ポリシー変更にかかる平均時間は4時間未満です。ブラウザ固有のDLPルールの更新に、SWGルールの更新よりも時間がかかる場合は、統合が不十分であると言えます。

重要なアプリケーションの障害はゼロ。上位20位以内のアプリケーションで、表示が正しく表示されないものや機能テストに不合格となるものは、いずれも「既知の問題」ではなく、デプロイの阻害要因となります。

マンディアントの「M-Trends 2026」レポートによると、最初の侵害から第2の脅威グループへの引き継ぎまでの所要時間の中央値は、2022年の8時間以上から、2025年にはわずか22秒にまで短縮されたことが明らかになりました。ブラウザのセキュリティは「ワイヤースピード」で動作し、攻撃者が侵害された認証情報を利用して横方向の移動を開始する前に、ブラウザセッション内で脅威を検知・ブロックする必要があります。

より広範なセキュリティアーキテクチャにおけるブラウザ分離の役割を理解することで、これらの指標を適切に捉えることができます。分離は単独の防御手段ではなく、多層的なセキュリティモデルにおけるポリシーに基づくエスカレーションの一環です。