ブラウザレベルの制御によるSaaSアプリケーションのセキュリティ確保

CASBは、契約業者がSalesforceから顧客リストを管理対象外のノートPCにダウンロードすることをブロックします。 5秒後、その同じ契約社員がテーブル全体を選択し、クリップボードにコピーして、個人のGmailの作成画面に貼り付け、「送信」をクリックしました。CASBはこの動作を一切検知しませんでした。しかし、ブラウザはこれを検知していました。適切な制御があれば、これを阻止できたはずです。本ガイドでは、SaaSセキュリティ管理者およびCASB運用担当者向けに、ブラウザレベルの制御を多層的に導入することで、このセキュリティギャップを埋める段階的なアプローチについて解説します―― remote browser isolation （RBI）、secure web gateway SWG）ポリシー、DLP、セッションアクション——を既存のCASB導入環境に重ねて適用することで、そのギャップを埋める段階的なアプローチについて解説します。

前提条件：開始前に準備しておくべきこと

ブラウザレベルの制御を有効にする前に、お使いの環境が4つの基本条件を満たしていることを確認してください。これらを省略すると、ポリシーの競合、ユーザーの不満、および対策範囲の不備につながります。

1. フォワードプロキシモードとリバースプロキシモードを備えたCASBがすでに導入されている。ポリシー適用における基本要件として、承認済みSaaSアプリケーションに対するインライントラフィック検査（リバースプロキシ）と、シャドーITの可視化（フォワードプロキシ）が必要となる。CASBの導入がAPIのみの場合、ブラウザ制御によって実現されるインラインパスが欠如することになる。

2. 統合されたDLPポリシーエンジン。ブラウザレベルの制御では、CASBやメールDLPポリシーで使用されているのと同じデータ分類（PII、PHI、財務記録、ソースコード、知的財産など）を参照する必要があります。DLPの定義が別々のサイロに分かれている場合は、まずそれらを統合することから始めましょう。分類に一貫性がないと、あるチャネルでブロックされているものが別のチャネルでは許可されてしまうといった事態を招きます。一元化されたDLPプラットフォームであれば、このような断片化を回避できます。

3. アイデンティティプロバイダー（IdP）との連携およびデバイスの状態評価。ブラウザの制御機能は、ユーザーが誰であるか、どのデバイスを使用しているかによって適応することで、その有用性が格段に高まります。個人のMacBookを使用しているマーケティング担当の契約社員には、管理対象のWindowsエンドポイントを使用している正社員の財務アナリストよりも、より厳格な制御を適用すべきです。これには、IdPとのSAML/OIDCフェデレーションおよびデバイスの状態チェック（管理対象か非管理対象か、OSのパッチレベル、ディスク暗号化の状態）が必要となります。

4. 機密性分類付きのSaaSアプリケーション一覧。どのSaaSアプリケーションが機密データを保持しているかを把握しなければ、ブラウザポリシーの適用範囲を定義することはできません。利用頻度の高い上位20～50のSaaSアプリケーションを、データの機密性レベル（重要、高、中、低）ごとに分類してください。CSAの「SaaSガバナンスのベストプラクティス」では、SaaSライフサイクルの全段階（評価、導入、利用、終了）においてリスクを評価することを推奨しています。この一覧は、ポリシー適用範囲を定義するための情報源となります。

フェーズ1：高リスクシナリオにおけるクリップボードとダウンロードのギャップを解消する

リスクが最も高く、ユーザー数が最も少ない領域、すなわち、機密性の高いSaaSアプリケーションにアクセスする管理対象外のデバイスから着手しましょう。

フェーズ1を正当化するシナリオ：第三者の監査人が、SSOを使用して個人のノートPCから貴社のWorkdayインスタンスにログインします。 CASBのリバースプロキシはセッションを認証し、ポリシーに従ってファイルのダウンロードをブロックします。しかし、監査担当者は従業員の報酬レポートを開き、30行分の給与データを選択してコピーし、新しいタブで個人のGoogleスプレッドシートを開いて貼り付けました。CASBは、認証済みのWorkdayセッションとGoogleスプレッドシートのセッションを検知しましたが、これらは別個の、それぞれ個別に許可されたイベントです。クリップボード操作は完全にブラウザのレンダリングコンテキスト内で発生したため、CASBは両者の間でデータが移動したことを検知しませんでした。

導入内容：Tier 1（重要）およびTier 2（高）のSaaSアプリケーションにアクセスするすべての非管理対象デバイスのremote browser isolation （RBI）を有効にします。RBIでは、SaaSアプリケーションをクラウド上でホストされたコンテナ内でレンダリングし、ユーザーのブラウザにはピクセルデータのみをストリーミングします。このアーキテクチャにより、セッションの動作をきめ細かく制御できます：

コピー／貼り付けの制限：SaaS アプリのコンテキストからデータが流出するのを防ぐため、隔離されたセッションからのクリップボードへの書き込み／読み取り操作をブロックするか、貼り付けは許可するもののコピーはブロックします。

ダウンロードの制限：レンダリングされたセッションからのファイルのダウンロードを完全に禁止するか、特定のファイル形式に限定します。

印刷のブロック：印刷およびPDFへの印刷コマンドを無効にします。

スクリーンショットの透かし処理：レンダリングされたストリームに、ユーザーのメールアドレスとタイムスタンプを含む可視またはフォレンジック用の透かしを挿入し、スクリーンショットの取得を阻止します。

NIST SP 800-53 SC 7 では、情報フローを制御し、悪意のある攻撃やエラーによる潜在的な被害を制限するために、境界保護メカニズムを用いてシステムコンポーネントを分離することが義務付けられています。RBI は、SaaS アプリケーションのデータとユーザーのローカルデバイスとの間にまさにこの境界を構築し、ネットワークプロキシでは実現できない情報フロー制御を強制します。

適用範囲の制限：これらの制御措置は、フェーズ1においては、管理対象外のデバイスおよび外部委託業者にのみ適用してください。エージェントが展開され、セキュリティ状態が確認済みの管理対象エンドポイントについては、生産性を維持するため、より緩やかな制御措置（クリップボードのブロックを伴わない透かし表示など）を適用することができます。

フェーズ 2：ブラウザ DLP を管理対象のエンドポイントおよびより広範な SaaS へ拡大する

フェーズ1が安定したら（通常、テレメトリデータの収集とポリシーの調整を4～6週間行った後）、対象範囲を管理対象デバイスや、より幅広いSaaSアプリケーションへと拡大します。

フェーズ2を正当化するシナリオ：管理対象のノートPCを使用する常勤の営業担当者が、Chromeを通じてSalesforceにアクセスします。その担当者は顧客アカウントレコードを開き、連絡先の氏名、会社名、電話番号をコピーしてChatGPTに貼り付け、パーソナライズされた営業メールを生成します。ファイルのダウンロードは一切行われていません。Salesforceの共有ルールにも違反していません。しかし、顧客の個人識別情報（PII）は、ブラウザのクリップボードを経由して、管理下のSaaS環境から第三者のAIツールへと流出してしまったのです。

CSAの「SaaSセキュリティの現状レポート（2025年）」によると、63％の組織が外部へのデータ共有過剰を報告しており、56％が従業員が機密データを許可されていないSaaSアプリにアップロードしていると回答しています。こうした行為は、多くの場合、従来の制御策では見落とされがちな、まさにクリップボードやアップロード経路を通じて行われています。ブラウザレベルのDLPは、データが許可されていない宛先に到達する前に、こうした動作を遮断する制御手段です。

デプロイする内容：

SWGは、管理対象のエンドポイントに対してDLP検査を実施しました。secure web gateway ブラウザのトラフィックを傍受し、送信中のデータ（フォームフィールドへの入力送信、Webアプリへのクリップボードからの貼り付け、ブラウザ経由のファイルアップロードなど）に対してDLP分類を適用します。これにより、前述のSalesforceからChatGPTへのデータ送信シナリオを検知することができます。

機密性の高いカテゴリに対する選択的なRBI。すべてのブラウジングを隔離するのではなく、ユーザーの行動がリスクシグナル（例：顧客データオブジェクトへのアクセス、エクスポートビューの表示、企業の認証情報を使用してAIツールにアクセスするなど）をトリガーした場合に限り、Tier 1およびTier 2のSaaSアプリへのセッションをRBI経由でルーティングします。

セッション記録の抑止を目的とした透かし処理。機密データが表示されているセッションには目に見える透かしを適用し、ユーザーが画面を撮影した場合でも、その透かしから特定のユーザー、セッション、およびタイムスタンプを特定できるようにする。

NIST SP 800-53 AC 4 に示されるポリシー設計の原則：アプリケーションおよびサービスレベルでアクセス制御メカニズムを採用することで、ネットワークレベルの制御では達成できないレベルの情報セキュリティの強化や情報フローの制御が可能となる。ブラウザレベルの DLP および RBI は、まさにこのアプリケーションおよびサービスレベルで動作し、ネットワークレベルの CASB プロキシでは対応できない制御機能を提供する。

フェーズ 3：ブラウザ制御を SSE ポリシー・ファブリックに統合する

ブラウザ制御を独立したレイヤーとして導入すると、運用上の負担が生じます。つまり、個別のポリシー、個別のコンソール、個別のインシデントキューが必要になるのです。フェーズ3では、ブラウザレベルの適用を、より広範な Security Service Edge （SSE）プラットフォームと統合し、単一のポリシーエンジンがCASB、SWG、DLP、RBI、およびZTNAの決定を一元的に管理できるようにします。

フェーズ3の導入を正当化するシナリオ：SOCに3つのアラートが届きました。ユーザーがシャドウSaaSアプリにアクセスしたというCASBアラート、同じユーザーのブラウザセッションでDLPパターンが一致したというSWGアラート、そしてクリップボードへのコピーがブロックされたというRBIアラートです。1人のユーザーが1つのアクションシーケンスを実行しただけで、3つのコンソール、3人のアナリスト、3つのチケットが発生してしまいます。Unified SSEポリシーにより、これらは1つの相関イベントに統合され、単一の対応ワークフローで処理されます。

デプロイする内容：

単一の条件文内で、ユーザーの身元、デバイスのセキュリティ状態、SaaSアプリの機密性レベル、データ分類、およびブラウザの操作タイプ（ダウンロード、クリップボード、印刷、アップロード）を参照する統一されたポリシールール。

SSEプラットフォームが、管理対象外のデバイスがTier 1アプリケーションにアクセスしている一方で、DLPがページ内の機密コンテンツを検出したといった一連のシグナルを検知した場合、セッションを自動的にフルRBIにエスカレーションする適応型隔離機能。

セッションのテレメトリデータをSIEM/SOARに送信し、ブラウザレベルのイベント（クリップボードのブロック、透かしの挿入、ダウンロードの抑制など）を、CASB、SWG、ZTNAのイベントと併せて可視化することで、相関分析や調査を可能にする。

CISAの「ゼロトラスト成熟度モデル」では、組織に対し、きめ細かなアクセス制御と統合された脅威対策を用いて、導入済みのアプリケーションを管理・保護し、「アプリケーションおよびワークロード」および「データ」の各柱において最適な成熟度を達成するよう求めています。ブラウザレベルでの制御をSSEポリシーに組み込むことで、ブラウザ経由でアクセスされるSaaSアプリケーションに対して、この指針を実践に移すことができます。

統合ポイント：ブラウザコントロールが既存のスタックと連携する箇所

ブラウザレベルの制御は、既存のセキュリティツールの代わりになるものではなく、それら間の適用上のギャップを埋めるものです。重複を避け、カバー範囲を確保するために、統合ポイントを明確に特定してください。

実際の統合シナリオを考えてみましょう。ある医療機関がCASBのAPIモードを使用して、Box内に保存されているPHIをスキャンし、共有ポリシーを適用しています。しかし、看護師が個人のタブレットでブラウザを介して患者の文書を開いた場合、APIによるスキャンはすでに実行済みであるため、患者の診断結果をクリップボードにコピーしてメッセージングアプリに貼り付けることを防ぐことはできません。クリップボードの制限と透かし機能を備えたRBIセッションを利用すれば、個人のタブレットにエンドポイントエージェントをインストールすることなく、このセキュリティ上の隙間を埋めることができます。Skyhigh Security、管理対象外のデバイスからクラウドアプリを保護するためのアプローチは、リバースプロキシ、RBI、およびDLPを統合ポリシーに組み合わせることで、まさにこのユースケースに対応しています。

指標と成功基準

ブラウザレベルでの制御により、従来のCASBのみの導入環境では生成できなかったテレメトリデータが得られます。導入前にメトリクスを定義しておくことで、その価値を実証し、ポリシーを最適化することができます。

運用指標（毎週追跡）：

ユーザー、アプリ、デバイスタイプごとにクリップボードのブロックイベントを確認します。特定のユーザーにおけるクリップボードのブロック件数が急増した場合は、データ漏洩の試みである可能性や、正当なワークフローに対してポリシーが過度に制限的である可能性を示唆している場合があります。異常値を調査してください。

ダウンロードのブロックイベントをダウンロードします。SaaSアプリおよびユーザーの役割ごとに追跡します。特定のアプリからのダウンロードブロック件数が多ければ、ユーザーには安全な代替手段（例：読み取り専用ビューアや、管理されたエクスポートワークフローなど）が必要である可能性があります。

透かしが調査のきっかけとなった。透かしが入ったスクリーンショットや印刷物が、調査を通じてユーザーに特定された回数を数えてみてください。その回数が少なくても、抑止効果があることが証明されます。

ポリシー例外の申請。ブラウザ制御に対する例外を申請したユーザー数と、その理由を追跡します。特定のアプリで例外の申請件数が多い場合は、ポリシーの見直しが必要であることを示唆しています。

リスク低減指標（四半期ごとに追跡）：

SaaSのクリップボードやアップロード経路に関連する機密データインシデントの減少。同一のSaaSアプリおよびユーザー層を対象に、ブラウザ制御の導入前後のインシデント件数を比較する。

管理対象外のデバイスのセッション制御のカバー率。RBIを経由する管理対象外のデバイスのSaaSセッションと、RBIをバイパスするセッションの割合を測定する。Tier 1アプリについては、95%以上のカバー率を目標とする。

ブラウザを介した情報漏洩の試みを検知するまでの平均時間。ブラウザのテレメトリを活用することで、検知時間を（事後的なDLPスキャンによるアラートに依存する場合の）数日単位から、（クリップボードのリアルタイムブロックによる）数秒単位へと短縮できるはずである。

ベライゾンの「2025年DBIR」によると、データ漏洩の60％は、ユーザーがクリック、コピー、アップロード、貼り付けといった操作を行うという「人的要因」が関与していたことが明らかになりました。 ブラウザレベルの制御は、まさにこうした人間の行動に関する執行テレメトリを生成するため、SOCは、ネットワークやAPIの制御では完全に見逃されてしまう攻撃経路を可視化できます。一方、フォレスターの報告によると、データ侵害の約5分の1は内部関係者によるインシデントに起因しており（2026年）、ブラウザセッション制御は、内部関係者が最も頻繁に悪用するクリップボードやアップロード経路に対して、直接的かつリアルタイムな執行を可能にします。

よくある間違い

間違いその1：導入初日から全ユーザーに対して完全なRBI分離を適用すること。完全なピクセルストリーミング分離は、ブラウジング体験に変化をもたらします。遅延がわずかに増加し、一部のブラウザ拡張機能が動作しなくなり、複雑なWebアプリでは表示が異なって見える可能性があります。これを5,000人の従業員に同時に導入すれば、ヘルプデスクから猛反発を受け、経営陣によってプロジェクトが中止されてしまうでしょう。まずは管理対象外のデバイスやリスクの高いアプリから始め、徐々に拡大していきましょう。

間違いその2：管理対象デバイスと非管理対象デバイスに同一のブラウザポリシーを適用すること。非管理対象の請負業者のノートPCには、クリップボードの完全なブロックとダウンロードの抑制が必要です。一方、エージェントがインストールされ、ディスク暗号化が確認され、最新のパッチが適用されている管理対象の企業エンドポイントでは、透かし表示と選択的な貼り付け制限のみで十分な場合があります。 デバイスの状態に応じてポリシーを区別してください。EDRが導入された管理対象デバイス上で認証情報が侵害された場合のリスクプロファイルは、可視性のない管理対象外のデバイス上のそれとは根本的に異なります。ブラウザポリシーは、この非対称性を反映させる必要があります。

間違いその3：DLPポリシーにおいてAIツールの送信先を無視していること。多くの組織では、ブラウザのDLP設定を構成し、従来のシャドーITのカテゴリー（個人用クラウドストレージやウェブメールなど）へのアップロードをブロックしていますが、AIアシスタントを含めるのを忘れてしまっています。現在、AIツールは、貼り付けやアップロードされるデータの最も一般的な不正な送信先の一つとなっています。SWGおよびDLPのURLカテゴリを更新して生成型AIサービスを含め、他の未承認アプリに対して適用しているのと同じクリップボードおよびアップロードの制限を適用してください。

間違いその4：ブラウザ制御をSSEポリシーの拡張機能ではなく、独立したプロジェクトとして扱うこと。ブラウザ制御が別のコンソールに配置され、個別のポリシーが適用されている場合、SOCが注目しないツールの一つとなってしまいます。フェーズ3以降、これらをSSEプラットフォームに統合し、単一のインシデントワークフロー内で、ブラウザのイベントとCASB、SWG、ZTNAのイベントを関連付けられるようにしてください。

間違いその5：ポリシーを作成する前に、SaaSアプリケーションを機密性レベル別に分類することを怠ること。機密性レベルに応じたSaaSインベントリがなければ、ブロックしすぎて（リスクの低いアプリケーションを隔離し、ユーザーに不満を抱かせる）か、ブロックが不十分で（重要なアプリケーションに制御が及ばない）かのいずれかになってしまいます。大企業では、数十から数百ものSaaSサービスが日常的に利用されており、分類は単なるオプションではなく、セキュリティ上の抜け穴とユーザーの反発の両方を回避するための、的確なポリシー策定の基盤となるものです。