規制産業向けブラウザ分離:医療、金融、政府機関
- ブラウザの隔離機能により、ローカルデータが残留することを防ぎます。Webコンテンツをリモートでレンダリングするため、PHI、カード保有者データ、CUIがシステム内に残留することはありません。
- 提案されているHIPAAセキュリティ規則の改正案では、技術的保護措置は「適用可能」なものではなく、義務付けられるものとなる。
- PCI DSS 4.0 では、消費者のブラウザで実行されるスクリプトに対する管理が義務付けられるようになりました。
- NIST SP 800-171 Rev 3 は、CUI 保護のためのアーキテクチャ的アプローチとして、隔離を明示的に推奨している。
- 米国防総省(DoD)のCBIIプログラムは、連邦政府規模でのブラウザ分離の有効性を実証している。
- コンプライアンス・マッピングは、一度きりの作業ではありません。各規制の枠組みには、継続的なモニタリング、監査ログの記録などが求められます。
- 一律に導入するのではなく、リスクが最も高いブラウザのシナリオから着手してください。
規制対象組織は、ブラウザのセキュリティ問題の特異な形態に直面しています。すなわち、ユーザーは業務を行うためにWebへのアクセスを必要としますが、管理されていないブラウザセッションが1つあるごとに、規制対象データの漏洩や、そのデータを処理するシステムへの脅威の侵入につながる潜在的な経路が生まれます。ブラウザの分離技術は、Webコンテンツをクラウドベースの環境で実行することでこの問題に対処するため、悪意のあるコード、キャッシュされたデータ、セッションの残骸などがエンドポイントに接触することは一切ありません。 医療、金融、政府機関のチームにとって、問題は「分離がセキュリティ上の価値をもたらすかどうか」ではなく、臨床、取引、および業務のワークフローを維持しつつ、HIPAA、PCI DSS、NIST SP 800-171、およびFedRAMPの要件に明確に準拠する形で、これをどのように導入するかということです。
このガイドでは、3つの規制環境すべてにおいてブラウザ分離を導入する際の、前提条件、段階的な導入、コンプライアンス対応状況のマッピング、統合ポイント、成功指標、およびよくある間違いについて解説します。
前提条件:導入前に準備すべきこと
規制対象の環境でブラウザ分離を導入する前に、3つの基本機能が稼働している必要があります。そうでなければ、分離は監査人が管理措置と関連付けられない、コストのかかる層となってしまいます。
データの分類とインベントリ。分類されていないものを隔離することはできません。共有の看護用ワークステーションで隔離措置を導入する病院は、どのワークフローがePHI(患者ポータルへのアクセス、検査結果の確認など)を扱うもので、どのワークフローが管理業務(シフトスケジュールの確認など)であるかを把握しておく必要があります。 銀行のトレーディングデスクでは、隔離ポリシーによって調査目的の閲覧と決済ページへのアクセスを区別できるようにする前に、カード保有者データ環境の範囲を明確に定義しておく必要があります。データインベントリを完了していない場合、ブラウザの隔離によりポリシーの不備が生じ、監査員に指摘されることになります。
IDおよびアクセス管理の統合。ブラウザ隔離ポリシーは、ユーザーが誰であるか、どのデバイスを使用しているか、そして何にアクセスしているかに基づいて発動されなければなりません。つまり、IdP、ディレクトリサービス、およびデバイスの状態チェックの結果を、隔離ポリシーエンジンに反映させる必要があります。例えば、同じ勤務シフト中に、CUIに関連するOSINT情報源と無害な内部文書の両方にアクセスする政府請負業者のアナリストを想定してみてください。隔離は、すべてのセッションを一律に適用するのではなく、アクセス先のリスクプロファイルに基づいて選択的に適用されなければなりません。 CISAの「ゼロトラスト成熟度モデル v2.0(2023年)」では、「最適」な成熟度段階において、特権セッション、管理対象外のセッション、または高リスクのセッションに対して自動的に隔離を適用することを推奨しており、IDを認識した隔離が目標状態であることを強調しています。
既存のコンプライアンス関連文書。何かを隔離する前に、現在のシステムセキュリティ計画(SSP)、リスク分析、またはPCI DSSの適用範囲に関する文書を整理してください。 NIST SP 800 171 Rev 3 (2024) では、セキュリティ要件は、CUI を処理、保存、または送信する非連邦システムのコンポーネントに適用されると規定されています。ブラウザの隔離機能を追加すると、セキュリティ境界が変更されます。SSP や適用範囲に関する文書を更新しない場合、コンプライアンス上のギャップを解消するどころか、新たなギャップを生み出すことになってしまいます。
フェーズ1:コンプライアンス・マッピング — 各フレームワークが実際に求めていること
最初の実装段階は、規制への適合です。各フレームワークには特定の制御機能があり、ブラウザの分離によって監査可能な証拠が生成されます。

HIPAAセキュリティ規則
提案されているHIPAAセキュリティ規則のNPRM(HHS、2024年12月)では、規制対象事業体に対し、ワークステーションを含む関連する電子情報システムを一貫した方法で構成するための技術的統制を確立し、導入することが求められている。また、限られた例外を除き、保存中および転送中のePHIの暗号化も義務付けられている。
ブラウザの分離は、HIPAAのいくつかの技術的保護措置を直接サポートしています。アクセス制御基準(§164.312(a))では、ePHIへのアクセスを権限のある者に限定する技術的ポリシーが求められています。共有の救急外来ワークステーションで、臨床医が分離されたブラウザセッションを通じて患者ポータルにアクセスした場合、タブを閉じるとセッションは終了します。これにより、次のユーザーが発見できるような形で、PHIがローカルキャッシュ、クッキー、またはダウンロードフォルダに残留することはありません。 伝送セキュリティ基準(§164.312(e))では、転送中のePHIを保護することが求められています。分離機能により、生データではなくレンダリング命令のみがエンドポイントにストリーミングされることが保証されます。
提案されている規則における最大の変更点は、「必須」と「対応可能」な保護措置の区別が撤廃され、限られた例外を除き、すべての実施仕様が義務化されることです。 これまでワークステーションの管理措置を「対応可能」として文書化し、その実施を見送っていた医療機関は、これらの不備を是正する必要があります。この問題の規模は桁外れです。『HIPAA Journal』の「2025年医療データ漏洩報告書」によると、2024年には742件の大規模な医療データ漏洩がOCRに報告され、2億8,900万人の個人情報が流出しました。
PCI DSS 4.0
PCI DSS v4.0.1は、現在適用されている決済カードセキュリティの規格であり、2025年3月31日をもって、将来施行予定の51項目の要件すべてが義務化されました(PCIセキュリティ基準協議会、2024年)。その中でも、ブラウザの分離に関する2つの要件が特に注目されます。
要件 6.4.3 では、決済ページにおいて顧客のブラウザで読み込まれる、または実行されるすべてのスクリプトについて、その一覧作成、承認、および完全性の検証を行うことが義務付けられています。非対面取引を処理する金融機関にとって、これは、顧客のブラウザで実行されるスクリプトが監査対象に含まれるようになったことを意味します。ブラウザの隔離機能により、これらのセッションをサンドボックス化することができ、たとえ悪意のあるスクリプトが注入された場合でも、それが隔離された環境内で実行され、カード会員データ環境には決して到達しないことが保証されます。
要件 11.6.1 では、決済ページスクリプトに対する不正な変更を検知する仕組みが求められています。証券会社のトレーダーが、社内取引システムへのアクセスに使用するのと同じワークステーションで、サードパーティの株式調査サイトを閲覧した場合、ドライブバイダウンロードによってエンドポイントが侵害され、CDE へ攻撃が波及する可能性があります。外部サイトへのアクセスをすべて隔離することで、取引システムのネットワークセグメントが、検証されていないウェブコンテンツを受け取ることがないよう確実に防ぐことができます。
NIST SP 800-171 Rev 3(CUIの保護)
NIST SP 800-171 Rev 3 (2024) では、非連邦機関は、CUI 処理システムの構成要素を別のセキュリティドメインに隔離することで、CUI セキュリティ要件の適用範囲を限定することができると規定されている。これは、サブネットワーク、境界保護装置、および情報フロー制御メカニズムなどの「アーキテクチャおよび設計概念」を通じて実現可能である。
ブラウザの隔離は、この指針の典型的な実装例です。機密情報(CUI)に分類されたプロジェクトに携わりながら、海外でホストされているウェブサイトからオープンソース情報にアクセスする必要がある防衛関連企業のエンジニアは、隔離されたブラウザセッションを通じてこれを行うことができ、CUIの境界を完全に維持できます。潜在的に敵対的なサイトからのウェブコンテンツ、スクリプト、クッキーは、CUIの範囲内にあるシステムコンポーネントに一切接触することはありません。
FedRAMP
FedRAMPはNIST SP 800-53のベースラインを採用しており、クラウドサービスプロバイダーに対し、第三者評価機関(3PAO)による独立したセキュリティ評価の完了を義務付けています。AWSのコンプライアンス文書(2025年)によると、FedRAMP「Moderate」は、FedRAMPの認可を受けたすべてのクラウドサービス提供の約80%を占めています。
連邦政府の環境に導入されるブラウザ分離ソリューションは、それ自体が適切な影響レベルにおいてFedRAMPの認可を受けている必要があります。これは絶対条件であり、連邦政府機関で認可されていない分離サービスを使用することは、リスク軽減策ではなく、コンプライアンス違反となります。 米国防総省(DoD)はすでに、このモデルを大規模に実証済みです。DISAの「クラウドベース・インターネット・アイソレーション(CBII)」プログラムは、340万~360万人のNIPRNet利用者を対象に設計されており、任務に必須ではない商用ウェブ閲覧セッションを処理しています(米国陸軍、2021年)。 DISAの要件・分析局によると、このプログラムにより、インターネットアクセスポイントを防御するサイバーセキュリティツールの継続的なアップグレードが不要になるため、国防総省は3億ドル以上のコスト削減が見込まれています。
フェーズ2:アーキテクチャおよび統合設計
コンプライアンス・マッピングが完了したら、次の段階として、ブラウザの隔離機能を既存のセキュリティスタックにどのように組み込むかを設計します。隔離機能は単独で動作するものではなく、 secure web gateway ポリシー、DLPエンジン、CASB制御、IDプロバイダー、およびSIEMインフラストラクチャと連携する必要があります。

医療現場の事例 — 共有臨床ワークステーション。看護ステーションや医師の執務室に計2,000台の共有ログインワークステーションを配備している病院では、すべての外部Webトラフィックを、SWGに統合されたブラウザ隔離機能を経由させています。 内部のEHRへのアクセスは隔離をバイパスしますが(すでに信頼境界内にあるため)、製薬会社の参照データベース、保険ポータル、継続教育プラットフォームなどの外部サイトはすべて、隔離されたセッション内で読み込まれます。DLPポリシーは、ダウンロードが許可される前に隔離レイヤー内でコンテンツを検査し、患者リストを個人のメールやクラウドストレージにエクスポートしようとする試みをブロックします。セッションの記録は、HIPAAの監査証跡要件を満たすためにSIEMに送信されます。
金融業界のシナリオ — トレーディングデスクと支店業務。ある中堅証券会社は、トレーディングフロアのワークステーションにおいて、ホワイトリストに登録されていないすべての外部サイトへのアクセスを隔離しています。 SWGポリシーにより、承認済みの金融データ端末や社内アプリへの直接アクセスは許可されますが、外部のリサーチサイト、ニュースサイト、広告掲載ページなどは隔離された環境で表示されます。クリップボード制御により、隔離されたセッションからローカルデスクトップへのデータのコピー&ペーストが防止されます。これにより、PCI DSSのネットワークセグメンテーション要件を満たしつつ、トレーダーが必要なリサーチツールを利用できるようになります。カード決済を処理する支店においては、決済処理アプリケーションを隔離することで、Magecart型のスクリプト注入攻撃を確実に封じ込めます。
政府機関のシナリオ — 非機密ネットワークにおけるOSINT分析。情報分析官は、NIPRNet上の隔離されたブラウザセッションを通じて、海外でホストされているOSINT情報源(ニュースサイト、ソーシャルメディアプラットフォーム、文書共有サービスなど)にアクセスする。 この隔離層は、実行可能コンテンツを削除し、マルウェアスキャンを通過しないファイルのダウンロードをブロックし、アナリストが誤ってCUI処理環境に悪意のあるJavaScriptを持ち込むことを防止します。アナリストの身元情報とセッションのメタデータはSIEMに送信されるため、すべてのアクセスがログに記録され、NIST 800-171の評価目的で監査が可能となります。
フェーズ3:ポリシーの設定と展開
効果的な展開には、すべてか無かの導入ではなく、リスクに応じた段階的なアプローチが採用されています。

Tier 1 — リスクが高く、コンプライアンスへの影響も大きいセッション。侵害された場合に規制上の影響が最も大きくなるシナリオ(患者ポータルにアクセスする共有臨床用ワークステーション、CDE内の決済ページへのセッション、および分類されていない外部サイトにアクセスするアナリスト用ワークステーションなど)に対して、まず隔離措置を講じます。これらはユーザー数は少ないものの、コンプライアンス上のリスクが極めて大きいものです。
ティア 2 — 従業員全体による外部ウェブ閲覧。規制対象セグメントに属するすべてのユーザーについて、一般的な外部ウェブアクセスにも隔離措置を拡大します。ここで、SSE プラットフォームとの統合が真価を発揮します。単一のポリシーエンジンにより、URL カテゴリ、ユーザーのリスクスコア、デバイスの状態に基づいて、トラフィックを隔離環境、SWG、またはダイレクトアクセスのいずれかにルーティングできます。 2025年のVerizon DBIRは、これがなぜ重要なのかを裏付けています。基本的なWebアプリケーション攻撃の88%で盗まれた認証情報が使用されており、それらの認証情報の多くは、ブラウザを介した攻撃ベクトルを通じて配信された情報窃取型マルウェアに由来するものでした。
レベル 3 — 管理対象外のデバイスおよび外部業者によるアクセス。個人用デバイスから規制対象のアプリケーションにアクセスする外部業者、出張中の従業員、および BYOD ユーザーは、アクセス制御において最も困難な課題となっています。 リバースプロキシまたはクライアントレスアーキテクチャを通じて提供されるブラウザ分離技術により、これらのユーザーは、管理対象外のエンドポイントにデータが残ることなくアプリケーションを操作できるようになります。これは、出張中の看護師が病院から支給された共有タブレットからEHRシステムにアクセスする医療分野や、契約業者が個人のノートPCからCUI関連システムにアクセスする政府機関において、特に重要な意味を持ちます。
Skyhigh Securityremote browser isolation は、統合型SSEプラットフォームの一環としてSWG、CASB、DLPと連携し、これら3つの層すべてが単一のポリシーエンジンと監査証跡を共有できるようにします。
成功の測定:監査人にとって重要な指標
測定可能な成果がないままブラウザ分離を導入することは、根拠のないセキュリティ投資に他なりません。そして、監査人はその根拠を求めています。
エンドポイント上のデータ残留の削減。隔離措置を実施する前に、規制対象のワークステーションについて、機密データ(医療分野ではPHI、金融分野ではCHD、政府機関ではCUIマーカー)を含むブラウザキャッシュのベースラインスキャンを実施します。隔離措置の導入後、再度スキャンを行い、削減率を測定します。目標は、隔離されたセッションのローカルブラウザデータに規制対象データが一切残らないようにすることです。
監査ログの完全性。すべての隔離セッションについて、ユーザーの身元、宛先URL、セッション時間、データ転送操作(アップロード、ダウンロード、クリップボード、印刷)、および実施されたポリシー操作(ブロック、許可、隔離)を記録したログエントリが生成される必要があります。 これらのログフィールドを、特定の規制要件(HIPAA監査管理措置(§164.312(b))、PCI DSS要件10(ログ記録および監視)、およびNIST 800-171 AUファミリーの管理措置)に照らし合わせて確認してください。
Web経由の脅威によるインシデントの削減。隔離機能の導入前後において、マルウェアによるインシデント、フィッシングクリックによる侵害、ドライブバイダウンロードの発生状況を追跡します。ベライゾンの「2025年DBIR」によると、全情報漏洩事件のうちサードパーティが関与したケースは30%に急増し、前年の2倍に達しました。隔離機能は、サードパーティのWebコンテンツがローカルのエンドポイント上で実行されるのを防ぐことで、このリスクの表面積を直接的に低減します。
コンプライアンス上の指摘事項の解消率。直近のHIPAAリスク分析、PCI DSS ROC、またはNIST 800-171評価において、ブラウザに関連する指摘事項(転送中のデータの暗号化未実施、ワークステーションの制御措置の欠如、ネットワークのセグメンテーションが不十分など)が特定された場合は、それらの指摘事項のうち、隔離措置によって解消された件数を追跡してください。これにより、CISOは取締役会への報告に際して、具体的なROIの数値を示すことができます。
ユーザー体験の基準値。導入前後のページ読み込み時間、セッション放棄率、ヘルプデスクへの問い合わせ件数を測定する。隔離措置によって、救急救命室(ER)の臨床医が薬剤相互作用データベースにアクセスする能力が低下したり、トレーダーがリアルタイムの調査情報にアクセスする速度が遅くなったりすると、導入の進展が阻害され、ユーザーは制御を完全に無効にしてしまうような回避策を講じるようになるだろう。
規制対象のブラウザ分離環境の導入におけるよくある間違い
アイソレーションを、データ保護プロジェクトではなくネットワークセキュリティプロジェクトとして扱うこと。規制対象業界におけるブラウザのアイソレーションは、基本的に、規制対象データ(PHI、CHD、CUI)が本来あるべきでない場所に流出しないようにすることを目的としています。 コンプライアンス、プライバシー、データ保護のステークホルダーからの意見を取り入れずに、ネットワークチームが主導して導入を進めると、重要なポリシー設定を見落としてしまうことになります。医療分野だけでも、その情報漏洩の規模は甚大です。『HIPAA Journal』(2026年)によると、2024年には2億8900万人の個人のPHIが漏洩しており、その多くは監視されていないブラウザベースの経路を通じて管理環境からデータが流出していたものです。
すべてを隔離し、インフラに過大な負荷をかけること。すべてのWebトラフィックを一律に隔離することは安全に聞こえるが、遅延やコストの問題を引き起こし、導入を妨げる要因となる。米国防総省(DoD)のCBIIプログラムでは、すべてのトラフィックではなく、任務に不可欠ではないブラウジングのみを隔離しており、内部の.milおよび.govサイトは隔離を完全にバイパスしている。同様の論理を適用すべきである。すなわち、外部からのトラフィック、分類不能なトラフィック、および高リスクのトラフィックを隔離し、信頼できる内部アプリケーションや承認済みのSaaSプラットフォームへの直接アクセスを許可する。
導入後にコンプライアンス関連の文書を更新していない。ブラウザの分離を導入すると、セキュリティ境界が変更されます。PCI DSSの適用範囲に関する文書に依然として旧アーキテクチャが記載されていたり、HIPAAのリスク分析において分離が管理措置として考慮されていなかったりする場合、文書上の不備があり、監査員から指摘を受けることになります。導入の各段階において、それに応じた文書の更新を行う必要があります。
DLPとの連携を無視してはならない。data loss prevention のない隔離環境は、誤った安心感data loss prevention 。クリップボードやDLPの制御が有効になっていない場合、医療従事者は隔離セッション内であっても、患者ポータルからPHIをコピーし、個人のメールに貼り付けることが可能である。DLPポリシーは、ネットワークの出口ポイントだけでなく、隔離環境内のコンテンツも検査しなければならない。
政府での利用に、FedRAMPの認可を受けていないソリューションを選択すること。これは当然のことのように思えますが、政府機関が商用隔離ツールのパイロット導入を行う際、その認可状況を確認せずに導入してしまうケースが頻繁に見られます。必要な影響レベルにおける3PAO評価に合格していないソリューションは、規制対象の政府ワークロードには使用できません。これだけは絶対に守らなければなりません。