Fireworks AI侵害でNotionのAIチャット記録が流出

Fireworks AIは、1カ月足らずの間に2件目となるセキュリティインシデントを公表しました。その影響は、同社のAIインフラに依存する企業の顧客にまで及んでいます。

同社は11月10日のセキュリティ更新情報で、攻撃者がサードパーティのクラウドプロバイダーを侵害し、そこから研究開発用マシンにアクセスしたことを明らかにしました。この結果、顧客の請求情報、データセット、未完成のAIモデルの重みの一部が流出しました。

拡大した今回の公表は、Fireworks自身にとどまらない影響をもたらしています。Notionは、同社のAIチャット記録の一部が流出に巻き込まれたことを確認しました。AIインフラプロバイダーが侵害されると、そのサービスを利用する企業やユーザーにも被害が波及しかねないことを示しています。

今回の事案は、サードパーティインフラのセキュリティをめぐる、より広い問題も浮き彫りにしました。とりわけ、独自のAI資産や機密性の高い顧客情報を扱うプロバイダーでは深刻です。

Fireworks AIとは

Fireworks AIは、AIインフラを提供する企業です。開発者や企業は、基盤となるコンピューティングインフラを自前で構築・管理しなくても、AIモデルの実行、ファインチューニング、デプロイができます。 

顧客は、大規模言語モデルを軸に製品を開発するAIスタートアップから、Notion、Cursor、Upwork、Vercelといった大手テクノロジー企業まで幅広く、AI搭載機能の基盤として同社のプラットフォームを利用しています。

このためFireworksは二重の立場に置かれています。AI製品を開発する企業にとってはサプライチェーン上のプロバイダーですが、自社インフラの一部については、自らもサードパーティのプロバイダーに依存しています。 

こうしたビジネスモデルは、テクノロジー業界では珍しくありません。ただ、適切に管理しなければセキュリティリスクとなり、セキュリティ業界で繰り返し目にするサードパーティ起因の問題を招きかねません。今回のインシデントの核心もそこにあります。

数週間で2度目の攻撃

同社が不正アクセスを最初に検知したのは10月6日で、10月9日にインシデントを公表しました。攻撃者は、一部の顧客アカウントの評価ジョブで使われる環境変数にアクセスし、APIキーやアクセストークンなどのシークレットが流出しました。

しかし、話はこれで終わりませんでした。11月9日に公開した更新版のセキュリティ情報で、Fireworksは別の侵入を公表しました。今回は研究開発インフラが標的でした。 

同社によると、研究開発用マシンをホストしていたサードパーティのクラウドプロバイダーで10月23日にセキュリティインシデントが発生しました。攻撃者は翌日、これを足がかりにFireworksのシステムへアクセスしたということです。

この2件目のインシデントで、被害範囲は拡大しました。攻撃者は、リソースのメタデータ、請求先・配送先住所、請求書、支払い履歴、アカウント残高、クレジット使用状況にアクセスしました。一部の顧客では、未完成のAIモデルの重みの一部やデータセットも流出しています。 

Fireworksは、決済カード番号は保存していないため影響はないと説明しています。

攻撃者について、Fireworksは調査で得られた証拠から、LLMジャッキングに関心を持つ金銭目的のサイバー犯罪グループによる犯行とみています。同社はこのグループの名称を公表していません。また、証拠からは、10月の2件のインシデントが同一の攻撃者によるものだとは断定できないとしています。

Fireworksはその後、フォレンジック調査とセキュリティ強化の支援のため、Palo Alto NetworksのUnit 42インシデント対応チームを起用しました。法執行機関にも通報済みです。

1つの侵害が次の侵害を招く連鎖

Fireworks AIの2件目のインシデントの影響は、顧客自身の業務にも及び、Notionの顧客データの一部も流出しました。Notionは、影響を受けた可能性のあるワークスペースは全体の1%未満だと確認しています。

流出した記録には、実際のNotion AIとの会話が含まれていました。RenderのCEOであるAnurag Goel氏は、Notionからの通知をXで共有し、Renderも被害を受けた顧客の1社であることを明らかにしました。 

Notionによると、流出したチャット記録の大半には、作成者や元のワークスペースを特定するラベルが付いていませんでした。ただし、会話の内容自体は閲覧可能な状態でした。

Notionの顧客の一部がFireworks AIの侵害に巻き込まれた。画像: Xのスクリーンショット

これは、下流に波及するサプライチェーンの問題です。Fireworksはインフラの一部を外部プロバイダーに頼っており、そのプロバイダーが侵害されたことで、攻撃者はFireworksの開発環境にアクセスできました。その結果生じた流出は、Fireworksが顧客のために処理していたデータにまで広がり、顧客の顧客にも被害が及びました。

防御側が取るべき対応

だからといって、企業がサードパーティベンダーへの依存をやめるべきだというわけではありません。こうした提携にはリスクを完全には排除できない部分があり、少なくとも現時点ではやむを得ません。それを踏まえたうえで、企業や防御側は、被害が生じた際に自らを守る方法をあらかじめ計画しておく必要があります。

まずは、次のような実践的な対策から始めます。

• ベンダーがアクセスできる範囲を限定する: サードパーティプロバイダーには、サービス提供に必要な権限とデータのみを与えます。
• 保有データを把握する: 各プロバイダーと共有している顧客記録、認証情報、データセットなどの情報を管理します。
• アクセスを迅速に遮断できるよう備える: 認証情報の失効、影響を受けたサービスの切断、流出したシークレットのローテーションに関する計画を用意します。
• 対応方法を把握する: インシデント発生時にベンダーがどう通知するか、自社のどのデータが影響を受けた可能性があるかをどう特定するかを定めておきます。
• 利用しているサードパーティと、そのベンダーが顧客について保有するデータを、常に顧客に知らせる: 顧客は、これを基に自らのセキュリティ対策を計画し、自社との取引を続けるかどうかを判断できます。 

これらは確立されたセキュリティ対策です。しかし、AIサービスの相互接続が進むなか、今回のFireworksのインシデントは、その重要性が変わらないことを示しています。

外部プロバイダーがもたらすリスクを、組織がすべて排除することはできません。それでも、サプライチェーンのどこかで起きた侵害が、自社の顧客にとってより大きなインシデントになる可能性は下げられます。

関連ニュースとして、 Black Kiteの新しいレポートによると、1万8,000社を超えるAIサプライヤーの34.2%に、未修正の重大な脆弱性があることがわかりました。サードパーティのAIサービスのセキュリティや、企業のデータ・インフラへの潜在的なリスクが懸念されます。