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は今度は研究開発インフラに関わる別の侵入を明らかにした。
同社によると、R&D用マシンをホスティングしていたサードパーティークラウドプロバイダーで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は、XでNotionからの通知を共有し、Renderが影響を受けた顧客の1社であることを確認した。
Notionによると、流出した記録の大半には作成者や元のワークスペースを特定するラベルがなかったものの、会話内容自体にはアクセスできる状態だった。
Notionの一部の顧客がFireworks AIの侵害に巻き込まれた。画像：Xからのスクリーンショット
これは、下流に位置するサプライチェーンの問題を引き起こす。Fireworksはインフラの一部を外部プロバイダーに依存しており、そのプロバイダーが侵害されたことで、攻撃者はFireworksの開発環境にアクセスできた。その結果として生じた流出は、Fireworksが自社の顧客向けに処理していたデータにまで及び、その顧客の顧客にも影響を与えた。
この問題を受けて防御側がすべきこと
だからといって、企業がサードパーティーベンダーへの依存をやめるべきだという意味ではない。少なくとも現時点では、この提携に伴うリスクの一部を完全に排除することはできない。ただし、その事実を理解すれば、インシデントが発生した際の影響から自社を守る方法を計画するよう、企業や防御担当者を促せるはずだ。
まずは、いくつかの実践的な対策から始める。
- ベンダーのアクセス範囲を制限する：サードパーティープロバイダーには、サービス提供に必要な権限とデータだけを与える。
- ベンダーが保有するデータを把握する：各プロバイダーと共有している顧客記録、認証情報、データセット、その他の情報を追跡する。
- アクセスを迅速に遮断できるよう備える：認証情報の無効化、影響を受けたサービスの切断、流出した秘密情報のローテーションを行う計画を用意する。
- 対応方法を把握する：インシデント発生時にベンダーからどのように通知を受けるか、また自社のどのデータが影響を受けた可能性があるかを特定する方法を決めておく。
- 常に顧客に知らせ、利用しているサードパーティーと、これらのベンダーが顧客について保有するデータを知らせることだ。これにより、顧客はそれに応じてセキュリティー対策を計画し、今後も取引を続ける必要があるかどうかを判断できる。
これらは確立されたセキュリティー対策だが、AIサービスの相互接続性が高まる中でも重要であり続ける理由を、今回のFireworksのインシデントは示している。
組織は外部プロバイダーによってもたらされるあらゆるリスクを排除することはできない。しかし、サプライチェーンの別の場所で起きた侵害が、自社の顧客にとってより大きなインシデントへと発展する可能性を下げることはできる。
そのほかのニュースとして、 Black Kiteの新たなレポートでは、1万8,000社を超えるAIサプライヤーの34.2％に重大な未修正脆弱性があることが判明した。この結果は、サードパーティーAIサービスのセキュリティーと、企業のデータやインフラに及ぶ潜在的なリスクへの懸念を高めている。