Fireworksでは二つの侵害が判明した
Fireworks AIが最初のセキュリティ告知を出したのは10月9日である。当初は、評価ジョブなどで同社が保存した秘密情報へのアクセスだけが判明していた。その後の調査で、請求先住所、請求書と支払い履歴、アカウント残高、クレジット利用量も影響範囲に入った。カード番号は同社が保存しておらず、影響していない。[1]
限られた顧客については秘密情報、データセット、未完成のモデル重みもアクセスされた。Fireworksは対象顧客へ個別に通知しているが、影響件数は公表していない。調査は継続中であり、ここで確認できるのは公表済みの種類までである。
別の経路もあった。Fireworksの研究開発用マシンを置いていた第三者クラウドが10月23日に侵害され、攻撃者は24日にFireworksの開発マシンへ到達した。不正な処理を動かし、追加の顧客データへ影響を与えた。同社は同日中に検知し、25日以降は成功した不正アクセスを確認していないとしている。[1]
Notionの会話記録まで影響が届いた
NotionがFireworksを使っていた用途は二つある。Notion AIの利用状況を顧客が理解するための「Insights」で会話を分類する処理と、オープンウェイトモデルを提供するための推論処理である。11月2日夜、Fireworksは最初に合成テストデータへのアクセスを伝えた。Notionは翌朝までに接続を切り、Fireworks側のデータを削除した。[2]
ところが11月6日、Fireworksから顧客データが含まれる可能性を知らされ、8日に対象データが確定した。そこにはInsightsで使われたNotion AIの会話記録が入っていた。影響はNotionワークスペースの1％未満で、多くの記録は誰が書いたか、どのワークスペースかを示す識別子を持たず、外部ツールの実行結果も含まなかった。
識別子がないことは、内容が安全という意味ではない。会話本文に会社名、顧客情報、パスワード、APIキーを書けば、その文字列自体から利用者や業務が分かる場合がある。Notionは影響を受けた顧客へ閲覧方法を案内し、該当期間に秘密情報を貼り付けた場合は交換するよう求めた。ほかのNotion機能への影響は確認していないとしている。[2]
中核サービスが無事でもデータは外へ出る
FireworksはInference、Training SDK、Nexusには影響を検知していないと説明する。これらは標準でZDR、つまり入力を保持しない設定である。一方、Insightsの分類やデータセットを使う学習では、処理のために情報を保存・転送する経路が生まれる。同じAI事業者でも、機能ごとに保持条件と影響範囲が異なる。[1]
Fireworksは調査中、自分でデータセットをアップロード、ダウンロードする機能を止めた。認証情報とサービスアカウントの交換、不要な高権限の削除、ネットワーク分離、保存先と監査ログの強化も進めている。Training SDKは保存しない設定のまま利用できるという。
The RecordはFireworksの告知とNotionの説明を照合し、請求情報、データセット、モデル関連データが侵害対象に含まれたこと、NotionがInsightsを停止し、Fireworks経由のオープンウェイトモデル提供もやめたことを報じた。[3]
AI委託先を確認する四つの質問
企業がSaaSへ生成AI機能を導入するときは、製品名と利用規約だけではデータ経路を把握できない。調達、法務、セキュリティ、現場の担当者が、少なくとも次の四点をそろえる必要がある。
- どの機能が外部AIへ送るか：チャット、分類、検索、要約、学習を分け、対象データを確認する。
- 何をどれだけ保持するか：ZDR、短期ログ、学習用データセットを同じ「AI利用」としてまとめない。
- 再委託先はどこか：AI事業者が使うクラウドや分析基盤まで、契約と事故通知の経路を確認する。
- 停止と削除ができるか：一つの機能だけを切り、保存済みデータを削除し、証跡を受け取れるかを事前に決める。
今回、Notionは11月3日に接続を切ったが、顧客データの可能性が通知されたのは6日だった。初報の範囲が後から広がることはある。通知を受ける担当、対象者を抽出する手順、秘密情報を交換する責任者を決めておかなければ、影響を確認するまでの時間が延びる。
入力禁止だけに頼らず漏えい後を設計する
従業員に「秘密情報をAIへ入力しない」と伝えるだけでは不十分である。会話は下書き、問い合わせ、ログ解析の途中で業務データを含みやすい。入力制御に加え、機密度に応じて使える機能を分け、APIキーのような形式を検知し、貼り付けを止める仕組みが必要になる。
影響を受けたNotion顧客は、案内された記録を確認し、そこに認証情報があれば発行元で失効させる。会話に顧客情報や社内情報が含まれていた場合は、契約上の通知義務と社内の事故対応手順も確認する。対象外の顧客へ一律に被害を広げて扱う必要はない。
AI機能の価値はモデルだけで決まらない。入力がどこを通り、どれだけ残り、事故時に誰が説明できるかまでが製品の条件である。委託先の侵害を自社システムの外の出来事として切り離さず、データの経路に沿って停止、削除、交換を実行できる設計が求められる。
まとめ
- Fireworks AIでは初回侵害に加え、第三者クラウドから開発マシンへ到達する別の侵害が起き、請求情報や一部のデータセットなどが影響を受けた。
- Notionではワークスペースの1％未満に関係するAI会話記録が含まれた。Notion本体の侵害でなくても、外部AI基盤から利用者データへ影響が届いた。
- 利用企業は機能ごとの送信先、保持条件、再委託先、停止と削除の手順を確認し、漏えい後の鍵交換と通知まで準備する必要がある。
読者のコメント (0)
コメントを残す