🏩

IP 制限の Web サイトにサクッとアクセスする Clientless Web Isolation の使い方（と、さらなる可能性）

に公開
Security
Cloudflare
rbi
tech

はじめに

このご時世、送信元 IP アドレスを制限している Web サイトへの接続維持に管理工数がかかって何とかしたい、という話をよく聞きます。オフィスから組織のゲートウェイ経由でアクセスするのが前提だった時代にフィットした IP アドレス制限と違って、今はリモートワーク前提ですもんね。

そんな（変わりゆく）ユーザークライアント側のロケーション分散化と（今も現役アーキテクチャ）サーバー側の送信元 IP アクセス制限のギャップを埋め、サクッとアクセスする環境を考えてみます。

まず、この時代だからこそ使えるツールが思い浮かびます。
みなさまご存知クラウドベースのセキュアウェブゲートウェイたち。
でも、分散したユーザーを集約するために、

  • エージェント入れたり
  • PAC 展開したり
  • トンネル掘ったり
  • 通信経路をこねくり回したり

複雑で面倒になりがちです。
そして 複雑さや面倒さのもたらす結果は… これもみなさま経験済みと思います。

もっと簡素に軽く、かつ安全に、やりたいことに届きたい。

で、勝手に要件を決めました。
これ全部実現します。

要件 目的 重要
ブラウザーさえあれば、地球上どこからでも同じ送信元 IP で宛先にアクセスできる 軽さ 必須
ブラウザーは素で使う
（明示プロキシーや PAC 設定の展開とか、面倒でヌケも出るのは拒絶）		 軽さ
安全		 必須
その IP を通すことで、Web サイトの応答速度を劣化させない
（むしろ上げる）		 軽さ 必須
組織で導入済みのセキュリティと併用でき、邪魔をせず、強化する
（エージェントだらけ、そしてまた… の回避）		 軽さ
安全		 必須
その IP を得れるのは特定のユーザーやグループだけ 安全 必須
IP 制限の Web サイトだからといって無条件に信頼しない
（悪意あるコード、マルウェア、ウィルスはブラウザーに渡さない）
HTTPS でもブラウザーに TLS decryption 用証明書の展開せず実現		 安全 必須
ユーザーやグループの属性に応じて、情報利用の制限をかける
（印刷を禁止、機密情報のダウンロード禁止、など）
HTTPS でもブラウザーに TLS decryption 用証明書の展開せず実現		 安全 オプション
送信元 IP 固定はインターネットフェイシングな Web サイトだが
インターネットに晒してない プライベート Web サイトにも接続できれば可		 軽さ
安全		 オプション

実現方法

Cloudflare の Remote Browser Isolation（Clientless Web Isolation）と Dedicated Egress IP で実現します。箱やソフトのインストール、設定ファイルや証明書の配布管理、不要です。


1,3,4,5 は Cloudflare プラットフォーム側に存在

宛先への HTTP リクエストはこんな感じで流れます。

概要
1 ブラウザーはリモートブラウザー https://<team_name>.cloudflareaccess.com/browser/<宛先 URL> をリクエスト
（宛先 URLがない場合はデフォルトのページが開くのでそこで宛先を指定）
2 リクエストは IDP でのユーザー認証など Access policy を経てリモートブラウザー利用が認可される
（IDP がないときは Email の One Time Pin 認証も可能）
3 リモートブラウザーは宛先 URL にリクエスト
4 リクエストは DNS policy Network policy HTTP policy に従い処理される（許可・拒否、など）
5 リクエストは Egress policy に従い処理される（エグレス IP の決定）
6 指定のエグレス IP を適用されたリクエストは IP 制限中の Web サイトに受け入れられる

派生のユースケース

余談ですが、ここで大事なことに触れておきます。

この構成、エグレス IP 固定のケースだけでなく、広く使えます。
組織のお悩みを解決できるか、想像してみてさい。

繰り返しますが、箱やソフトのインストール、設定ファイルや証明書の配布管理、不要です。

たとえば

制限されたインターネット接続環境

  • インターネットへの接続が制限がされている環境で
  • 一部端末だけインターネットに接続させたい
  • 接続先は制御したいが、制御ポイントはローカルのファイアウォールでなく、クラウドで
  • 外の悪いやつらを中に連れてこないよう、不審サイトへの接続拒否やマルウェア回避、アンチウィルス対策などは必須


特定の端末だけはインターネット接続許可、リモートブラウザーだけ許可、Gateway でセキュア化

プライベート Web サイトへのアクセス

  • 組織内部のインターネットにフェイシングしてない Web サイトがあり
  • 自組織だけでなく、委託先（外部組織）のプロジェクトに利用しているが
  • わざわざ間口の広い VPN クライアントを発行し、ユーザー管理（特に消す方）やアクセス範囲を狭める制御が煩雑
  • 特定の Web サイトのみブラウザーでアクセスさせ、サイトごとに操作を制御したい
  • 監査のためコピーやダウンロードの操作ログまですべて取るとよい

この構成はサーバー側に ⑦ App tunnel（cloudflared）を追加します。

インターネットに晒さない Web サイトにブラウザーのみでアクセス、自組織はダウンロード許可、外部組織はダウンロード禁止、操作はすべてログに取る

接続例
  • プライベート IP アドレスでの接続
  • 内部ドメイン名での接続

    この内部ドメインの名前解決も Cloudflare の中に建て、ホスト名でのアクセスを可能にします。
    超便利です。
  • 操作ログもちゃんと取れます、もちろんラクに。
    コピー操作をブロック
    {
  "AccountID": "*",
  "Decision": "block",
  "DomainName": "tun1.corp.oymk.work",
  "Metadata": "",
  "Timestamp": "2025-10-04T08:02:30Z",
  "Type": "copy",
  "URL": "https://tun1.corp.oymk.work/",
  "UserEmail": "user@example.com",
  "UserID": "*"
}

ユーザー体験と効果（エグレス IP アドレスの確認）

エグレス IP の話に戻り、ユーザー体験とその効果を見てみます。

  1. リモートブラウザーに接続
    https://<team_name>.cloudflareaccess.com/browser/
    ユーザーが所属する IDP を選択

  2. ユーザー認証（Entra ID）

  3. リモートブラウザーが表示
    上段の青バーか中段の入力枠に宛先 URL（あるいは検索文字）を入力

    検索文字列の場合、検索エンジンが結果を表示（duckduckgo が利用されていた）

  4. 宛先に接続（送信元 IP アドレス確認サイト）
    このリクエストがマッチする固定エグレス IP 104.*.*.91 を使って接続されている

違うユーザーで接続

  1. ユーザー認証（Google Workspace を選択）

  2. 宛先に接続（送信元 IP アドレス確認サイト）
    このリクエストがマッチする固定エグレス IP 8.*.*.45 を使って接続されている

設定内容

Cloudflare の設定は ① Clientles Web Isolation アプリケーションの有効化とそのアプリにつける Access ポリシー ② Egress IP ポリシーの適用です。

Clientless Web Isolation

Browser Isolation の契約により利用できるようになります。

設定 > ブラウザ分離 > クライアントレス Web 分離

Clientless Web Isolation を有効にします。

設定 > ブラウザ分離 > アクセス許可

ポリシー

リモートブラウザーにログインするための認可条件を指定します。

ログイン方法

ポリシーで指定したユーザーに関連する IDP はすべて選択します。

エグレス IP

Gateway > エグレスポリシー

Dedicated egress IPs の契約により Cloudflare からエグレス IP が割り当てられます。
それをもとに割当ポリシーを作成します。
ルールは上から評価され、マッチした エグレス IP が選択されます。

詳細（ポリシー 1）

マッチ条件に宛先ホストとリモートブラウザーログインユーザーを指定しています。

宛先ホスト リモートブラウザー
ログインユーザー		 選択 IP
api.ipify.org *@*.onmicrosoft.com 104.*.*.91
詳細（ポリシー 2）

マッチ条件は宛先ホストのみです。

宛先ホスト リモートブラウザー
ログインユーザー		 選択 IP
api.ipify.org *@example.com 8.*.*.45

おまけ：操作をコントロールする

ブラウザーでの操作をコントロールできます。

試しに BOX へのアクセスを制御してみます。
ここではリモートブラウザーのログインユーザーによって許可を変えます。

リモートブラウザー
ログインユーザー		 BOX 操作
Entra ID フリーに許可
Google Workspace アップロード、ダウンロード、コピー禁止


見やすさのために Egress policy を抜いてますが、もちろん併用できます。

特徴は Gateway の HTTP policy 条件（リモートブラウザーのログインユーザーなど）で読み書きの権限を変えるところです。たとえば BOX のログインアカウントが同じでも、リモートブラウザー接続の属性状況によって読み書き権を変えられます。

ユーザー体験と効果

Entra ID ユーザーは制限なく操作できました。
期待通り Google Workspace ユーザーでは指定の操作が禁止されました。

ブロック表示は将来的には管理者が編集できそう

設定内容

Gateway > ファイアウォールポリシー > HTTP ポリシー

Google Workspace ユーザー email が *@example.com には下記の isolate 設定がされています。

一方、Entra　ID ユーザーはデフォルトのすべて許可です。

TLS decryption について

エグレス IP を適用するだけならリモートブラウザーからのリクエストを TLS decryption する必要はありませんが、この isolate 設定でリモートブラウザー操作を制御したい場合は TLS decyription される必要があります。

そのため、他の HTTP ポリシーの Do not inspect 条件に当たらないようにします。
ただ、Clientless Web Isolation での宛先 URL との TLS の通信は必ずリモートブラウザーが発動するので、ローカルブラウザー側に Gateway HTTP TLS decyription 用のルート証明書を配置する必要はありません。


制御が効いている状況でもローカルブラウザーは <team_name>.cloudflareaccess.com と通信


Eicar ファイルのダウンロードを試み、ブロックされたが、証明書の警告は出ない

一方、In-line 型（Access 以外）の場合、HTTP ポリシーの isolate 設定をトリガーに isolation が発動します。そのためには TLS decryption が必要で、ブラウザーにルート証明書の配置することになります。
その点でも Clientless Web Isolation の運用は軽くなります。

ログ

ユーザーの操作のログも Logpush で取得可能です。

biso_user_actions
Block された操作
{
  "AccountID": "*",
  "Decision": "block",
  "DomainName": "app.box.com",
  "Metadata": "{\"URL\":\"https://public.boxcloud.com/d/1/b1!F*/download\"}",
  "Timestamp": "2025-10-04T08:18:12Z",
  "Type": "download",
  "URL": "https://app.box.com/folder/*",
  "UserEmail": "user@example.com",
  "UserID": "*"
}
{
  "AccountID": "*",
  "Decision": "block",
  "DomainName": "app.box.com",
  "Metadata": "",
  "Timestamp": "2025-10-04T08:18:38Z",
  "Type": "upload",
  "URL": "https://app.box.com/folder/*",
  "UserEmail": "user@example.com",
  "UserID": "*"
}
{
  "AccountID": "*",
  "Decision": "block",
  "DomainName": "app.box.com",
  "Metadata": "",
  "Timestamp": "2025-10-04T08:18:23Z",
  "Type": "copy",
  "URL": "https://app.box.com/file/*",
  "UserEmail": "user@example.com",
  "UserID": "*"
}
Allow された操作
{
  "AccountID": "*",
  "Decision": "allow",
  "DomainName": "app.box.com",
  "Metadata": "",
  "Timestamp": "2025-10-04T08:14:47Z",
  "Type": "copy",
  "URL": "https://app.box.com/file/*",
  "UserEmail": "adelev@hoge.onmicrosoft.com",
  "UserID": "*"
}

通信内容

Clientless Web Isolation 時のローカルブラウザーから見た通信宛先と全体の通信フローを見ておきます。

宛先ホスト

IDP が Entra ID の場合、Web サイト接続時に通信宛先ホストは以下でした。
当然ながら宛先 Web サイトへの通信は流れません。

宛先ホスト プロバイダー
1 <team_name>.cloudflareaccess.com Cloudflare
アクセス制御
2 content.browser.run Cloudflare
ブラウザー描画コマンド
3 login.microsoftonline.com Microsoft
4 login.live.com Microsoft
5 browser.events.data.microsoft.com Microsoft
6 aadcdn.msftauth.net Microsoft
7 imagedelivery.net 外部（Access ログインページのロゴ画像）
Cloudflare Imagesから呼んだ場合なので、このホスト名
  • 1,2 が Clientless Web Isolation が利用するホスト
    これは必ず通す必要があるので、Firewall などで許可します
  • 3-6 は IDP によって異なる
  • 7 は Access のログインページに管理者が指定した画像ソースによって異なる
    （この画像が GET できなくても動作に影響はない）

フロー

概要です。

ユーザー体験

リクエストをリモートブラウザーに誘導する例を書いておきます。

ブックマーク

リモートブラウザー起動状態でブックマークすると

普通にブックマーク文字列が表示されました 経済ニュース速報...。

クリックすると、違和感なく使えます。

Safari でも似たような感じでした。

リダイレクト

Dev docs にはサードパーティの SWG などでリダイレクトさせる設定例が載っています。

ブラウザー拡張

ブラウザー拡張を使い、https://<team_name>.cloudflareaccess.com/browser/ を自動追加させ、常にリモートブラウザーを通すこともできます。

ブラウザー拡張コード サンプル（Chrome）

サードパーティを利用せずテスト用に記載したのがこちらです。
参考まで。

manifest.json
// manifest.json
{
  "manifest_version": 3,
  "name": "Cloudflare Remote Browser Redirector",
  "version": "1.0",
  "description": "Automatically redirects URLs to a Cloudflare remote browser session using declarativeNetRequest.",
  "permissions": [
    "declarativeNetRequest"
  ],
  "host_permissions": [
    "<all_urls>"
  ],
  "background": {
    "service_worker": "background.js"
  }
}
background.js
// background.js

// Cloudflare RBI (Remote Browser Isolation) domain — replace with your own
const myCloudflareDomain = "<team_name>.cloudflareaccess.com";
const browserDomain = "content.browser.run";

// Domains that should be excluded from redirect
const excludedDomains = [
  myCloudflareDomain,         // Cloudflare Access domain
  browserDomain,              // Cloudflare Remote Browser domain
  "accounts.google.com",      // Example: OIDC identity provider
  "intranet.example.local",   // Example: internal intranet domain
  "www.trusted-site.com"      // Example: trusted external site
];

chrome.declarativeNetRequest.updateDynamicRules({
  removeRuleIds: [1],
  addRules: [
    {
      id: 1,
      priority: 1,
      action: {
        type: "redirect",
        redirect: {
          // Redirect any URL into Cloudflare RBI session
          regexSubstitution: "https://" + myCloudflareDomain + "/browser/\\1"
        }
      },
      condition: {
        regexFilter: "^(https?://.*)",
        resourceTypes: ["main_frame"],
        excludedRequestDomains: excludedDomains,
        excludedInitiatorDomains: excludedDomains
      }
    }
  ]
});

console.log("Cloudflare redirector extension loaded with exclusion list.");


Chrome に拡張コードを追加、ローカルブラウザーのアドレスバーに google を入れるとリモートブラウザーで Google 検索が開く

App ランチャー

デフォルトでは Clientless Web Isolation は App ランチャーに表示されません。
表示させるには Access アプリケーションの Bookmark を使います。
https://<team_name>.cloudflareaccess.com/browser/ を登録すると他のアプリケーションと共に App ランチャーに表示され、クリックするとリモートブラウザーに接続されます。

他の面白い使い方

他にも使い方があり、面白いです。

たとえば Access。

WAF や DDoS 緩和もついてくるし。。。
よりセキュアな Web アプリを提供したい場合はうってつけだと思うんですが。

以上です。
応用範囲はいろいろですが、まずは IP アドレス制限のあるサイトへの接続を簡単に構築することができました。

Discussion