- Cloudflareが、大規模言語モデル（Large Language Models, LLMs）の前段に配置して悪用を識別する新しい保護レイヤー『AI向けファイアウォール（Firewall for AI）』の開発を発表
- インターネットに接続されたアプリケーションとしてLLMを利用することは、新たな脆弱性を持ち込み、悪意ある攻撃者に悪用される可能性がある
- 既存のWebおよびAPIアプリケーションに影響する脆弱性に加え、LLMの動作方式に起因する新たな脅威も生じる
- AI向けファイアウォールは、LLMを利用するアプリケーションに特化した高度なWebアプリケーションファイアウォール（WAF）であり、脆弱性を検出し、モデル所有者に可視性を提供するツールセットを含む
なぜLLMは従来のアプリケーションと異なるのか？
- LLMをインターネット接続アプリケーションとして考えた場合、従来のWebアプリと比べて2つの大きな違いがある
- 第一に、ユーザーが製品とやり取りする方法が異なる。従来のアプリは決定論的である一方、LLMは非決定論的で自然言語を基盤としている
- 第二に、アプリケーションの制御プレーンがデータと相互作用する方法が異なる。従来のアプリケーションでは制御プレーン（コード）とデータプレーン（データベース）が明確に分離されているが、LLMでは学習データがモデル自体の一部となるため、ユーザープロンプトによるデータ共有の制御が難しい
OWASP LLMの脆弱性
- OWASP FoundationはLLMに関する脆弱性トップ10を公開しており、言語モデルをどう保護するかを考える上で有用なフレームワークを提供している
- 一部の脅威はWebアプリケーションのOWASP Top 10と似ているが、言語モデルに特化した脅威もある
LLMのデプロイ
- LLMのリスクはデプロイモデルによって異なる。現在、3つの主要なデプロイアプローチがある
- Internal LLM（内部）: 企業は日常業務で人員を支援するためにLLMを開発する。これは企業資産と見なされ、従業員以外がアクセスしてはならない。たとえば、カスタム提案の生成に使われる営業データや顧客とのやり取りで学習したAIコパイロット、あるいはエンジニアが参照できる社内ナレッジベースで学習したLLMなどがある
- Public LLM（公開）: 企業外からもアクセス可能なLLM。こうしたソリューションには誰でも使える無料版があることが多く、一般的または公開された知識で学習されていることが多い。たとえばOpenAIのGPTやAnthropicのClaudeがある
- Product LLM（製品）: 企業の観点では、LLMは顧客に提供される製品やサービスの一部である場合がある。通常は自社ホスティングのカスタムソリューションで、会社のリソースと相互作用するツールとして利用できる。たとえば顧客サポートチャットボットやCloudflare AIアシスタント
- すべてのシナリオにおいて、モデルを悪用から保護し、モデルに保存された独自データを守り、ユーザーを誤情報や不適切な内容から保護する必要がある
AI向けファイアウォール
- CloudflareのAI向けファイアウォールは、従来のWAFのように配置され、すべてのLLMプロンプトを含むAPIリクエストをスキャンして、想定される攻撃パターンやシグネチャを検出する
- Cloudflare Workers AIプラットフォームでホストされたモデルの前段にも、サードパーティ製インフラでホストされたモデルの前段にも配置でき、Cloudflare AI Gatewayと併用できる
ボリューム攻撃の防止
- OWASPが挙げる脅威の1つに、モデルのサービス拒否（Model Denial of Service）がある
- 従来のアプリケーションと同様に、DoS攻撃はリソースを過剰に消費してサービス品質を低下させたり、モデル運用コストを増大させたりする
- このリスクは、個別セッションにおけるリクエストの比率を制御するレート制限ポリシーを採用することで緩和できる
機密情報の識別
- 機密情報に関するユースケースは2つあり、モデルとデータを所有している場合と、公開LLMに対してユーザーがデータを送信するのを防ぎたい場合とで異なる
- OWASPが定義する 機密情報の漏えい は、LLMが応答内で機密データを不用意に公開した際に発生し、無許可のデータアクセス、プライバシー侵害、セキュリティ侵害につながる可能性がある
モデル悪用の防止（Preventing Abuse）
- モデルの悪用には、『プロンプトインジェクション』や、幻覚を引き起こしたり、不正確・不快・不適切・話題外の応答を生成させたりするリクエスト送信など、さまざまなアプローチが含まれる
- プロンプトインジェクションは、特別に細工された入力によって言語モデルを操作し、LLMに意図しない応答を引き起こそうとする試みである
AI向けファイアウォールの利用方法
- 「Application Security Advanced」を利用する企業顧客は、Advanced Rate Limiting と Sensitive Data Detection を今すぐ利用できる
- AI向けファイアウォールのプロンプト検証機能は現在開発中で、今後数か月以内にWorkers AIユーザー向けベータ版として提供予定
1件のコメント
Hacker Newsの意見
プロンプトインジェクションとジェイルブレイクは別物だと主張したいが、この点に関する議論ではすでに負けているように思える。Cloudflareの記事によれば、モデルの悪用とは、プロンプトインジェクションのような手法を含む、より広いカテゴリの悪用を指す。プロンプトインジェクションは、開発者が定義したプロンプトと、ユーザーからの信頼できない入力を連結したときに発生する。信頼できる入力と信頼できない入力の連結がなければ、これはプロンプトインジェクションではない。この区別は重要であり、一般的なジェイルブレイク攻撃に対して訓練されたモデルでは、これを捉えるのは難しいだろう。
WAF（Web Application Firewall）は、セキュリティチームが制御も理解もできないWebサービスに対する、その場しのぎの解決策だった。性能上の問題や、悪意あるトラフィックを効果的に遮断するためのチューニングの難しさから、次第に好まれなくなった。WAFベースのアプローチは、無知の告白であり、弱点の所在を示すものでもある。モデルへの移行はまだ検証されておらず、アプリのレスポンシブな自己防御のような考え方にも反している。
AI学習の目的で自分のサイトがスクレイピングされるのを防ぐ保護が欲しい。すでに負け戦のようにも感じるが、プライバシーを重視する人たちも同じように考えていると知った。
Cloudflareの製品の多くがそうであるように、この製品も利用する顧客が増えるほど有用になり、顧客ごとの手作業も少なくて済む。Cloudflareの価値は、設定や保証ではなく、ほぼリアルタイムで他のすべての人が見ている攻撃の可視性と、それをパッケージ化して提供することにある。
この製品はとても良いアイデアに見える。ファイアウォールを追加して有効化するのと同じくらい簡単であれば、他のガードレール製品よりも関心と採用を集めやすい。汎用的なLLMファイアウォールがどれほど有用になり得るのか、またモデルやユースケースに応じてどれだけのカスタマイズが必要で、どこまで可能なのかは気になる。だが、これは比較的簡単に解決できそうだ。
この投稿を読んだ限りでは、Cloudflareは検閲と文化戦争に首を突っ込みつつある。Cloudflareの有料ユーザーは、自分たちの政治的バイアスを押しつけるためにCloudflareへ金を払うだろうし、AIユーザーはCloudflareが検閲に加担していると非難するだろう。Cloudflareは不必要に政治的な争いへ巻き込まれる可能性がある。
リクエストをフィルタリングするためにAIを使っているのか？ だとしたら、まさに天上の組み合わせだ！
[マイクに寄りかかりながら] 秘密の材料は正規表現です。
LLMの悪用を防ぐために、LLMが購入／非購入の判断を行う状況で、スマート決済資格情報について同じ発想の何かをやりたいと前から考えていた。決済資格情報が正当なチェーンによって要求された場合にのみ、単回使用トークン（またはそれに類するもの）を提供するというアイデアだ。この分野について考えている人がいれば、ぜひ話してみたい。
以前から、彼らはマーケティングにおける次の大きな流行を追い続けるのだろうと思っていた。まあいい、CDN/DNS/WAF市場において、いまだにそういうことを気にする企業にとっては、競争の余地が増えるだけだ。