ゼロデイ攻撃の脅威を業界公表前に阻む：Akamaiの事前対応型WAAPアーキテクチャ

現代のビジネスはすべてアプリケーション上で稼働しています。そのため、デジタルオペレーションの安全性は、業界が脆弱性の存在を認識する前にエクスプロイトをブロックできるかどうかにかかっています。攻撃者はもはや、Webアプリケーションファイアウォール（WAF）に対して基本的なインジェクションを試すだけではありません。人間であれAIであれ、自動化されたボットネット、APIの脆弱性、そしてゼロデイを連鎖させ、稼働中のバックエンドロジックを侵害する複雑な攻撃キャンペーンを実行しています。

こうした素早く変化する脅威を食い止めるには、セキュリティリーダーは分断されたポイントソリューションへの依存から脱却し、共通のデータモデルを持つ統合アーキテクチャへと移行する必要があります。

エンタープライズの購買担当者にとっても、アプリケーション防御の評価基準は、個々の製品性能から「統合プラットフォームがもたらす運用上の相乗効果」へと根本的にシフトしているのです。

構造的なレジリエンスを実現するには、共有のアーキテクチャコンテキストと、インタラクションの発生時の意思決定に対応できる一貫したデータモデルが必要になります。本記事では、事前対応型のゼロデイ緩和モデルを紐解くことで、真に信頼できるプラットフォームと、段階的な展開（ステージング）を行わない脆弱なデプロイモデルとを分ける、構造的なアーキテクチャの違いを見ていきます。

重要なインフラストラクチャの脆弱性が発覚した場合、企業のリスク露出は「時間単位」で計算されます。Apache Camelにおけるリモートコード実行（RCE）の脆弱性（CVE-2025-29891およびCVE-2025-27636）の公表と緩和策の展開を追うと、事前対応型のプラットフォームと事後対応型のシグネチャによる対応との間に、大きな実行力の差があることが証明されています。

• 3 月 7 日（金）：Akamai Security Intelligence GroupはApacheの協力で、初日（Day 0）から事前対応型のインライン保護メカニズムである「Rapid Rule」を展開しました。この情報は3月9日まで非公開とされていました。
  

• 3 月 9 日（日）：

  週末の48時間に及ぶ防御の空白期間を経て、F5が初期の防御策を展開しました。

• 3 月 11 日（火）：

  • Cloudflareが緩和策のアップデートをオンラインでプッシュしました。標的にされやすい企業環境にとって、これは4日間にも及ぶ構造的な空白期間であり、中核となるアプリケーション資産が積極的な脅威スキャンにさらされ続けたことを意味します。なお、同社は約1ヶ月後のブログ記事でこのアップデートを振り返っています（後述「不正確な検知がもたらす真の代償」を参照）。 

  • AkamaiはCiti Cyber Security Operationsと緊密に連携して回避（バイパス）手法を特定し、Apacheのセキュリティチームへ報告しました。その結果、新たなCVE（CVE-2025-27636）が割り当てられ、双方のCVEをカバーするための保護アップデートが元のRapid Ruleに適用されました。

• 3 月 12 日（水）： 発見から約1週間が経過した時点で他社動向を追跡したところ、FastlyやImpervaなどの主要ベンダーは、依然として有効な防御策や公開インジケーターを提供していないことが確認されました。

不正確な検知がもたらす真の代償

セキュリティ対応が遅れると、ベンダーからの保護策が届くまでの間、現場のチームは一時的な緩和策を手動で実装しなければならず、運用の負担が増大します。ようやく提供された保護策には、当然ながら正確性と信頼性が期待されます。Apache Camelの事例は、スピードと検知精度の両方が欠けた場合に何が起こるかを示しています。

最初の発見から約1ヶ月後、CloudflareはApache Camel（CVE-2025-29891）に対する事後対応のルールが、自社ネットワーク全体で大規模なシステムの不安定化を引き起こしたと公表しました。実際のトラフィックデータを用いた段階的な検証が欠如していたため、このルールは高い頻度で誤検知を引き起こし、正規の顧客トランザクションまでブロックしてしまったのです。最終的に17:03（UTC）、同社のセキュリティ・オペレーション・センターは緊急停止措置を取り、保護機能を全面的に無効化せざるを得ませんでした。

2025年後半にサーバーサイドのWebフレームワークを直撃した脆弱性は、アプリケーションスタックの上層に直接的な脅威をもたらし、標準的なWebの動作をコード実行へのバイパス手段へと変えてしまいました。CVE-2025-55182の緩和策とアップデートの記録を見ると、リアルタイムにセキュリティを改善していくアプローチと、未検証のまま本番環境をアップデートするアプローチとの違いが浮き彫りになります。

• 12 月 2 日（月）：AkamaiはRapid Rule 3000976を通じて環境内にコアとなる保護策を展開し、12月3日（火）まで一般への公開を厳格な情報制限下に置きました。Cloudflareも、12月3日の遅い時間帯の投稿において、同じ日に初期保護を展開したと主張しています。

• 12 月 3 日（火）：AWSが公開用の脅威シグネチャのアップデートをオンラインで公開しました。

• 12 月 4 日（水）～ 12 月 5 日（木）： Akamai Security Intelligence Groupは、緩和を単発のルール適用で終わらせるのではなく、エクスプロイト活動を継続的に監視しました。新たに出現する攻撃の変種を分析し、48時間以内に3つの段階的なルール改善（v1、v2、v3）を立て続けにリリースしました。このアジャイルなアプローチにより、高い防御精度を維持しながら、進化する脅威へと保護を適応させました。

• 12 月 4 日（木）： F5、Imperva、Googleがそれぞれのスタックに防御策を展開しました。

• 12 月 5 日（金）： Microsoft Azureが保護ルールをロールアウトしました。同時期に、CloudflareはCVE-2025-55182に関して未検証のグローバルアップデートを自社のセキュリティシステムにリリースしています。段階的テストや検証を行わずにシグネチャを変更した結果、アクティブループ障害が引き起こされ、顧客のアプリケーションが完全にオフラインになる大規模障害へと発展しました。

ゼロデイルールの展開が数日遅れると、稼働中のシステムは完全に無防備な状態になります。その間、攻撃者はマシンスピードでオープンソースのスキャナーを兵器化していきます。影響力の大きいWeb環境において、48〜96時間もの間「自社のエンドポイントには攻撃が来ないだろう」と想定するのは、企業としてあまりにも大きすぎるギャンブルと言えます。

Webアプリケーションのアーキテクチャは、未検証のまま即座に適用される設定変更を許容できません。すべてのトラフィックを単一のエンジンにルーティングするセキュリティアーキテクチャにおいて段階的なロールアウトが行われない場合、潜在的なプログラムの異常やエッジケースでの誤検知は、瞬時にネットワーク全体へと波及してしまいます。

その結果、事業を継続するためにセキュリティチームがルールを完全に無効化してパラメータの可視性が損なわれるという深刻なセキュリティの穴を生むか、あるいは壊滅的なプラットフォームのダウンタイムを引き起こすかの二択を迫られることになります。

真のプラットフォームのレジリエンスは、次のような構造化された最適化のループによって支えられています。

• 制御された環境で自動化されたシンセティックテストを実行する

• 限定的な検証層からより広範なデプロイへ、変更を段階的に展開する

• 予期せぬ挙動がないか、本番トラフィックを継続的に監視する

最終的な本番展開においては、自動レビューと人手によるレビューを組み合わせ、ゾーンベースの検証を行う必要があります。これにより、多様なアプリケーションアーキテクチャ全体にわたるトラフィックの異常や、予期せぬ影響を特定できます。

脅威インテリジェンスの進化に合わせて、セキュリティチームは迅速に変更をロールバックし、検知ロジックを洗練させ、改善版を再展開できなければなりません。このアプローチにより、正規トラフィックへの影響を最小限に抑え、アプリケーションのパフォーマンスとサービスの可用性を維持しながら、能動的な攻撃者に対して保護を適応させることが可能になります。

従来のWAFモデルでは、セキュリティチームが静的なルールの例外を作成し、手動で誤検知を管理しなければなりません。これは「例外処理の悪用」として知られる深刻な企業の脆弱性を引き起こします。組織が自由記述のパラメータ（説明文やコメント欄など）のチェックを回避するために静的な例外を作ると、攻撃者はまさにそのパラメータ内に悪意のあるペイロードを埋め込むようになります。

大規模な実稼働データセットに対する社内のデータサイエンスの分析により、静的な例外処理の危険性が裏付けられています。

• 顧客自身が静的例外を管理した場合：顧客が定義した静的ルールがペイロードを許可してしまったため、実際の攻撃の23%を完全に見逃していました。

• 適応型インテリジェンス（Akamaiのコアエンジン）に依存した場合：攻撃の見逃しは、無視できる水準である0.02%にまで減少しました。
  

Akamaiのコアエンジンは、リクエストごとに複雑な誤検知の論理分析を計算することで、コンテキストを考慮した意思決定を行います。これにより、無害なWebトラフィック（生のHTMLビジュアルエディタやJira Query Languageのクエリなど）に対しては動的にトリガーをスキップします。一方で、クライアントのプロファイルが能動的な攻撃者の振る舞いを示している場合は、鉄壁の保護適用を維持します。

この差が生じる理由は、完全に構造的な問題です。

Akamaiは、ミッションクリティカルな企業アプリケーションが、段階的ではないグローバルな変更を許容できないことを認識しています。すべてのRapid Ruleおよびプラットフォームのアップデートは、高度に構造化された自動テストと、多段階の検証フレームワークに従っています。

• ラボでのシンセティック検証：社内ラボ環境とサンプリングされたネットワークトラフィックに対して検知ロジックを検証し、カバレッジ、有効性、および運用への潜在的な影響を評価します。

• エッジのシャドーモード展開：段階的なロールアウトを通じて、ライブの本番トラフィックに対してアップデートをシャドーモードで評価します。これによりチームは、実世界のトラフィックにおける攻撃トリガー、例外、およびベースラインからの逸脱に対する検知精度を評価し、強制適用を有効にする前に潜在的な問題を特定できます。

• 監視付きの段階的本番ロールアウト：脅威リサーチチームとQAチームが回帰テストとピアレビューのサイクルを実施した後、トラフィックの範囲を広げながらゾーンごとに本番展開を段階的に進めます。リリースチームは攻撃検知とプラットフォームの安全性を監視し、予期せぬ影響が発生した場合には迅速に変更をロールバックできる体制を維持します。