数週間前、私たちはサイバー・フロンティア・モデルを自社のソースコードに対して使った結果を紹介したProject Glasswingについての記事を公開しました。この記事は多くの反響をいただきましたが、中でも特に共感を集めたのは、「パッチのスピードよりも、脆弱性を取り囲むアーキテクチャ（システム設計）の方が重要である」という考え方でした。
この記事を読んだCISO（最高情報セキュリティ責任者）やセキュリティ担当者から受けた質問で多かったものは、「自社のアーキテクチャを外部評価するとどう見えるか」、「何を監視すべきか」、「どこから対策を始めるべきか」、「Cloudflareはどのような支援ができるのか」？といった内容でした。
詳しい説明に入る前に、この記事で紹介するアーキテクチャは、ほぼCloudflareの製品で構成されているということをお伝えします。これは、Cloudflareでは自社で開発したセキュリティ製品を、まず自社で使う（カスタマーゼロ）という方針を取っているためです。Cloudflareのサービスは、社内のソースコードや従業員向けシステム、そしてお客様向けアプリケーションを保護するために、すでにこの構成で運用されています。Cloudflareをご利用中のお客様であれば、ここで紹介する機能はすべて現在利用できます。Cloudflareをご利用でない場合でも、ここで紹介する考え方は、皆さんが構築しているどのようなシステムにも応用できます。
前回の投稿では、Mythosのようなサイバー・フロンティア・モデルが、攻撃者の行動スピードをどのように変えるのかを紹介しました。サイバー・フロンティア・モデルを使用することで、従来のモデルよりもはるかに高速に、脆弱性を発見し、攻撃手順（エクスプロイトチェーン）を試行し、実際に動作する概念実証（PoC）を作成することができます。ただし、その変化はスピードと規模に対してのものであり、攻撃の流れそのものは従来と変わらず、「偵察 → 初期侵入 → ラテラルムーブメント → 永続化 → データを持ち出す」といった一連の手順はそのままです。インターネット全体を対象にすれば、モデルは攻撃しやすいシステムを短時間で大量に見つけて攻撃できる一方、防御がしっかりしたシステムに対しては、依然として探査や適応が必要であり、その過程で慎重な人間の攻撃者よりも多くの痕跡（ノイズ）を残すことがあります。
これまで実際の攻撃を成立させるまでの大きな障壁であった、脆弱性の発見、攻撃手順の組み立て、そしてPoCの作成といった3つの工程を、フロンティア・モデルはごく短時間で実行できるため、以前は時間をかけて慎重に行われていた作業が、今では高速かつ大量に実行されるようになっています。
それに対し、Cloudflareをはじめ多くの企業では、AIによって開発チームのコード公開速度は大きく向上している一方で、セキュリティチームはその高速化に追随できていないのが現状です。その理由として、攻撃者は侵入口を1つ見つければ十分ですが、防御側はすべての侵入口を見つけて塞がなければならないこと、また、修正プログラムを作成し、回帰テストを行い、周辺の機能を壊さずに公開するという作業にはAIでは解決できない制約がある点が挙げられます。この制約については、前回の投稿の最後で紹介したように、AIコーディング支援ツールに自社の脆弱性を修正させる実験を行った際、このことを痛感しました。一部の修正は元のバグを解消したものの、そのコードが依存していた別の機能を気付かないうちに壊してしまうものもありました。
こうしたモデルの性能がさらに向上していく中で、私たちが脅威の観点から特に重視しているのは、次の3点です。これらが、このあと紹介するアーキテクチャの設計方針にもつながっています。
まず1つ目は、発見の速度です。フロンティア・モデルは、多くの企業が利用しているオープンソースライブラリを含め、膨大な公開ソースコードを効率よく調査できます。もちろん、ライブラリにバグがあるからといって必ず悪用できるわけではなく、また、ほとんどの脆弱性がライブラリに存在するという意味でもありません。実際に悪用できるかどうかは、そのコードがどのように利用されているか、攻撃者が入力したデータが脆弱な処理まで到達できるか、そして周囲にどのような防御策があるかによって決まります。しかし、多くの企業で共通して使われているライブラリやフレームワークは、攻撃者にとって一度に調査できる大きな標的となります。もし実際に悪用可能な脆弱性が存在すれば、モデルはその脆弱性を見つけ出し、攻撃経路を考え、PoCのさまざまなパターンを作り出すことができます。そのスピードは、ライブラリの保守担当者や利用企業の防御担当者が、影響範囲を確認するよりも速い場合があります。私たちが最も懸念しているのは、攻撃者が脆弱性を発見してから、防御側がその存在を知るまでの時間差です。もし自社のコードをモデルで調査していないのであれば、誰か別の人がすでに調査していると考えたほうがよいでしょう。
2つ目は、エクスプロイトの量と適応能力です。モデルは単一のエクスプロイトから何千通りものバリエーションを作り出し、同じ規模で偵察を行うことができますが、この大量の試行は攻撃者に有利である一方、多くのバリエーションは同じ特徴（シグネチャ）を持っているため、防御側がルールによって最初の攻撃を検知できれば、その後の多くも同じルールで防ぐことができます。しかし、モデルはシグネチャベースの検出を回避できる適応能力を持ちます。例えば、モデルにSQLインジェクションの作成を単に依頼するだけでは教科書どおりの攻撃を生成しますが、前にWAFがあることを追加で伝えた場合、モデルは何がブロックされるのかを試しながら学習し、攻撃コード（ペイロード）を書き換えながらルールを回避できるまで調整を続けます。
3つ目は、脆弱性が実際に悪用された場合の影響範囲です。どのようなセキュリティアーキテクチャを構築したとしても、すべての攻撃を防ぐことはできません。脆弱性が悪用されたあと、私たちが考えるべきは、「攻撃者は、1つのアカウント、1つの侵入経路、あるいは1組の認証情報だけで、他の防御に阻まれるまでどこまで到達できるのか」ということです。もし答えが「行きたい場所ならどこへでも行ける」なのであれば、問題は脆弱性そのものではありません。本当の問題は、その脆弱性を取り巻くアーキテクチャにあります。
Cloudflareは、世界のWebトラフィックのおよそ5分の1を処理しています。そのため、どのような攻撃コード（ペイロード）が変化しているのか、どのような攻撃パターンが増え始めているのか、そして攻撃者が次にどのようなツールを使おうとしているのかを、リアルタイムで把握できます。そして、この膨大な情報を実際の防御に生かしているのが、Cloudflareの2つのチームです。
まず1つ目は、Cloudflareのセキュリティ部門に所属する脅威インテリジェンス・調査・運用チームCloudforce Oneです。このチームは、ネットワーク全体から得られる情報を分析し、他のセキュリティ機能が活用できる形にまとめます。具体的には、監視対象となる攻撃者グループ、新たに始まった攻撃キャンペーン、侵害の痕跡（IoC）などの情報です。これまでの課題は、「何が悪意のある攻撃か」を見つけることではなく、その情報を防御に反映するまでに時間がかかることでした。通常、新しい脅威に関する情報は、まず脅威レポートとして公開され、それが脅威情報フィードに取り込まれ、さらに各企業のセキュリティ製品へ反映されて、ようやく攻撃をブロックできるようになります。しかし、攻撃者はその流れよりも速く行動するようになっています。Cloudflareでは、自社ネットワークを利用することでこの時間差をなくしています。現在では、Cloudflareのお客様は、Cloudforce Oneが提供する脅威インテリジェンスをWAFで直接利用し、リスクの高い通信を即座にブロックできるようになっています。
2つ目は、実際に攻撃を検知するWAFエンジンを開発・運用するチームです。このチームは、自社サービスを保護するとともに、すべてのCloudflareのお客様が利用できる管理ルールセット（Managed Rules）や、WAF Attack Scoreを支える機械学習モデル、さらに場合によってはCVE（共通脆弱性識別子）が公開される前に検知ルールを配信できる体制を担当しています。このチームは世界各地に配置されており、非常に迅速に対応します。新しい攻撃のPoCが公開されると、数時間以内に検知ルールを作成し、配信します。そして、一度ルールが公開されると、30秒以内にCloudflareのネットワーク全体と、すべてのお客様へ反映されます。最近の例としては、React2Shellがあります。この脆弱性では、公式のセキュリティアドバイザリが公開される数時間前から、Cloudflareの管理WAFルールが、自社サービスだけでなくCloudflareをご利用のお客様のサービスも保護していました。
このように、攻撃を危険度で評価するスコアリング機能、アプリケーションの前段で攻撃を防ぐ仕組み、そして万一脆弱性が悪用された場合でも被害を最小限に抑えるための設計は、いずれもこれら2つのチームがネットワーク全体から得た情報を基盤として成り立っています。
従来のシグネチャベースの防御は、新しい攻撃手法がめったに現れず、その亜種が出回るまでにも数週間かかる時代を前提に設計されていました。Cloudflareではこれまで、新しい攻撃のPoCが公開されてから、実際にWAFルールを作成・配信するまでの目標時間（SLA）を12時間としてきました。しかし、フロンティア・モデルの登場によって、このスピードではもはや十分ではありません。これからは、CVE（共通脆弱性識別子）が公開される前から検知できることが求められます。そのためCloudflareでは、従来のシグネチャベースのWAFの前段に、機械学習（ML）による検知機能を配置しています。
このモデルは過去の膨大な攻撃トラフィックを学習しているため、新しい脆弱性の変種でも公開される前に検出できます。実際には、新しいSQLインジェクションやリモートコード実行（RCE）の攻撃であっても、その多くは過去に見られた攻撃の特徴を組み合わせたり、少し形を変えたりしたものです。Cloudflareでは、すべてのリクエストに対してこのモデルを実行し、WAF Attack Scoreとして1～99のスコアを付与しています。このスコアは、既知の攻撃シグネチャと照合して決めるのではなく、そのリクエストが過去に学習した攻撃パターンにどれだけ似ているかを基準に算出されます。スコアが低いほど攻撃である可能性が高いと判断され、より厳しい対処が行われます。そして、このスコアに基づいて、そのリクエストを許可するかどうかを決定します。同じ考え方は、AI Security for AppsによるAIプロンプトの保護にも採用されています。こちらも、既知の悪意あるプロンプトの一覧と照合するのではなく、そのプロンプトが実際の攻撃とどれだけ似た特徴を持っているかをスコア化して判定します。
こうした機能も、アプリケーションの前段に適切に配置されて初めて効果を発揮します。Cloudflareの多層防御において、最初の防御層となるのがWAFです。既知の悪意あるパターンに一致する通信は、アプリケーションへ届く前に遮断されます。これにより、明らかな攻撃トラフィックの大部分を最初の段階で取り除き、その下にあるより高度な防御機能は、残った通信だけを重点的に分析できるようになります。APIについては、API Shieldによるポジティブセキュリティモデルを採用しています。これは、どのようなリクエストが悪意のあるものかを全てのリクエストに対して事前に予測しようとするのではなく、正しいAPIリクエストとはどのようなものかをあらかじめ定義する方式です。その定義には、APIの仕様そのものを利用する場合もあれば、実際のトラフィックを学習して作成する場合もあります。そして、その定義に当てはまらないリクエストはすべて遮断します。この方式では、AIが何千通りもの新しい攻撃パターンを生成したとしても、正当なリクエストとして認められない限り通過できないため、フロンティア・AI・モデルの強みを無効化できます。
Cloudflareの多層防御アーキテクチャ
Bot Managementは、フロンティア・モデルが攻撃対象を調査してシステム構成を把握する前に、そのような偵察活動を検知します。この機能は、すべてのリクエストに対して、自動化されたアクセスである可能性をスコア化します。判断には、クライアントの振る舞い、本物のブラウザであるかどうか、接続が既知の悪意あるパターンに一致するかどうかなど、Cloudflareネットワーク全体で得られるさまざまな情報が利用されます。攻撃は、防御の手薄な部分を見つけられた場合にしか成功しません。
Zero Trust Network Accessは、社内のすべてのアプリケーションで利用されています。従来のように「社内ネットワークにいるから信頼する」という考え方から、すべてのアクセス要求ごとに、利用者の本人確認とアクセス権限を確認するポリシーに置き換えられます。この価値は、Cloudflareのエンジニアが設定ミスのあるツールを公開してしまった際に明らかになりました。多層防御ではないフラットなネットワークであれば、同じネットワーク内の他のシステムまで影響が及んでいたでしょう。しかし、ゼロトラストを採用していたため、影響はそのツールだけにとどまりました。この経験を踏まえ、CloudflareではRequire Access Protectionを開発しました。これにより、新しく公開されたアプリケーションや設定ミスのあるアプリケーションは、アクセス制御ポリシーが設定されるまで外部から利用できないようになっています。
IdP Federationは、すべてのCloudflareアカウントで安全なデフォルト設定を一貫して維持しやすくします。これは、より多くの人が社内向けツールを迅速に開発・提供するようになるにつれて、さらに重要になります。各チームが個別にSSOを設定するのではなく、IDプロバイダー（IdP）を一度設定し、それを組織全体で共有します。新しく作成されたアカウントには自動的にSSOが適用され、受信側のIdP接続は読み取り専用になります。また、各アカウントのAccessポリシーでは、通常どおり認証された利用者情報に基づいてアクセス可否が判断されます。
MCP Server Portalは、AIエージェントが企業内システムへ安全に接続できるようにする仕組みです。エージェントは、一元管理されたポータル経由で管理されるMCPサーバーを利用し、その操作はすべて記録されます。そのため、エージェントが誰かの代理として操作を行った場合でも、それが何を実行したのか、何にアクセスしたのか、その操作が許可されるべきだったかどうかを後から確認できます。この仕組みについては、「Enterprise MCP」に関する記事で詳しく紹介しています。
AI Gatewayは、社内向けAIツールの前段で動作し、お客様向けAI機能を保護するAI Security for Appsと同じように、リクエストをスコアリングし、利用状況を可視化します。社内では、攻撃をブロックすること以上に、エンジニアが実際にどのようなAIツールを構築し、どのように利用しているのかを把握することが重要でした。その実態を把握できて初めて、適切な利用ポリシーを策定できるからです。
フロンティア・モデルによって、攻撃者は脆弱性を見つけ、悪意のあるペイロードを変化させ、より素早く行動することができますが、アプリケーションの前段に配置された多層防御を突破しなければないことは変わりません。そのため、チームはまずここに取り組むべきことがあります：
公開アプリケーションの前に、通信を検査する仕組みを配置する。
正しいAPI通信とは何かを定義する。
ボット検知を利用して、自動化された偵察活動を制限する。
本人確認とアクセス制御ポリシー適用を、社内ツールへアクセスするための必須要件にする。
AIやAIエージェントを利用するシステムの場合：
重要なのは、ある防御層が攻撃を見逃したとしても、次の防御層によって、攻撃者が確認できる範囲、アクセスできる範囲、変更できる範囲を制限することです。
これが、「脆弱性を取り巻くアーキテクチャ」が重要である理由です。脆弱性は攻撃のきっかけになるかもしれません。しかし、攻撃がどこまで広がるかを決めるのは、その脆弱性ではなく、それを取り囲むシステム全体の設計です。
セキュリティ構成の中には、設計図の上では完全に突破不可能に見えても、実際の運用では簡単に破られてしまうものが数多くあります。そのため、当社では周辺と内部の両方で継続的にテストを行い、その両方にレッドチームが関わっています。
境界部分では、私たちは敢えてフロンティア・モデルを適応型の攻撃者として利用し、アプリケーションのセキュリティ対策を検証しています。これらのモデルは、レッドチームによるその他の検証や検知プロセス（手動テスト、脅威インテリジェンス、観測されたトラフィックパターン、PoC分析、当社ネットワークからのシグナル）と組み合わせて利用されています。これらの情報を総合して、どこを重点的にテストすべきかを判断します。それには、新たに公開された製品、最近変更された接触面、攻撃者が最初に探る可能性が高い経路が含まれます。そして、最も重要なのは、その後の対応プロセスです。もし何かが防御をすり抜けた場合、私たちは、どこに防御の不足（ギャップ）があったのかを特定し、適切なツールを組み合わせて原因を分析する、ルールまたは緩和策を作成し、更新を配信し、再度テストしてギャップが埋められたことを確認します。
環境内部では、レッドチームは「すでに境界防御は突破された」という前提から調査を始めます。何が変更されたのか、機密性の高いシステムにどのようなリスクがあるのか、さらに1つの侵害されたID、侵入経路、または資格情報によって想定以上の場所にまで到達できてしまわないかを確認します。レッドチームの調査結果をもとにアーキテクチャを変更した場合は、その変更後の環境に対して、同じ攻撃シナリオをもう一度実行し、ギャップが実際に埋められていることを確認します。
私たちは、個々の防御機能が完璧であることを前提にするのではなく、障害や防御失敗が発生した場合でも、システム全体がどのように動作するかを継続的に検証することで、このアーキテクチャが機能していることを確認しています。
もし、貴社のチームが同様の課題に取り組んでおり、意見交換をご希望される場合は、security-ai-research@cloudflare.comまでご連絡ください。