プログラマブルSASE : SWG の「警告 -> 接続」を安全にする方法

警告の先に「保護」を置く必要があるのでは

多くの Secure Web Gateway (SWG) 製品は、リスクのあるサイトへのアクセス時に「Warn（警告）」アクションを提供しています。ユーザーに警告画面を表示し、「続行」ボタンを押せばアクセスできる、という仕組みです。これはユーザーへのリスク通知やコンプライアンスの観点で広く活用されています。

一方で、「続行」を押した後はどうなるのかですが、ユーザーの端末は対象サイトに直接接続されるようです。つまり警告画面は意思確認として機能しますが、接続後の技術的なセキュリティ保護がは十分ではないように思います。

この点について以下のような考え方を持って対応するべきと思います。

エンドユーザーに接続の可否を委ねるだけでは、安全性を十分に担保できない。

この設計思想に基づき、Cloudflare はリスクのあるトラフィックに対して Block（遮断） を基本としています。とはいえ、現実の運用では一律ブロックが難しいケースもあります。新規に登録されたドメインやグレーゾーンのカテゴリなど、「ブロックは厳しいがフリーアクセスにもしたくない」という要件です。

そこで本記事では、Cloudflare のプラットフォームならではのアプローチを紹介します。Block を維持しつつ、Workers で警告画面を提示し、同意後はリモートブラウザ分離（RBI）で安全に閲覧させる という設計です。警告の先にあるのは「直接接続」ではなく「隔離された環境」。これにより、ユーザーへの意思確認と技術的な保護を両立させることができます。

Programmable SASE — Cloudflare だからできること

Cloudflare の SASE プラットフォームには、他のベンダーにはない特徴があります。セキュリティ機能とプログラマブルなエッジコンピューティング基盤が同一のネットワーク上に統合されている点です。

Gateway がセキュリティポリシーの判定エンジン
Workers が判定結果を受けてカスタムロジックを実行
Browser Isolation が安全なアクセス手段を提供

これらが同じ Cloudflare のエッジ上で連携することで、他の SWG 製品では実現できない「警告 + 技術的保護」を単一プラットフォームで構築できます。サードパーティのツールや追加のインフラは一切不要です。

アーキテクチャ概要

ユーザーがリスクサイトにアクセス
        |
        v
+------------------------------+
|  Gateway HTTP Policy         |
|  Action: Block               |
|  Block behavior:             |
|    URL redirect -> Workers   |
|    Send policy context: ON   |
|                              |
|  -> 307 Redirect to Worker   |
+-------------+----------------+
              |
              v
+------------------------------+
|  Cloudflare Workers          |
|  (警告ページ)                  |
|                              |
|  - ブロック理由の表示           |
|  - リスクカテゴリの表示         |
|  - 組織ポリシーの説明           |
|  - 監査ログ記録 (KV)           |
|                              |
|  [隔離ブラウザで開く            |
|   ことを理解して接続] ボタン     |
+-------------+----------------+
              | 
              v
+------------------------------+
|  Clientless RBI              |
|  <team>.cloudflareaccess.com |
|  /browser/<元URL>            |
|                              |
|  - リモートブラウザで描画      |
|  - コピペ / DL / UL 制限可    |
|  - 印刷制限可                 |
+------------------------------+

Block アクションの URL redirect オプションを使う

Gateway の Block アクションには、ブロックページの代わりに任意の URL へ 307 Temporary Redirect を返すオプションがあります。さらに Send policy context を有効にすると、元の URL、ユーザーメール、カテゴリ、ルール ID などのコンテキスト情報がクエリパラメータとして付与されます。

https://warn-worker.example.workers.dev/warn
  ?cf_site_uri=https%3A%2F%2Frisky-site.com
  &cf_user_email=user@corp.com
  &cf_request_categories=New%20Domains,Gambling
  &cf_rule_id=6d48997c-...
  &cf_device_id=a3f1c9e2-...

これにより、Block を維持しながら Workers に処理を委譲する という設計が成立します。

各コンポーネントの詳細

1. Gateway HTTP Policy

項目	設定値
Policy name	`Warn-then-RBI`
Selector	Security Categories / Content Categories / Domain 等
Operator	in
Value	ブロック対象のカテゴリ
Action	Block
Modify Gateway block behavior	Override account setting with URL redirect
Redirect URL	Workers の URL
Send policy context	ON

2. Cloudflare Worker（警告ページ + 監査ログ + RBI リダイレクト）

Worker は以下の3つの責務を持ちます。

警告画面の表示 — Gateway から渡されたコンテキスト（URL、カテゴリ、ユーザー情報）を基に、ブロック理由とリスク説明を表示
監査ログの記録 — KV に監査ログを書き込み（RBI での接続履歴は HTTP ログで閲覧可能で、コンプライアンスや監査要件がある場合に利用価値があるかと）
Clientless RBI へのリダイレクト — 同意・認識後、https://<team>.cloudflareaccess.com/browser/<元URL> へ 302 リダイレクト

Worker が表示する警告画面では、ブロック理由、対象 URL、ユーザー情報、RBI の制限事項が明示され、ユーザーは「ブラウザ分離で開くことを理解して続行する」ボタンを押すことで認識を表明します。

3. Clientless Web Isolation（RBI）

Clientless Web Isolation は、WARP クライアントのインストールなしにリモートブラウザ分離を利用できる機能です。プレフィックス URL 形式でアクセスします。

https://<team-name>.cloudflareaccess.com/browser/<対象URL>

Worker からこの URL にリダイレクトすることで、ユーザーは隔離されたリモートブラウザ上で対象サイトを閲覧できます。ユーザーの端末上ではサイトのコードは一切実行されません。

4. RBI 経由トラフィック用の Isolate ポリシー

Clientless RBI 経由のトラフィックも Gateway を再度通過します。Block ポリシーに引っかかると RBI 内でもブロックされてしまうため、RBI 経由のアクセスを許可する Isolate ポリシー を Block ポリシーより上の優先順位で作成します。

優先順位	ポリシー	条件	Action
高	`Allow-via-RBI`	対象カテゴリ AND Host が `<team>.cloudflareaccess.com`	Isolate（制限付き）
低	`Warn-then-RBI`	対象カテゴリ	Block + URL redirect

Isolate ポリシーでは、以下のような制限を設定できます。

コピー＆ペースト: 禁止 / 隔離ブラウザ内のみ許可
ファイルダウンロード: 禁止 / リモートブラウザ内閲覧のみ
ファイルアップロード: 禁止
キーボード入力: 禁止
印刷: 禁止

一般的な SWG の「Warn」アクションとの違い

多くの SASE/SSE ベンダーの SWG には、ポリシーアクションとして「Warn」「Caution」「Continue」「Coach」などと呼ばれる警告機能が用意されていることがあります。名称はベンダーごとに異なりますが、基本的な仕組みは共通しています。

ここでは、こうした一般的な Warn アクションの仕組みを整理し、Cloudflare の「Block → 警告 → RBI」アプローチとの違いを考えてみます。

一般的な Warn アクションの仕組み

多くの SWG 製品で提供されている Warn 系アクションには、おおむね以下のような特徴があるようです。

警告画面の表示: URL カテゴリやリスクの理由をユーザーに提示する
ユーザーによる続行/中止の選択: 「続行」ボタンを押すとアクセスが許可される
監査ログの記録: 警告の表示やユーザーの選択がログに記録される
続行後の接続: ユーザーの端末が対象サイトに直接接続される

一部のベンダーでは、続行時にユーザーがアクセス理由を入力する「Justification（理由入力）」機能や、警告の表示・続行・中止をそれぞれ個別にログ記録する機能など、コンプライアンス面で優れた工夫が見られます。これらの機能は、監査やガバナンスの観点で大きな価値があります。

「続行後に直接接続」が意味すること

一方で、こうした Warn アクションに共通するのは、ユーザーが「続行」を選択した後、端末が対象サイトに直接接続される という点です。

[一般的な Warn フロー]

  ユーザー → リスクサイトにアクセス
          → SWG が警告画面を表示
          → ユーザーが「続行」を選択
          → 端末が対象サイトに直接接続
                |
                +-- JavaScript が端末上で実行される
                +-- マルウェアが端末にダウンロードされうる
                +-- フィッシングサイトに認証情報を入力できる
                +-- ゼロデイ攻撃の影響を受ける可能性

もちろん、SWG のインライン検査（URL フィルタリングやマルウェアスキャンなど）は引き続き動作します。しかし、これは Warn の有無にかかわらず Allow 時と同じ保護レベルです。警告画面を表示したこと自体が、技術的な保護を追加するわけではありません。

つまり、一般的な Warn アクションは ユーザーの意思確認とコンプライアンス上の記録 を主な目的としており、接続後の技術的なセキュリティ保護を提供するものではないといえます。

Cloudflare の「Block → 警告 → RBI」との構造的な違い

Cloudflare のアプローチでは、警告の先にあるのは「直接接続」ではなく「リモートブラウザ分離（RBI）」です。

[Cloudflare Block + RBI フロー]

  ユーザー → リスクサイトにアクセス
          → Gateway が Block (直接接続は常に不可)
          → Workers が警告画面を表示
          → ユーザーが同意 → 監査ログ記録
          → Clientless RBI でサイトを描画
                |
                +-- サイトのコードは Cloudflare のインフラ上で実行
                +-- 端末には画面の描画結果のみ送信
                +-- マルウェアは端末に到達しない
                +-- コピー・ダウンロード・アップロード・印刷を制御可能
                +-- ゼロデイ攻撃から端末を保護

脅威ごとの保護レベル比較

脅威	一般的な Warn → 直接接続	Cloudflare Block → RBI
マルウェアダウンロード	端末に直接ダウンロードされる。AV スキャンで検知できるものは阻止されるが、未知の脅威は通過する可能性あり	リモートブラウザ内に留まり、端末へのファイル転送を禁止できる
ドライブバイダウンロード	端末のブラウザの脆弱性を突かれる可能性あり	サイトのコードは端末上で実行されないため、影響を受けない
フィッシング（認証情報窃取）	ユーザーが直接サイトにフォーム入力可能	キーボード入力やクリップボードのペーストを制限できる
JavaScript ベースの攻撃	端末のブラウザ上で実行される	リモートブラウザ上で実行され、端末には描画結果のみ送信される
ゼロデイ脆弱性の悪用	未知の脆弱性には対応が難しい	リモートブラウザが使い捨てセッションで動作し、端末は影響を受けない
データ漏洩（外部への持ち出し）	サイトからのコピーやダウンロードは自由	コピー、ペースト、ダウンロード、アップロード、印刷を個別に制御できる

RBI との統合について

多くの SASE/SSE ベンダーは RBI 機能を提供していますが、一般的に Warn 系アクションと RBI は独立したポリシーアクションとして設計されています。「警告を表示した後、ユーザーの同意を得て RBI で閲覧させる」というフローを実現するのはパフォーマンスや実装コストの面から考えると、ユーザーとしてもベンダーとしても難しいのではと。

Cloudflare の場合、Gateway の Block + URL redirect、Workers によるカスタムロジック、Clientless RBI という3つの機能を連携させることで、このフローをプラットフォーム内で完結させています。
そして Cloudflare のネットワーク網やエッジの仕組みは他ベンダーではできない実装の容易さを提供できています。

コンプライアンス面の補足

一部のベンダーでは、Warn アクションにおけるコンプライアンス機能が非常に充実しています。たとえば、ユーザーがアクセス理由を自由記述で入力できる機能や、「警告表示」「続行選択」「中止選択」をそれぞれ個別のログとして記録する仕組みなどは、監査の観点で大きな価値があります。

Cloudflare の本設計でも、Workers のフォームに理由入力フィールドを追加することで、こうしたコンプライアンス要件に対応できます。さらに、その先の接続が RBI で保護されるため、コンプライアンスとセキュリティの両方を同時に満たすことが可能です。

この比較から見えること

一般的な Warn アクションには、意思確認や監査記録としての明確な価値があります。一方で、「続行」後の接続が保護されないという構造は、セキュリティの観点では課題が残ります。

警告疲れ（Alert Fatigue）: 繰り返し表示される警告に対して、ユーザーが条件反射的に「続行」を押してしまう傾向がある
リスク判断の難しさ: エンドユーザーはセキュリティの専門家ではないため、警告の内容から接続の安全性を正しく判断することは難しい
保護の不連続性: 警告を表示するところまでは手厚いが、続行後は通常の Allow と同じ保護レベルになる

Cloudflare の「Block → 警告 → RBI」アプローチは、こうした課題に対するひとつの解として、警告の先にも技術的な保護を置くことで、安全性と利便性の両立を目指しています。

ブロックが前提であるため、直接接続は常に発生しない
警告画面でリスクと制限事項を丁寧に説明し、形骸化を防ぐ
同意後も RBI による技術的な保護 が継続する
監査ログやアクセス理由の記録も Workers で柔軟に実装できる

セキュリティ上の考慮事項

懸念	対策
Worker URL を直接叩いてバイパス	Worker 側で CSRF トークン (HMAC) を検証。Gateway 経由でない不正リクエストを排除
RBI URL を直接叩いてバイパス	Clientless RBI に Access Policy を設定し、認証を強制
同意の形骸化	監査ログをすべて記録。同意の有効期間を制御可能（例: Cookie で1時間）
RBI 内でのデータ漏洩	Isolation ポリシーでコピペ・ダウンロード・アップロード・印刷を制限

コスト

この設計で使用する各コンポーネントのコスト構造は以下の通りです。

コンポーネント	コスト
Gateway HTTP Policy (Block + URL redirect)	Zero Trust プランに含まれる
Workers	無料枠: 100,000 リクエスト/日。1日数回の利用なら無料枠で十分
KV（監査ログ）	無料枠: 読み取り 100,000/日、書き込み 1,000/日。十分に収まる
Browser Isolation	有償アドオン

Workers と KV は比較的小規模な利用であれば完全に無料枠内で運用できると思います。ただし、Browser Isolation（RBI）自体が有償アドオンであるため、RBI のライセンスは別途必要です。

デプロイ手順

1. Workers プロジェクトの作成とデプロイ

# プロジェクトディレクトリに移動
cd warn-then-rbi

# 依存関係をインストール
npm install

# KV Namespace を作成
wrangler kv namespace create "AUDIT_LOG"
wrangler kv namespace create "AUDIT_LOG" --preview

# wrangler.toml に出力された id と preview_id を記入
# TEAM_NAME も自組織のチーム名に変更

# ローカルで動作確認
wrangler dev

# デプロイ
wrangler deploy

2. Gateway Policy の設定

ポリシー 1: Block + URL redirect

Cloudflare One → Traffic policies → Firewall policies → HTTP
Add a policy
Selector: Security Categories (例: New Domains, Gambling)
Action: Block
Configure policy settings → Modify Gateway block behavior → Override account setting with URL redirect
Redirect URL: https://warn-then-rbi.<account>.workers.dev/warn
Send policy context: ON

ポリシー 2: RBI 経由トラフィック許可（優先順位を上に）

Add a policy
Selector 1: Security Categories in (同じカテゴリ)
And: SourceIP is 198.41.211.0（現状は RBI が利用する Anycast IP を利用するが、今後、RBI からの通信を識別するセレクタの実装が計画されている様子)
Action: Isolate
制限設定（コピー・DL・UL・印刷を制限）
ポリシーの順序で Block ポリシーより上に配置

3. Clientless RBI の有効化

Cloudflare One → Browser isolation → Browser isolation settings
Manage remote browser permissions → Enable Clientless Web Isolation
Access Policy で社内ユーザーのみアクセスを許可

まとめ

Cloudflare Gateway は「Block か Allow か」というシンプルな判定を基本としています。これは、エンドユーザーにセキュリティ上の判断を委ねないという設計思想に基づいたものです。

その上で、Gateway + Workers + Browser Isolation を組み合わせることで、「Block → 警告 → RBI」 という、警告と保護を両立するフローを構築できます。

Gateway Block + URL redirect — ブロックを維持しつつ Workers へリダイレクト
Workers + KV — 警告画面の表示、ユーザー同意の取得、監査ログの記録
Clientless Browser Isolation — 同意後、隔離されたリモートブラウザで安全に閲覧

一般的な SWG の Warn アクションは、ユーザーの意思確認やコンプライアンスの観点で大きな価値がある一方、続行後の接続は直接接続となり、技術的な保護が追加されるわけではありません。

本設計のアプローチは、警告画面による意思確認に加えて、RBI による技術的な保護を継続させることで、コンプライアンスとセキュリティの両方に応える ことを目指しています。

Cloudflare のプロダクトはすべてエッジ上で動作するため、追加のインフラやサードパーティのツールは必要ありません。プラットフォームのプログラマビリティを活かして、組織ごとの要件に合わせた柔軟な設計ができる — これが Programmable SASE の考え方です。

ユーザーの業務を止めず、かつエンドポイントを脅威から守る。そのバランスを取るためのひとつのアプローチとして、参考にしていただければ幸いです。