数週間前、CloudflareはProject Glasswingに関する投稿で、フロンティアサイバーモデルを自社コードに適用した際の観察結果を共有し、「脆弱性をめぐるアーキテクチャがパッチの速度よりも重要である」という主張が最も共感を呼んだことを述べました。その後、CISOやセキュリティチームとの会話で寄せられた質問は一貫しています：実際のアーキテクチャはどのようなものか、何を監視すべきか、どこから始めるべきか、Cloudflareはどのように支援できるか。
詳細に入る前に：以下で説明するアーキテクチャは、ほぼ完全にCloudflare自身の製品で構築されています。なぜなら、Cloudflareセキュリティは、私たちが構築するセキュリティ製品のカスタマーゼロだからです。このスタックはすでに、コード、従業員、顧客向けアプリケーションの前に展開されています。Cloudflareのお客様であれば、以下のすべてのレイヤーを今日から利用できます。そうでない場合でも、原則はお客様のスタックに適用できます。
フロンティアサイバーモデルが実際に変えること
前回の投稿では、Mythosのようなフロンティアモデルが攻撃者のタイムラインをどう変えるかを示しました。脆弱性の発見、エクスプロイトチェーンの推論、実用的なPoCの生成を従来のモデルより高速に行えます。侵入の形状（偵察、初期アクセス、横移動、永続化、データ流出）は変わりませんが、速度と規模が異なります。オープンなウェブを対象にすると、低い実の簡単に発見して攻撃できます。堅牢な標的に対しては、依然として探索と適応が必要であり、人間のオペレーターよりも多くのノイズを生むことがよくあります。
発見、エクスプロイトチェーンの構築、PoCの生成は、かつては実用的な攻撃を生み出すための制約要因でした。フロンティアモデルはこれらすべてを短時間で処理します。かつては遅くて方法論的だった作業が、今では高速で無差別になりました。
AIがCloudflareや多くの企業のコード出荷速度を加速する一方、セキュリティチームの作業は同じようには圧縮されていません。攻撃者は1つの入口があれば侵入できるのに対し、セキュリティチームはすべての発見と封鎖が必要です。修正を作成し、回帰テストし、周囲のコードを壊さずに出荷するには、AIが取り除けない制約があります。前回の投稿の最後で述べたように、AIコーディングアシスタントに自社のバグに対するパッチを書かせた際、元のバグは修正しても、コードが依存する別の部分を静かに壊すパッチがありました。
これらのモデルがより有能になるにつれ、脅威の観点から主に3つのことに焦点を当てています。それぞれが、この投稿の後半で説明するアーキテクチャを形成します。
最初は発見速度です。フロンティアモデルは、多くの企業が依存するオープンソースライブラリを含む大量の公開コードを容易に検索できます。これはライブラリのすべてのバグが悪用可能であることを意味するわけではありませんが、広く使われるライブラリやフレームワークは、攻撃者が大規模に研究できる共有の表面を提供します。実際に到達可能な脆弱性が存在する場合、モデルは保守者や防御者がすべての下流の使用をレビューするよりも高速に発見、推論、バリアント生成を行えます。脆弱性が発見されてから防御者がそれを知るまでのギャップが、最も懸念される点です。自社コードに対してこれらのモデルを実行していなければ、他の誰かが実行していると想定すべきです。
第二はエクスプロイトの量と適応性です。モデルは単一のエクスプロイトの数千ものバリエーションを生成し、同じ規模で偵察を行えます。その量は攻撃者に有利に働きますが、シグネチャベースの検出を必ずしも回避できるわけではありません。多くのバリエーションは同じ基礎シグネチャを持つため、最初を捕捉するルールが残りも捕捉します。適応性こそがシグネチャベースの検出を回避する方法です。モデルにSQLインジェクションを示すよう依頼すると、教科書的な例が返ってきます。WAFが存在することを伝えると、プローブし、何がブロックされるかを学習し、ペイロードをルールをすり抜けるまで書き換えます。
第三は脆弱性が最終的に悪用された場合の影響です。すべてを捕捉するアーキテクチャはありません。脆弱性が悪用された後、私たちは自問します：「1つのID、1つのパス、1つのクレデンシャルで、何かが阻止するまでに攻撃者はどこまで到達できるか？」答えが「どこでも好きな場所」なら、脆弱性は問題ではなく、その周囲のアーキテクチャが問題だったのです。
Cloudflareのスーパーパワー：可視性
私たちは世界のWebトラフィックの約5分の1を把握しており、そのトラフィックから、どのペイロードが変異しているか、どのパターンが増加しているか、攻撃者のツールが次にどこへ移動するかをリアルタイムで知ることができます。2つのチームがその可視性を防御に変換します。
1つ目はCloudforce Oneです。これはCloudflareセキュリティ組織内の脅威インテリジェンス、研究、運用チームで、ネットワーク全体で見えたものを、スタック全体が行動できるインサイトに変換します：追跡された敵対者、新たなキャンペーン、IOC（侵害指標）。この作業の難しい部分は、何が悪意あるかを知ることではなく、緩和までの遅延でした。脅威の知識は通常、脅威レポートからフィード、そして企業の防御へと伝わる必要があり、攻撃者はそれよりも速く行動することを学んでいます。当社のネットワークはそのギャップを埋めます：Cloudflareのお客様は、Cloudforce Oneの脅威インテリジェンスをWAF内で直接使用して高リスクトラフィックをブロックできます。
2つ目は、実際の検出を行うWAFエンジンを所有するチームです：自社プロパティの前に展開され、すべてのCloudflareのお客様が利用できる管理ルールセット、WAF Attack Scoreの背後にある機械学習、そしてCVEが公開される前にルールを出荷できる関係性。チームはグローバルに分散し、迅速に行動し、攻撃のPoCが知られてから数時間以内にルールをリリースします。検出が展開されると、30秒以内に当社のネットワーク全体とすべてのCloudflareのお客様に到達します。React2Shellは最近の例です：管理WAFルールは、公式アドバイザリが公開される数時間前に、自社プロパティと他のCloudflareのお客様を保護していました。
スコアリングレイヤー、アプリケーションの前に置く防御、脆弱性の封じ込めはすべて、これら2つのチームが見たものに基づいています。
シグネチャよりスコア
シグネチャベースの防御は、新奇なエクスプロイトが稀で、バリエーションに数週間かかる世界向けに構築されました。Cloudflareの従来のSLAは、新鮮なPoCからライブルールの展開まで12時間でした。フロンティアモデルの出現により、これではもはや十分ではありません。検出はCVEが発見される前に行われる必要があります。そのため、従来のシグネチャベースのWAFの前にMLベースの検出を配置しています。
モデルは過去の攻撃トラフィックの大規模なボディでトレーニングされ、既知の脆弱性の新しい亜種を捕捉します。新しいSQLインジェクションやリモートコード実行チェーンは、モデルが以前に見た攻撃形状の再配置であることがほとんどで、特定のエクスプロイトがまったく新しい場合でも同様です。すべてのリクエストに対してモデルを実行し、リクエストがそれらの基礎形状にどの程度近いかに基づいて1～99のWAF Attack Scoreを割り当てます。スコアが低いほど、リクエストを積極的に処理します。そのスコアがリクエストを通すかどうかを決定します。同様のスコアリング手法を、AI Security for AppsでAIプロンプトに適用しています：既知の悪意のあるプロンプトのリストと照合するのではなく、プロンプトが実際の攻撃にどの程度似ているかをスコアリングします。
脆弱性をめぐるアーキテクチャ
これらの機能は、アプリケーションの前に積み重ねられて初めて意味を持ちます。多層防御の最初のレイヤーはWAFです。既知の悪いパターンに一致するものは、アプリケーションに到達する前にドロップされ、明らかなトラフィックを排除し、以下のより専門的なレイヤーが残りに集中できるようにします。
APIサーフェスでは、API Shieldを通じてポジティブセキュリティモデルを実行します。すべての悪いリクエストを予測しようとする代わりに、各APIへの有効なリクエストの姿を、API自身の定義から、または実際のトラフィックから学習して記述し、適合しないものは通過させません。これにより、フロンティアAIモデルの利点が無効化されます：検証済みトラフィックのみ許可するため、数千の新しい攻撃バリエーションを生成してもシステムをバイパスできません。
Bot Managementは、フロンティアモデルがマップを構築する前に、プロービングトラフィックを捕捉します。各リクエストが自動化されている可能性をスコアリングし、ネットワーク全体で同じシグナルを使用します：クライアントの動作、実際のブラウザに見えるかどうか、接続が既知の悪いパターンに一致するかどうか。攻撃が成功するのは、弱点を見つけられた場合のみです。
Zero Trust Network Accessは、すべての内部アプリケーションに使用されます。ネットワーク内部にいることの暗黙の信頼は、すべての従業員がすべてのツールにアクセスする際の明示的なリクエストごとのIDとポリシーに置き換えられます。あるエンジニアが設定ミスのあるツールを出荷したときに、その価値が明らかになりました。フラットネットワークでは同じセグメント上のすべてが露出したでしょうが、当社のデプロイでは露出はツール自体に留まりました。その後、新しくデプロイされた、または設定ミスのあるアプリケーションがアクセスポリシーが整う前に到達可能にならないよう、Require Access Protectionを構築しました。
IdP Federationにより、すべてのCloudflareアカウントでセキュアバイデフォルトの状態を一貫して維持しやすくなります。これは、より多くの人が内部ツールを迅速に出荷する場合にさらに重要になります。各チームが個別にSSOを設定する代わりに、IDプロバイダ（IdP）を一度設定して組織全体で共有します。新しいアカウントは自動的にSSOを取得し、受信側のIdP接続は読み取り専用で、各アカウントのAccessポリシーは通常のリクエストフローの一部として結果のIDを評価します。
MCP Server Portalは、チームがAIエージェントをエンタープライズシステムに接続する制御された方法を提供します。エージェントは単一のポータルを通じて集中管理されたMCPサーバーにアクセスし、すべてのアクションが記録されます。これにより、エージェントが誰かに代わって行動したとき、何をしたか、何に触れたか、許可されるべきだったかがわかります。構築方法の全容は、エンタープライズMCPに関する投稿にあります。
AI Gatewayは、内部AIツールの前に、AI Security for Appsが顧客向けAI機能の前にあるのと同じ方法で展開され、同じスコアリングと同じ可視性を提供します。社内では、可視性の部分がブロックよりも有用です。なぜなら、意味のあるポリシーを作成する前に、エンジニアが実際に何を構築しているかを把握する必要があったからです。
チームが開始できる場所
フロンティアモデルは攻撃者が脆弱性を発見し、ペイロードを適応させ、より速く動くことを支援しますが、それでもアプリケーションの前に展開する多層防御を通過しなければなりません。チームは以下から開始すべきです：
公開アプリケーションの前に検査を配置する。
有効なAPIトラフィックの定義。
ボット検出を使用して自動プロービングを制限する。
内部ツールが到達可能になる前に、IDとアクセスポリシーを要求する。
AIおよびエージェントシステムの場合：
モデルトラフィックをゲートウェイ経由でルーティングする。
エージェントを承認されたMCPサーバーを通じて接続する。
彼らが何をしたかを記録する。
目標は、1つのレイヤーが見逃したときに、次のレイヤーが到達範囲を制限することです。