フロンティア・サイバーモデルに対抗する：カスタマーゼロとしてのCloudflareのアーキテクチャ

2026-06-09 — Rohit Chenna Reddy, Chase Catelli, Dan Jones — 読了約8分

数週間前、Project Glasswing と私たちが自社コードにフロンティア級のサイバーモデルを向けたときに観測したことについて投稿しました。その投稿で最も反響が大きかったのは、脆弱性そのものの速やかなパッチよりも、脆弱性を取り巻くアーキテクチャのほうが重要だという主張でした。CISO やセキュリティチームとの会話で共通して出る質問は次のようなものです：私たちのアーキテクチャは実際にどうなっているのか、何を監視すべきか、どこから始めればいいのか、Cloudflare はどう支援できるのか。

まず重要な点：以下に示すアーキテクチャはほぼ完全に Cloudflare 自身のプロダクトで構成されています。Cloudflare のセキュリティ製品は私たちにとってカスタマーゼロです。Cloudflare スタックは既に我々のコード、従業員、顧客向けアプリケーションの前に存在しています。あなたが Cloudflare の顧客であれば、以下の各層は今日すぐに利用可能です。そうでなくても、本稿で述べる原則はあなたが構築したスタックにも当てはまります。

フロンティア・サイバーモデルが実際に変えること

前回の投稿では、Mythos のようなフロンティア級サイバーモデルが攻撃者のタイムラインをどう変えるかを示しました。これらのモデルは脆弱性を見つけ、エクスプロイト連鎖を推論し、動作するプルーフ・オブ・コンセプトを従来より速く生成できます。フロンティアモデルは侵入の形自体（偵察、初期アクセス、ラテラルムーブメント、永続化、流出）を変えるわけではありませんが、速度とスケールを大きく変化させます。

• 公開ウェブに向けると、モデルは低い実り（low-hanging fruit）を迅速に見つけて攻撃できます。
• 強化されたターゲットに対しては、なお探索（プローブ）と適応が必要であり、人間の慎重なオペレータよりノイズが多くなることもあります。

発見、エクスプロイト連鎖の構築、PoC 生成がかつては実働攻撃を作る上でのボトルネックでしたが、フロンティアモデルはこれらを短時間で処理します。以前は遅くて体系的だった作業が、今や高速かつ無差別になり得ます。

開発チームがコードのデリバリを高速化する一方で、セキュリティチームの作業は同じように圧縮されません。攻撃者はひとつの突破口を見つければよいのに対し、守る側はすべてを見つけて閉じる必要があります。修正を書いてリグレッションテストを行い、周辺を壊さずに出荷するための制約は AI によって取り払われるわけではありません。我々は以前、AI コーディングアシスタントに自社のバグに対するパッチを書かせたときにこれを痛感しました（前回投稿参照）。その一部は元のバグを直しつつ、コードが依存していた何かを静かに壊していました。

脅威の観点から主に注目しているのは次の3点で、以降のアーキテクチャ設計はこれらを反映しています。

1. 発見の速度
2. エクスプロイトの量と適応
3. 脆弱性が悪用された場合の影響範囲

1) 発見の速度

フロンティアモデルは公開コード、特に多くの企業が依存しているオープンソースライブラリの大規模な探索を容易にします。とはいえ、ライブラリ中のすべてのバグが必ずしもエクスプロイタブルであるわけではなく、脆弱性の多くはコードの利用方法、攻撃者制御の入力が脆弱経路に到達できるか、そしてそれを囲む保護に依存します。しかし、広く使われている OSS ライブラリやフレームワークは攻撃者にとってスケールして研究できる共通の面を与えます。実際に到達可能な脆弱性が存在する場合、モデルはそれを見つけ、可能なエクスプロイト経路を推論し、保守者や守る側が下流のすべての利用を精査するより速く PoC バリエーションを生成します。

我々が最も懸念するのは、攻撃者が脆弱性を発見した時点と守る側がそれを知るまでのギャップです。自社コードに対してこれらのモデルを実行していないなら、誰か別の誰かが実行していると仮定するのが安全です。

2) エクスプロイトの量と適応

モデルは単一のエクスプロイトの何千もの変形を生成し、同規模で偵察を行えます。そのボリュームは攻撃者に優位を与えますが、シグネチャベースの検知を必ずしも突破するとは限りません。多くの反復が同じ基底シグネチャを持つため、最初のものを捕まえるルールが他の変種も捕まえます。

ここで重要なのは「適応」です。モデルに SQL インジェクションの例を見せれば教科書どおりの例が返ってきますが、WAF があると伝えると、何がブロックされるかを探り、学び、ペイロードを書き換えてルールをすり抜けようとします。

3) 悪用された際の影響

どのアーキテクチャもすべてを捕まえられるわけではありません。脆弱性が悪用された後に問うべきは「攻撃者が一つのID、一つの経路、あるいは一つのクレデンシャルでどこまで到達できるか、何か別のものが止める前にどれだけの権限が得られるか」です。もし答えが「好きなところに行ける」であれば、問題は脆弱性そのものではなく、その脆弱性を囲むアーキテクチャです。

Cloudflare の超能力：可視性

我々はウェブのおよそ5分の1を可視化しており、それによってどのペイロードが変化しているか、どのパターンが広がっているか、攻撃者ツールが次にどこへ動いているかをリアルタイムで把握できます。この可視性を防御に変えるのは主に2つのチームです。

• Cloudforce One — これは Cloudflare セキュリティ組織内の脅威インテリジェンス、リサーチ、オペレーションのチームです。彼らはネットワーク全体で見えているものをスタックが行動できるインサイトに変換します：追跡中の敵対者、出現中のキャンペーン、IOCs（侵害の指標）など。新たな脅威の知見は通常、脅威レポート→フィード→各社の防御へと伝播し、それがブロックに利用されるまで遅延が生じます。攻撃者はその速度差を利用するようになりました。私たちのネットワークはそのギャップを埋めます：Cloudflare の顧客は Cloudforce One の脅威インテリジェンスを WAF 内で直接利用して高リスクトラフィックをブロックできます。

• WAF エンジンを所有するチーム — 実際に検知を行う管理ルールセット、WAF Attack Score の背後にある機械学習、そして CVE が公開される前にルールを出せることもある関係性を持つチームです。このチームはグローバルに分散しており、攻撃の PoC が明らかになってから数時間以内にルールを出すなど迅速に動きます。検知がデプロイされると、それは我々のネットワーク全体とすべての Cloudflare 顧客へ30秒以内に届きます。

React2Shell は最近の例です：管理された WAF ルールが我々自身のプロパティと Cloudflare 上の他のすべてを守っており、公式アドバイザリが公開される数時間前に適用されていました。

これら二つのチームが見ているものの上に、スコアリング層、アプリケーション前の防御、脆弱性周囲の包含（containment）が構築されます。

シグネチャよりスコア

シグネチャベースの防御は、新規エクスプロイトが稀で変種の発生に数週間かかる世界を前提に作られました。Cloudflare の従来の SLA（新規 PoC からライブルール適用まで）は12時間でしたが、フロンティアモデルの出現によりこれでは不十分になっています。検知は CVE が発見される前に存在している必要があります。だからこそ、私たちは従来のシグネチャベース WAF の前に ML ベースの検知を重ねています。

モデルは過去の攻撃トラフィックの大規模な集合で訓練されており、まだ公表されていない脆弱性の新変種を捕まえます。新規の SQL インジェクションやリモートコード実行チェーンであっても、多くの場合それはモデルがこれまでに見た攻撃形状の再構成です。私たちはすべてのリクエストでモデルを実行し、リクエストが既知の悪性シグネチャのリストに合致するかではなく、その形状にどれだけ似ているかに基づいて1〜99の WAF Attack Score を割り当てます。スコアが低いほどそのリクエストをより積極的に扱い、そのスコアで通すかどうかを決定します。

同様のスコアリング手法を AI Security for Apps で AI プロンプトにも適用しています：既知の悪性プロンプトの一覧と照合するのではなく、実際の攻撃にどれだけ似ているかをスコアリングします。

脆弱性を取り巻くアーキテクチャ

これらの能力はアプリケーションの前に積み上げられて初めて意味を持ちます。防御の深さ（defense-in-depth）における最初の層は WAF です。既知の悪いパターンに合致するものはアプリケーションに到達する前にドロップされ、明らかなトラフィックの大部分を除去し、下位のより専門的な層が残りに集中できるようにします。

• API サーフェスでは、API Shield によるポジティブセキュリティモデルを実行します。すべての不正なリクエストを予測しようとする代わりに、各 API に対して有効なリクエストがどのようなものかを API 定義から、あるいは実トラフィックから学習して記述し、それに合わないものは通しません。これによりフロンティア AI モデルの利点は中和されます：許可されるのは検証済みトラフィックのみであり、何千通りもの攻撃変種を生成してもシステムを迂回できません。

Cloudflare の多層アーキテクチャ（主なコンポーネント）

• Bot Management

  • フロンティアモデルがマップを作る前にネットワーク上のプロービングを捕捉します。すべてのリクエストに対して自動化されている可能性をスコアし、クライアントの振る舞い、実ブラウザに見えるか、既知の悪い接続パターンに合致するかといったシグナルを用います。

• Zero Trust Network Access

  • すべての内部アプリケーションに対して使用します。ネットワーク内部にいることによる暗黙の信頼を、従業員があらゆるツールにアクセスする際のリクエスト単位の明示的なアイデンティティとポリシーに置き換えます。あるエンジニアが設定ミスしたツールを出荷したとき、このアプローチの価値が明確になりました。フラットなネットワークであれば同一セグメント上のすべてが露出していたはずですが、我々の展開では露出はそのツール単体で止まりました。

• Require Access Protection

  • 新しくデプロイされた、あるいは設定ミスしたアプリケーションがアクセスポリシーが設定される前に到達可能にならないようにするために構築しました。

• IdP Federation

  • セキュア・バイ・デフォルトな姿勢を組織内のすべての Cloudflare アカウントで一貫して保つことを容易にします。各チームが個別に SSO を配線する代わりに、IdP を一度設定して組織で共有します。新規アカウントは自動で SSO を受け、受信側の IdP 接続は読み取り専用にし、各アカウントの Access ポリシーは通常のリクエストフローの一部としてその結果のアイデンティティを評価します。

• MCP Server Portal

  • エージェントをエンタープライズシステムに接続するための制御された方法をチームに提供します。エージェントは中央で管理される MCP サーバーにアクセスし、すべてのアクションがログに残ります。エージェントが誰かの代理で動作したときに、何をしたか、何に触れたか、許可されるべきだったかを後から知ることができます。全体像は enterprise MCP に関する投稿に詳述しています。

• AI Gateway

  • 社内の AI ツールの前で、AI Security for Apps が顧客向けの AI 機能の前に置かれているのと同様に動作します。同じスコアリングと可視性を提供します。社内ではブロッキングよりも可視性の側面が有益で、エンジニアが実際に何を作っているかを見てから意味のあるポリシーを書けるようにしました。

チームがどこから始めるか

フロンティアモデルは脆弱性を見つけ、ペイロードを適応させ、より速く動く手助けをしますが、アプリケーションの前に配備した多層防御を通過しなければなりません。ここがチームの出発点です。

• 公開アプリケーションの前にインスペクションを置く
• 有効な API トラフィックがどういうものかを定義する（API Shield など）
• 自動化されたプロービングを制限するために Bot Detection を使う
• 内部ツールに到達する前にアイデンティティとアクセスのポリシーを要求する
• AI とエージェント系システムについては：モデルのトラフィックをゲートウェイ経由にする
• エージェントの接続状況を可視化し…（原文が途中で切れています）