Cloudflareが「Custom Regions」発表。データ処理の地理的境界を自在に定義、ISMAP対応も拡充
Cloudflare（クラウドフレア）は2026年3月18日、同社の「Regional Services（リージョナル・サービス）」の大幅なアップデートを発表した。今回の更新では、特定の国や地域を自由に組み合わせてデータ処理の境界を定義できる「Custom Regions（カスタム・リージョン）」が導入された。
また、日本政府のセキュリティ評価制度である「ISMAP」への対応を含む、新しい管理リージョンの追加も行われている。これにより、企業はグローバルなDDoS防御の恩恵を受けつつ、各国の法規制やコンプライアンスに基づいた厳格なデータ局所化が可能になる。
データ主権（データ・ソブリンティ）への要求が世界的に高まる中、今回の機能拡張はインフラ構成の柔軟性を大きく向上させるものだ。記事によれば、従来の固定された地域選択から、個別のビジネスニーズに合わせた「独自の境界線」を引くフェーズへと移行したことが示唆されている。
Regional Servicesの仕組み：防御とコンプライアンスの両立
Cloudflareが提供するRegional Servicesは、グローバルネットワークの規模を活かしたセキュリティと、特定の地域内でのデータ処理という、一見相反する要素を両立させる仕組みだ。一般的なソブリンクラウド（主権クラウド）が特定の地域にインフラを隔離するのに対し、Cloudflareはネットワーク全体で攻撃を防ぎつつ、データの「中身」を扱う場所だけを限定する手法をとる。
グローバルなDDoS防御とローカル処理の共存
トラフィックの処理フローは、大きく4つの段階に分かれている。まず、ユーザーに最も近い世界各地のデータセンターでトラフィックを受け入れ、L3/L4（ネットワークおよびトランスポート層）レベルでのDDoS防御を即座に実行する。DDoS防御とは、大量の不要なデータを送りつけてサイトをダウンさせる攻撃を防ぐ仕組みであり、これを世界規模のネットワークで受けることで、攻撃を効率的に分散・無効化できる。
次に、パケットのメタデータを検査し、指定されたリージョン外のデータセンターに届いた場合は、Cloudflareのプライベートバックボーンを経由して指定リージョン内のデータセンターへと転送される。ここで重要なのは、この段階ではまだデータの復号（暗号化の解除）が行われていない点だ。
データの復号、つまりTLS（Transport Layer Security）の終端と、WAF（Web Application Firewall）によるL7（アプリケーション層）の検査、およびCloudflare Workersによるロジックの実行は、必ず指定されたリージョン内のデータセンターで行われる。これにより、機密性の高いデータの解析や処理を特定の地理的境界内に閉じ込めることが可能になる。最終的に、処理されたリクエストは再度暗号化され、オリジンサーバーへと送られる。
Custom Regionsによる柔軟なデータ制御
2020年の提供開始以来、Regional Servicesは欧州、英国、米国などの固定されたリージョンを提供してきた。しかし、各国の規制は複雑化しており、単一の国や特定の組み合わせでのデータ処理を求める声が強まっていた。これに応える形で登場したのがCustom Regionsだ。
独自の地理的境界を定義する「式」の活用
Custom Regionsでは、リストから地域を選ぶのではなく、開発者が「式（Expression）」を用いて処理場所を定義する。例えば、ISOコード（国コード）を使用して、特定の国を含める、あるいは除外するといった柔軟な設定が可能だ。記事では、以下のような定義例が示されている。
- 単一の国のみ（例：トルコのみ）
- 複数の国の組み合わせ（例：ドイツ、フランス、オランダ）
- 特定の国を除外（例：北米以外すべて）
この定義はCloudflareのインフラ全体に配布され、各データセンターが「自分はこのカスタムリージョンに含まれるか」を即座に判断する。インフラが拡張され、新しいデータセンターが稼働した場合も、条件に合致すれば自動的にリージョンに組み込まれるため、運用負荷が低いのも特徴だ。
実務における具体的な活用シナリオ
Custom Regionsの柔軟性は、法規制対応以外の場面でも威力を発揮する。著者のAndrew Berglund氏らは、早期アクセスユーザーによる活用例として、AI推論のリージョン化を挙げている。大規模言語モデル（LLM）へのプロンプトや応答を特定の国々に留めることで、パフォーマンスの最適化とデータ局所化の義務を同時に果たしているという。
また、政府機関との契約に基づいた特定の境界設定や、企業の組織構造（EMEA、APACなど）に合わせたガバナンスの適用にも利用されている。温度単位に華氏を使う国々（米国、バハマなど）といった、極めて特殊なグループ化さえも理論上は可能であり、ビジネス要件に合わせた「境界の設計」が可能になったと言える。
技術的アーキテクチャの深掘り
Custom Regionsがどのようにして最適なパフォーマンスと信頼性を維持しているのか、その裏側にはCloudflare独自のルーティング技術がある。単にデータを転送するだけでなく、リアルタイムのネットワーク品質を考慮した動的な決定が行われている。
最適なインレジョン・ルーティングの算出
リクエストがリージョン外のデータセンターに届いた際、どのリージョン内データセンターに転送すべきかの判断は、2段階のプロセスで行われる。まず、定義されたリージョンのメンバーセット（どのデータセンターが対象か）を特定する。次に、流入地点から見て最もパフォーマンスが高い転送先のリストを作成する。
このランキングは物理的な距離だけでなく、遅延（レイテンシ）、パケットロス、タイムアウトなどのネットワーク品質指標、さらには各拠点のキャパシティや負荷状況、稼働ステータスを基に算出される。この情報は「Quicksilver」と呼ばれるCloudflare独自の分散キーバリューストアを介して、エッジネットワーク全体に瞬時に共有される仕組みだ。
境界の強制とエラーハンドリング
Regional Servicesの設計思想において、レジリエンス（回復力）と境界の強制は最優先事項だ。ルーティング時には複数の候補地が考慮され、特定の拠点がダウンしている場合は、リアルタイムで次善の候補へとフェイルオーバー（切り替え）が行われる。ネットワークの監視データが不十分な場合は、新しいルーティング情報の更新を停止するなどの安全策も講じられている。
特筆すべきは「フェイル・クローズ（Fail-close）」設計だ。もし有効なリージョン内の転送先が一つも見つからない場合、リージョン外で処理を継続するのではなく、接続をエラーとして遮断する。これにより、意図しない場所でデータが復号されるリスクを物理的に排除している。
日本のISMAP対応と管理リージョンの拡大
今回のアップデートでは、Custom Regionsだけでなく、Cloudflareが定義・管理する「Managed Regions」も拡充された。新たにトルコ、アラブ首長国連邦（UAE）、オーストラリアのIRAP、そして日本のISMAPに対応したリージョンが追加され、合計で35のリージョンが利用可能となっている。
ISMAP（Information System Security Management and Assessment Program）とは、日本政府がクラウドサービスのセキュリティを評価するための制度だ。政府機関がクラウドを採用する際の基準となるものであり、民間企業にとっても信頼性の高いサービスの指標となっている。CloudflareがISMAP対応リージョンを明示したことは、日本の公共セクターや厳格なコンプライアンスを求める金融、インフラ企業にとって、導入の大きな後押しとなるだろう。
これらの管理リージョンは、Cloudflareの管理画面（ダッシュボード）やAPIから標準的な手順で有効化できる。一方で、独自の定義が必要なCustom Regionsについては、現時点ではセルフサービス形式ではなく、アカウントチームとの連携による個別設定が必要となる。将来的なセルフサービス化に向けた技術開発も継続されているとのことだ。
独自の分析：データ主権時代のインフラ戦略
Cloudflareの今回の発表は、エッジコンピューティングの役割が「高速化」から「統治（ガバナンス）」へと進化していることを象徴している。かつてのCDN（Content Delivery Network）は、いかにコンテンツを速く届けるかが主眼であったが、現代のWebインフラには「どこでデータを扱うか」という法的な正確性が求められている。
Custom Regionsが提供する「式による境界定義」は、コードによるインフラ管理（IaC）の流れを汲むものだ。地理的な境界をソフトウェア的に定義できるようになったことで、国境という物理的な制約を、アプリケーションのロジックと同じ柔軟さで扱えるようになった。これは、GDPR（欧州一般データ保護規則）などの地域特有の規制と、インターネットのボーダレスな利便性を橋渡しする重要な技術的解決策と言える。
特に日本市場においては、ISMAP対応の明文化が大きな意味を持つ。国内のレンタルサーバーやクラウドから、グローバルなエッジサービスへの移行を検討する際、最大の懸念事項であった「セキュリティ基準の適合」と「データの所在」がクリアされたからだ。今後は、グローバルなDDoS耐性を維持しつつ、日本の法域内で全ての重要処理を完結させる構成が、エンタープライズWebサイトの標準となっていくのではないだろうか。
この記事のポイント
- Cloudflareが「Custom Regions」を導入し、国単位でデータ処理の境界を自由に定義可能になった。
- 世界規模のDDoS防御を維持しつつ、TLS終端やWAF検査などのL7処理を指定地域内に限定できる。
- 日本政府のセキュリティ評価制度「ISMAP」に対応した管理リージョンが追加された。
- 独自のルーティング技術により、リージョン内での最適なパフォーマンスと、フェイル・クローズによる安全性を両立している。
- データ主権の確保とグローバルなセキュリティ対策を、一つのプラットフォームでシームレスに実現できる。
出典
- Cloudflare Blog「Introducing Custom Regions for precision data control」（2026年3月18日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Pingora OSSの脆弱性とリクエストスマグリング対策——Cloudflareが修正した3つの欠陥
Cloudflareは2026年3月9日、オープンソースのプロキシフレームワーク「Pingora（ピンゴラ）」に複数の脆弱性が存在することを公表した。対象となるのはPingoraをイングレスプロキシとして独自にデプロイしている環境だ。修正版となるPingora 0.8.0が同日にリリースされている。
発見された脆弱性は、HTTP/1.xにおける「リクエストスマグリング」に関連するものが中心だ。これはプロキシサーバーとバックエンドサーバーの間で、リクエストの終端解釈が食い違うことで発生する。最悪の場合、セキュリティ制御の回避や他ユーザーのセッション奪取につながる恐れがある。
Cloudflareの調査によれば、同社のCDNサービスや顧客トラフィックへの影響は確認されていない。Pingoraは同社ネットワーク内で広く利用されているが、インターネットからの直接的なトラフィックを受けるイングレスプロキシとしては使用されていないためだ。しかし、Pingoraを独自に公開サーバーとして運用しているユーザーは、速やかなアップデートが求められる。
Pingora OSSで発見された3つの脆弱性とリクエストスマグリングの脅威
今回のアップデートで修正されたのは、CVE-2026-2833、CVE-2026-2835、CVE-2026-2836の3件だ。これらはいずれも、HTTP/1.xの通信においてリクエストの境界を誤認させる「リクエストスマグリング（Request Smuggling）」を可能にする欠陥である。
リクエストスマグリングとは何か
リクエストスマグリングとは、1つのTCP接続の中で複数のHTTPリクエストを送る際、サーバー間で「どこまでが1つ目のリクエストか」の認識がズレる攻撃手法だ。例えるなら、レストランの注文票で「ハンバーグ1つ。あと、隣のテーブルの会計を私につけて」と巧妙に書き込み、店員に2つの指示を1つとして誤認させるような行為に近い。
プロキシサーバーが「これは1つのリクエストだ」と判断して通したデータの中に、バックエンドサーバーだけが「これは2つ目のリクエストだ」と解釈するデータが含まれている場合に発生する。これにより、プロキシ側のセキュリティチェックを素通りした不正なリクエストが、バックエンドで実行されてしまう。
独自展開のPingoraに潜むリスク
PingoraはRustで書かれた高速なプロキシフレームワークであり、Nginxの代替として注目されている。しかし、今回の脆弱性は、Pingoraをインターネットの窓口（イングレスプロキシ）として直接配置している場合に牙をむく。
攻撃が成功すると、攻撃者はPingoraのアクセス制御（ACL）を回避したり、共有バックエンドから取得したキャッシュを汚染したりすることが可能になる。また、他人の通信に自分のリクエストを割り込ませる「デシンク（非同期）攻撃」により、他ユーザーの認証情報を盗み出すリスクも指摘されている。
脆弱性1：101レスポンスを待たない不適切なプロトコル移行
1つ目の脆弱性（CVE-2026-2833）は、HTTPの「Upgrade」ヘッダーの処理に関するものだ。通常、WebSocketなどのプロトコルに切り替える際、クライアントはUpgradeヘッダーを送信し、サーバーが「101 Switching Protocols」を返した時点で切り替えが完了する。
Upgradeヘッダーの誤用によるバイパス
修正前のPingoraは、バックエンドからの「101」レスポンスを確認する前に、後続のデータを「アップグレード後のストリーム」としてそのまま流し込む（パススルーする）挙動を示していた。
GET / HTTP/1.1
Host: example.com
Upgrade: foo
GET /admin HTTP/1.1
Host: example.comこのコードのように、Upgradeリクエストの直後に別のリクエストを連結して送信すると、Pingoraは最初の部分だけを解析し、残りを「アップグレードされた通信」と見なしてバックエンドに丸投げする。たとえバックエンドがアップグレードを拒否して「200 OK」を返したとしても、Pingoraはすでに通信を素通しするモードに入ってしまっている。
バックエンドとの同期ずれ（Desync）の仕組み
この挙動により、プロキシとバックエンドの間で「Desync（デシンク / 同期ずれ）」が発生する。プロキシは1つの通信だと思っているが、バックエンドは「拒否したはずのアップグレードの後に、なぜか別のGETリクエストが届いた」と認識する。
結果として、プロキシ側のWebアプリケーションファイアウォール（WAF）や認証チェックを一切受けずに、`/admin` などの機密性の高いパスへのアクセスがバックエンドに到達してしまう。これは、検問を「工事車両です」と偽って通過し、ゲートが開いた瞬間に後ろに隠していた別の車を侵入させるような手口だ。
脆弱性2：HTTP/1.0とTransfer-Encodingの不適切な解釈
2つ目の脆弱性（CVE-2026-2835）は、古い規格であるHTTP/1.0のリクエストに「Transfer-Encoding: chunked」が含まれていた場合の処理に起因する。HTTP/1.0は本来、チャンク形式の転送をサポートしていない。
リクエストボディの終端判定ミス
Pingoraの従来のロジックでは、HTTP/1.0リクエストにTransfer-Encodingが含まれている場合、ボディの終端を「コネクションの切断（close-delimited）」で判断していた。しかし、最新のRFC（仕様書）では、リクエストボディにおいてコネクション切断を終端判定に使うことは明確に禁止されている。
攻撃者が以下のようなリクエストを送信した場合、問題が顕在化する。
GET / HTTP/1.0
Host: example.com
Connection: keep-alive
Transfer-Encoding: chunked
Content-Length: 29
0
GET /admin HTTP/1.1
X:Pingoraはこれを「1つの長いボディを持つリクエスト」と誤認するが、バックエンド（Node.jsやuvicornなど）は「チャンク形式の終わり（0）」でリクエストが終了したと判断する。その結果、後ろに続く `/admin` へのリクエストが、次にそのコネクションを利用する別ユーザーのリクエストとして処理されてしまう。
RFC準拠の厳格化による修正
Cloudflareはこの問題に対し、PingoraのHTTP解析ロジックを大幅に強化した。具体的には、HTTP/1.0とTransfer-Encodingの組み合わせを拒否し、無効なContent-Lengthを持つリクエストも遮断するように変更されている。
RFC（Request for Comments）とはインターネット技術の標準仕様書であり、これに厳格に従うことがセキュリティの基本となる。Pingoraはこれまで、レガシーなシステムとの互換性のために一部の仕様を緩く解釈していたが、今回の修正で「安全な厳格さ」へと舵を切った形だ。
脆弱性3：デフォルトCacheKeyによるキャッシュ汚染のリスク
3つ目の脆弱性（CVE-2026-2836）は、Pingoraのアルファ版機能である「プロキシキャッシュ」のデフォルト設定に関するものだ。キャッシュの識別子となる「CacheKey（キャッシュキー）」の生成ロジックが不十分であった。
URIパスのみに依存するキャッシュキーの危険性
修正前のデフォルト実装では、キャッシュキーの生成に「URIパス」のみを使用していた。ここにはホスト名（Hostヘッダー）や通信プロトコル（HTTPかHTTPSか）が含まれていなかった。
これにより、例えば `site-a.com/index.html` と `site-b.com/index.html` が、同じキャッシュとして扱われてしまう。攻撃者が自分の管理するドメインで不正なコンテンツをキャッシュさせれば、同じサーバーを共有する全く別ドメインの利用者にその不正コンテンツを表示させることが可能になる。
現在、Pingoraはこの「不完全なデフォルト設定」自体を削除している。利用者は自身のアプリケーションの特性に合わせ、ホスト名やスキームを含めた適切なキャッシュキーを明示的に設計する必要がある。
独自の分析：Rust製プロキシにおけるRFC準拠と「寛容さ」のトレードオフ
今回の脆弱性公表は、Rustというメモリ安全な言語で開発されていても、プロトコルの解釈という論理的なレイヤーでの脆弱性は避けられないことを改めて示した。PingoraはCloudflareが数千台のサーバーで運用する実績あるコードだが、それでもなお、リクエストスマグリングのような古典的な攻撃手法が有効な隙間が存在していた。
モダンなスタックでも避けられないHTTPの複雑性
HTTP/1.1は1990年代から続く仕様であり、長年の拡張によって解釈の余地が非常に多い。プロキシ開発者は「どんなに壊れたリクエストでも、可能な限りバックエンドに届ける」という「寛容さ」と、「不正なリクエストを厳格に弾く」という「安全性」の板挟みにあう。
今回の事例では、Pingoraがレガシーなクライアントをサポートするために持たせていた「解釈の柔軟性」が、攻撃者に悪用される結果となった。Cloudflareのような巨大なインフラを支える技術であっても、OSSとして一般公開され、多様な環境（イングレスプロキシとしての利用など）に置かれることで、新たなリスクが浮き彫りになる点は興味深い。
今後のプロキシ開発においては、Rustによるメモリ安全性だけでなく、仕様（RFC）への「形式的な厳格さ」をいかに自動テストや静的解析で担保するかが、次なるセキュリティの焦点となるだろう。
この記事のポイント
- Pingora 0.8.0がリリースされ、3つのリクエストスマグリング脆弱性が修正された。
- 脆弱性は、不適切なUpgrade処理、HTTP/1.0の誤認、不十分なキャッシュキー生成に起因する。
- CloudflareのCDNサービス自体には影響がなく、独自にPingoraを構築しているユーザーが対象となる。
- 攻撃を受けると、セキュリティ制御のバイパスや他ユーザーのセッション奪取の恐れがある。
- Pingoraを運用しているエンジニアは、速やかに最新版へのアップグレードを推奨する。
出典
- Cloudflare Blog「Fixing request smuggling vulnerabilities in Pingora OSS deployments」（2026年3月9日）
- GitHub「cloudflare/pingora Release v0.8.0」（2026年3月2日）
- CVE MITRE「CVE-2026-2833 / CVE-2026-2835 / CVE-2026-2836」（2026年3月4日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WAFの「ログかブロックか」を卒業。Cloudflareが提唱するAttack Signature Detectionの革新性
WAF（Web Application Firewall / ウェブ・アプリケーション・ファイアウォール）の運用において、セキュリティ担当者を長年悩ませてきた「ログモードかブロックモードか」という二者択一に、終止符が打たれようとしている。
Cloudflareが発表した「Attack Signature Detection（アタック・シグネチャ・デテクション）」は、検知と遮断のアクションを分離することで、防御性能を維持しながらトラフィックの完全な可視化を実現する技術だ。
この新機能は、従来のWAFが抱えていた「遮断を優先すると、他の攻撃シグネチャがどう反応したかのデータが失われる」という構造的な欠陥を解消する。
WAFの課題「検知か遮断か」のジレンマを解消する新アプローチ
従来のWAF運用では、新しいアプリケーションを公開する際、まず「ログ専用モード」で数週間稼働させることが一般的だった。
これは、WAFが正規の通信を誤って攻撃と判断してしまう「誤検知（False Positive）」を防ぐための調整期間だ。
ログモードとブロックモードの壁
ログモードでは攻撃を防げず、ブロックモードでは誤検知によってビジネス機会を損失するリスクがある。
さらに深刻なのは、ブロックモードで特定のルールがリクエストを遮断した場合、その時点で処理が終了してしまう点だ。
これにより、他のシグネチャ（攻撃のパターンを定義した識別子）がそのリクエストをどう評価したかという貴重なインサイトが得られなくなる。
多角的な防御策を講じる上で、この「可視性の欠如」は防御の最適化を妨げる大きな要因となっていた。
検知とアクションを分離する「常時稼働」モデル
Attack Signature Detectionは、このトレードオフを「検知の常時稼働」という概念で解決する。
リクエストが届いた際、まず全ての検知シグネチャを走らせてリッチなメタデータを付与し、その後に実際の遮断アクションを行うかどうかを判定する仕組みだ。
これにより、たとえリクエストをブロックしたとしても、背後でどのシグネチャが反応していたかを全て記録に残すことが可能になる。
Attack Signature Detection：常時稼働する高精度な検知エンジン
Attack Signature Detectionは、Cloudflareのマネージドルールセットと同じ高度なヒューリスティック（経験則に基づいた分析手法）を利用している。
SQLインジェクション（SQLi）やクロスサイトスクリプティング（XSS）といった代表的な攻撃から、最新のCVE（Common Vulnerabilities and Exposures / 共通脆弱性識別子）まで、700以上のルールがリアルタイムで適用される。
信頼度（Confidence）による分類
各シグネチャには「カテゴリー」と「信頼度」というタグが付与されている。
信頼度は、そのシグネチャが正規の通信を誤検知する可能性の低さを示す指標だ。
- High（高信頼度）: 誤検知が極めて少なく、即座にブロックモードでの運用が推奨される。
- Medium（中信頼度）: トラフィックの特性によっては誤検知の可能性があるため、事前の分析が推奨される。
運用者はこれらの指標を基に、「信頼度が高いシグネチャに一致した時だけブロックする」といった柔軟なポリシーをノーコードで作成できる。
パフォーマンスへの影響を最小限に抑える設計
「全てのシグネチャを常時稼働させると、通信速度が低下するのではないか」という懸念が生じるのは自然なことだ。
しかし、このフレームワークは効率性を極限まで高めている。
特定の検知に基づいた遮断ルールが設定されていない場合、検知処理はリクエストがオリジンサーバー（Webサイトの本体が稼働しているサーバー）へ送信された「後」に実行される。
この非同期処理により、検知そのものがユーザーの体感速度に影響を与えることはない。
Full-Transaction Detection：レスポンスまで見通す次世代の防御
Attack Signature Detectionのさらに先を行く進化として開発されているのが、「Full-Transaction Detection（フル・トランザクション・デテクション）」だ。
従来のWAFは、ユーザーからの「リクエスト（問いかけ）」の内容だけを見て攻撃を判断していた。
しかし、Full-Transaction Detectionは、サーバーからの「レスポンス（回答）」も含めた一連のやり取り（トランザクション）を分析対象とする。
「攻撃の成否」を判断する重要性
例えば、URLの末尾にSQLインジェクションのコードが含まれていたとする。
リクエストだけを見れば攻撃だが、サーバーが「500 Internal Server Error」や「404 Not Found」を返していれば、その攻撃は失敗したと判断できる。
一方で、サーバーが「200 OK」を返し、かつレスポンスボディにユーザーのパスワード一覧のような機密データが含まれていた場合、それは「攻撃が成功した」ことを意味する。
このように、レスポンスを相関分析することで、誤検知を劇的に減らし、真に危険なイベントだけを抽出することが可能になる。
データ漏洩と設定ミスの検知
この技術は、外部からの攻撃だけでなく、内部の設定ミスや意図しないデータ露出の検知にも威力を発揮する。
例えば、管理者が誤って公開設定にしてしまったElasticsearch（検索エンジン）のインターフェースや、Apacheの機密エンドポイントへのアクセスを検知できる。
また、正規のAPIリクエストであっても、レスポンスに数千件のクレジットカード番号が含まれているような異常な事態（データエクスフィルトレーション / データ持ち出し）を即座に特定できる点は、従来のWAFにはない強みだ。
セキュリティ運用を劇的に変える分析とルールのカスタマイズ
Attack Signature Detectionがもたらす最大の価値は、セキュリティ運用の「データ駆動型」への転換だ。
Security Analytics（セキュリティ・アナリティクス）のダッシュボードを活用することで、専門家でなくても自社サイトがどのような攻撃にさらされているかを詳細に把握できる。
Security Analyticsによる可視化
ダッシュボードでは、どのCVEを狙った攻撃が多いか、どのエンドポイント（URL）が標的になっているかがグラフ化される。
例えば、特定のAPIパス（`/api/v1/`など）に対して執拗に攻撃を繰り返しているIPアドレスを特定し、その場で遮断ルールを作成するといったアクションがスムーズに行える。
また、過去のトラフィックデータに対して「もしこのルールを適用していたらどうなっていたか」というシミュレーションを行うことも可能だ。
柔軟なルールエンジンの活用
検知されたメタデータは、Cloudflareの「Edge Rules Engine」で自由に利用できる。
「信頼度がMediumのシグネチャに一致した場合は、即座にブロックせず、Managed Challenge（人間であることを確認する認証画面）を表示する」といった、ユーザー体験を損なわない防御策も容易に実装できる。
こうした「多層防御」の構築が、複雑なスクリプトを書くことなくGUI上で行える点は、リソースの限られた中小企業のWeb担当者にとっても大きなメリットとなるだろう。
独自の分析：Web制作現場におけるWAF運用のパラダイムシフト
これまでのWeb制作や保守運用の現場では、WAFは「導入して終わり」か、あるいは「誤検知が怖いからオフにする」という極端な運用に陥りがちだった。
しかし、Attack Signature Detectionの登場により、WAFは「静的な壁」から「動的なセンサー」へと進化したと捉えるべきだ。
筆者の分析では、この技術が普及することで、以下の3つの変化が起こると予測している。
第一に、WAF導入の心理的ハードルが下がる。
「とりあえず検知だけさせてデータを貯める」というスモールスタートが、パフォーマンスへの影響なしに可能になるからだ。
第二に、インシデント対応の迅速化だ。
リクエストとレスポンスの両面から攻撃の成否が可視化されるため、ログを数時間かけて解析しなくても、どの脆弱性が突かれたのかが瞬時に判明する。
第三に、開発とセキュリティの融合（DevSecOps）が加速する。
開発者はWAFの検知データをフィードバックとして受け取り、コードレベルでの修正が必要なのか、WAFでの対応で十分なのかをデータに基づいて判断できるようになる。
もはやセキュリティは、開発の足を引っ張る存在ではなく、安全なリリースを支える強力なインフラへと変貌を遂げている。
この記事のポイント
- WAFの課題だった「検知（ログ）か遮断（ブロック）か」の選択を、機能を分離することで解消した。
- Attack Signature Detectionは常時稼働し、リクエストに詳細なメタデータを付与して可視性を高める。
- Full-Transaction Detectionにより、レスポンスまで分析して攻撃の成功・失敗を正確に判別できる。
- 非同期処理の導入により、高度な検知を行いながらもユーザーの通信速度に影響を与えない設計を実現した。
- 専門知識がなくても、信頼度に基づいた柔軟なセキュリティポリシーの運用が可能になった。
出典
- Cloudflare Blog「Always-on detections: eliminating the WAF “log versus block” trade-off」（2026年3月4日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
エンドポイントからAIプロンプトまで——Cloudflare Oneが描く統合データセキュリティの現在地
企業のセキュリティ対策は、ネットワークの境界防御からデータそのものの保護へと重心が移っている。機密データが存在する場所、アクセスする人物、不正な移動経路を可視化し制御することが、現代のセキュリティプログラムの核心的な課題だ。
Cloudflareは2026年3月6日、同社のSASE（Secure Access Service Edge）プラットフォーム「Cloudflare One」におけるデータセキュリティの統合ビジョンを発表した。このビジョンは、データが移動するあらゆる経路——転送中、保存時、利用時、さらにはAIプロンプトへの入力時までを単一のモデルで追跡することを目指す。従来のサイロ化した制御ではなく、データの流れに沿ってポリシーを適用するアプローチである。
今回の発表では、ブラウザベースのリモートデスクトッププロトコル（RDP）におけるクリップボード制御、SaaSアプリ内操作の詳細なログ記録、エンドポイントでのデータ損失防止（DLP）、Microsoft 365 Copilot向けのAIセキュリティスキャンなど、複数の新機能が公開された。これらの更新は、データがツールや製品の境界を越えて高速に移動する現代の環境において、セキュリティポリシーがデータそのものに追随する必要性を具現化するものだ。
データ移動の最終関門——ブラウザRDPのクリップボード制御
クラウド環境や外部協力者との作業が一般化する中、ブラウザを通じたリモートアクセスは一般的なワークフローとなった。Cloudflare OneのブラウザベースRDP機能は、管理されていない端末やクライアントソフトがインストールされていない環境からのアクセスを可能にする。しかし、ブラウザ内で完全なRDP体験を提供する際、データがどこへ移動できるか、特にクリップボードを介した移動をどの程度細かく制御できるかが課題となる。
生産性とセキュリティのトレードオフを解消する
クリップボード制限は、生産性とセキュリティのバランスを象徴する問題だ。ユーザーがコピー＆ペーストできないと、スクリーンショットの撮影、データの手打ち、管理外ツールへの作業移行など、制御を迂回する方法を探し始める。完全なブロックは実用的ではない。
Cloudflare Oneが追加した新機能は、このジレンマを解消する。セキュリティ管理者は、ローカルデバイスとブラウザ内RDPセッション間のコピー・ペーストを、方向性と文脈に応じて細かく制御できるようになった。例えば、顧客情報を含むサポートポータルにアクセスするセッションでは、作業効率化のためにセッション内へのペーストは許可しつつ、機密データが管理外の端末に流出するのを防ぐためにセッション外へのコピーはブロックする、といった設定が可能だ。
具体的な適用シナリオと設定
この機能は、Cloudflare Oneのダッシュボード内、ブラウザベースRDPアプリケーション用のアクセスアプリケーションポリシーに新設された設定項目から構成できる。ポリシーは「双方向許可」「ローカルからリモートのみ許可」「リモートからローカルのみ許可」「すべて禁止」の4つのプリセットから選択する。これにより、契約者やパートナー企業からのアクセスなど、端末管理が行き届かないシナリオでも、データの意図しない持ち出しリスクを低減できる。
従来のVPNや専用RDPクライアントに比べ、ブラウザベースのアクセスは導入ハードルが低い。Cloudflare Oneはこの利便性を維持しつつ、セッション境界でのデータ制御という追加の防御層を提供する。このアプローチは、ゼロトラストセキュリティの原則——「決して信用せず、常に検証せよ」——をリモートアクセス領域に具体化した一例と言える。
可視性の深化——操作マッピングによるログの強化
適切な制御を設計するには、ユーザーがSaaSアプリ内で実際にどのような操作を行っているかを理解する必要がある。しかし、生のHTTPログや監査ログだけでは、個々のリクエストがビジネス上のどのアクションに対応するのか、解釈が困難な場合が多い。
「操作」としてのログ解釈
Cloudflareは「操作マッピング」と呼ばれるプロセスを用いてこの課題に対処する。このプロセスは、HTTPリクエストの様々な要素（パス、メソッド、パラメータなど）を解釈し、それを単一のビジネス操作（例：ChatGPTにおける「SendPrompt」）に変換する。さらに、類似のアクションを行う複数の操作を「アプリケーションコントロール」（例：「共有」や「アップロード」）というグループにまとめる。これまで、このマッピングはポリシー作成の簡素化に主に活用されてきた。
ログ分析とフォレンジックの高速化
今回の更新で、この操作マッピングがログイベントにも適用されるようになった。追加設定なしに、Cloudflare Oneの操作マップと互換性のあるSaaSアプリケーションのトラフィックについて、ログ詳細に「アプリケーションコントロール」と「特定の操作」の両方が表示される。
調査担当者は、生のURLやメソッドを解読する代わりに、「ユーザーがSalesforceでレコードをエクスポートした」や「Google Driveでファイルを共有した」といった直感的な情報を即座に把握できる。これにより、インシデント調査やポリシーチューニングにかかる時間が短縮され、ユーザー体験を不必要に損なうことなく、リスクの高い行動を特定しやすくなる。
この機能は、単なるログの装飾ではない。セキュリティ運用における根本的な課題——「何が起こっているのかを文脈を持って理解する」——を解決する。可視性が向上すれば、防御策は事後対応から事前予防へとシフトできる余地が生まれる。
エンドポイントでの最終防御——Cloudflare One ClientによるDLP
管理されたSaaSアプリケーションから、クリップボードを経由して管理外のコンテキストに機密情報が移動するリスクは日常的に存在する。リスクはファイルの組織外流出だけではない。独自コードの断片や顧客レコードが、許可されていない大規模言語モデル（LLM）や個人用ツールに貼り付けられる可能性もある。
転送中・保存時から利用時への保護拡張
Cloudflare Oneは既に、ゲートウェイとDLPによる転送中のデータ保護、CASB（Cloud Access Security Broker）とAPI連携による保存時の可視性と制御を提供している。今回、エンドポイントDLPの適用範囲を「利用時」のデータに拡大する。その第一歩として、Cloudflare One Client（旧WARPクライアント）にクリップボードの移動といったハイシグナルのワークフローに対するDLP適用機能が追加された。
これにより、保護されたSaaSアプリからコピーされた機密データが、OSのクリップボードに到達した瞬間に「ポリシーの適用外」のコンテンツになることを防ぐ。組織は、別のエージェントを導入したり複雑な連携を構築したりすることなく、ユーザーの手元までデータ保護を拡張できる。
エージェント統合の利点と「エンドポイントからプロンプトまで」の問題
既にCloudflare One Clientをゼロトラストネットワークアクセスに利用している組織にとって、エンドポイントDLPは自然な機能拡張である。単一の軽量エージェントが、ネットワークセキュリティとデータセキュリティの両方の役割を担う。これが「エンドポイントからプロンプトまで」の問題を解決する鍵となる。機密データがローカルでコピーできるなら、それはAIアシスタントに同じくらい簡単に貼り付けられる。利用時のデータを保護することで、この連鎖の最初の一歩を封じる。
このアプローチは、データセキュリティを単なる「チェックボックスを満たす活動」から、「実際のデータフローに沿った継続的な適用」へと進化させる。エンドポイントは、データがデジタル世界から物理世界（例えば、スクリーンショットや印刷）へと移行する可能性のある最後の関門の一つだ。ここでの制御は、防御層を実質的に強化する。
AI時代の可視性——M365 Copilot向けAPI CASBスキャン
AIアシスタントの業務利用が拡大するにつれ、新しいブラインドスポットが生じている。従業員がMicrosoft 365 Copilotなどのツールに機密データを入力しても、従来のDLPやCASBではそのやり取りを検知できない場合があった。AIとの対話は、新しいデータ移動経路を生み出した。
AIプロンプトとアップロードのスキャン
Cloudflare OneのAPI CASBは、SaaSアプリをAPI経由でスキャンし、一般的かつリスクの高いセキュリティ問題を検出する。今回、この機能がMicrosoft 365 Copilotのアクティビティ分析に対応した。具体的には、DLP検出プロファイルに一致するチャット内容やアップロードファイルをスキャン対象とする。
検出された結果は、ファイル参照、プロファイル一致内容、対話メタデータなどの豊富な文脈情報と共に表示される。これにより、セキュリティチームは生の監査ログから手作業で情報を抽出する代わりに、迅速にトリアージを行える。
設定と今後の展開
M365 Copilotの検出機能は、既存のMicrosoft 365連携の一部としてデフォルトで利用可能となる。既に連携を設定しているユーザーは、Cloudflare Oneダッシュボードの「統合」セクションでMicrosoft 365接続を更新するだけでCopilotの検出を開始できる。新規ユーザーは、テナントを接続することでCopilotの使用状況と関連するデータセキュリティ上の発見を可視化できる。
Cloudflareは、AI製品の拡散が続く中、2026年を通じて他のAIアシスタントや主要SaaSプラットフォームへの対応を大幅に拡大する計画を示している。これは、データセキュリティの適用範囲を、単なる従来型のアプリケーションから、AIという新しいインターフェースへと積極的に拡張する姿勢を示すものだ。
統合データセキュリティの未来像
過去数年間、企業セキュリティはSaaS、管理外エンドポイント、リモートアクセスパターン、そして現在はAIアシスタントへと適用範囲を広げてきた。しかし、その目的——機密データの保護——は変わらない。今回発表された一連の更新は、転送中、保存時、利用時、プロンプト時における一貫した可視性と適用を実現するという単一の方向性を反映している。ポリシーが製品の境界ではなく、データそのものに追随する世界だ。
Cloudflareのビジョンは、「データセキュリティ製品内のデータセキュリティ機能」という枠を超えている。同社は、時間の経過とともに、あらゆるCloudflare One製品がデータセキュリティをより意識したものになり、データ指向の設定可能性、可視性、制御、ガードレールが、アクセス、ゲートウェイ、エンドポイント適用、SaaS連携といった既存のワークフローに直接組み込まれると述べている。
目標は明確だ。ユーザーがどこで作業し、データがどこに移動しようとも、Cloudflare Oneは何が起こっているかを説明し、それを制御する手助けができるべきである。モダンペリメーターがアプリケーション、ブラウザ、エンドポイント、AIプロンプトにまたがって広がる中、点のソリューションを継ぎ接ぎすることは、運用を困難にし、回避を容易にする。Cloudflare Oneにデータセキュリティを直接構築し、これらのレイヤーを統合し続けることで、同社は企業がエンドポイントからプロンプトまでのデータリスクとデータセキュリティ体制を、より明確かつ完全に把握することを支援しようとしている。
この記事のポイント
- Cloudflare Oneは、データの移動経路（転送中、保存時、利用時、AIプロンプト時）を単一モデルで追跡・保護する統合ビジョンを発表した。
- ブラウザベースRDPにクリップボードの方向制御機能を追加。生産性を維持しつつ、セッション境界でのデータ流出を防止する。
- 操作マッピングをログに適用し、SaaSアプリ内のユーザー行動を「ビジネス操作」として可視化。調査とポリシーチューニングを高速化する。
- Cloudflare One ClientにエンドポイントDLPを導入。クリップボードを介したデータの管理外ツールへの移動を阻止する。
- API CASBがMicrosoft 365 Copilotのスキャンに対応。AIプロンプトやアップロードファイルに含まれる機密データを検出する。
出典
- Cloudflare Blog “From the endpoint to the prompt: a unified data security vision in Cloudflare One” (2026年3月6日)
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験