Notionは公式ヘルプで、委託先のFireworks AIが受けたセキュリティインシデントにより、Notion AIの一部チャットセッションが流出した可能性があると公表した。影響を受けた可能性があるのは全ワークスペースの1%未満で、Notionの英語版告知によると、該当するワークスペースの大多数では、チャットの発言者や送信元のワークスペースを識別できるラベルが付いていなかった。一方、Fireworksは10月9日の公表で、自社プラットフォームはZDR（ゼロデータリテンション）を採用しており、既定ではプロンプトや生成結果を保存しないと説明していた。データを保存しないはずのサービスから、なぜチャットの内容が流出した可能性があるのか。両社の公表内容を照らし合わせると、通常の推論処理ではなく、データセットとして保存された情報が流出に関係している可能性が浮かび上がる。
Notionの通知で明らかになったこと、分からないこと
Notionの公式ヘルプによると、同社はFireworksを主に2つの用途で利用していた。1つは、顧客がAIの利用状況を把握するための「Insights」機能におけるデータ分類処理だ。もう1つは、Notion AIでオープンウェイトモデルを利用できるようにする推論サービスである。今回のインシデントを受け、NotionはInsights機能を無効化し、Fireworks経由でのオープンウェイトモデルの提供も停止した。
Notionの英語版告知によると、事態が明らかになったのは11月2日夜だった。Fireworksから、悪意のある第三者が少量のデータにアクセスしたとの連絡を受けたが、当初はNotion AIの合成テストデータに限られ、顧客データは含まれていないと説明されていた。Notionは念のため、11月3日までにFireworksとの接続を解除し、同社のシステム内にあったデータをすべて削除した。しかし11月6日には、顧客データとみられる情報にも第三者がアクセスした可能性があるとの通知を受けた。さらに11月8日、Fireworksから新たなデータセットの存在が確認されたと連絡があり、Notionが分析したところ、Insights機能で使用されたチャットの記録が含まれていることが判明した。
Notionによると、影響を受けたワークスペースの大多数では、記録から発言者やワークスペースを特定できなかった。また、記録にはツール呼び出しの結果が含まれておらず、チャットの文言以外に企業やユーザーの特定につながる情報もなかったという。ただし、流出した可能性のあるチャットの総件数や、Insightsの分類処理に使用していたFireworksの具体的な製品、データがどの保存経路から流出したのかは明らかにされていない。流出経路を考えるには、これらの不明点を踏まえたうえで、Fireworksが公表しているインシデントの詳細やデータ保持の仕組みを確認する必要がある。
「推論はZDR」と「データセットへの影響」は矛盾するのか
Fireworksが10月9日に公表した初期の調査結果では、10月6日に内部認証情報が不正使用されたことを確認し、限られた顧客アカウントで実行された評価ジョブの環境変数が取得されていたと説明していた。一方、顧客のモデル、データセット、学習データ、推論トラフィック、個人情報については、Fireworksの管理範囲内で不正アクセスの証拠は検出されていないとしていた。つまり、この時点では顧客データそのものへの被害は確認されていなかった。
しかし、その後の調査で被害範囲は拡大した。Fireworksの更新情報によると、アカウント情報や請求情報への影響が判明し、一部のアカウントではシークレット、データセット、学習途中のモデルにも影響が及んでいた。さらに10月23日には、Fireworksの研究開発用マシンをホストする第三者クラウド事業者でインシデントが発生した。翌24日には、悪意のある第三者がそこから開発用マシンに侵入して不正なワークロードを実行し、追加の顧客データにも影響が及んだという。なお、この更新ページには公開日が記載されていないものの、11月2日に公開されたGoogleとMandiantのブログに言及していることから、それ以降に作成または更新された文書と考えられる。
ここで重要になるのが、Fireworksのデータ保持に関する説明だ。同社のデータセキュリティ文書では、オープンモデルを使用する際のプロンプトと生成データについて、ユーザーが明示的にオプトインしない限り、ログへの記録も保存も行わないとしている。これがZDRの基本的な仕組みである。一方、同じ文書では、モデルの学習ワークフローにおいて、データセット、チェックポイント、トレース、学習済みモデルなどを保持する場合があるとも説明している。つまり、Fireworksのすべての機能がデータを保存しないわけではなく、処理の目的や利用する機能によってデータの扱いが異なる。
実際、Fireworksのインシデント更新ページでは、推論サービス、Training SDK、Nexusの3製品について、ZDRが既定で適用されており、今回のインシデントによる影響は検出されていないとしている。一方、Batch Inferenceやデータセットを用いた学習で使用するセルフサービス型のデータセットについては、アップロードとダウンロードを停止したと説明している。これは、通常の推論サービスとは別に、顧客データの保存を前提とする機能が存在することを意味する。
この違いを踏まえると、NotionとFireworksの説明には一定の整合性がある。Notionは、Fireworksから通知された新たなデータセットを分析した結果、Insights機能で使用されたチャットの記録を発見した。一方、Fireworksはデータセットへの影響を認めながら、通常の推論サービスへの影響は検出していないとしている。これらの情報を総合すると、Notion AIのチャットは推論時の通信やログから直接流出したのではなく、何らかの処理のために保存されていたデータセットから流出したと考える方が、現時点の公表内容とは整合的だ。
別の可能性と、見立てが覆る条件
ただし、この見立てには重要な不確実性が残っている。最大の問題は、Notionが言及した「新たなデータセット」が具体的に何を指しているのか分からないことだ。Fireworksのシステムに保存されていた入力データの集合を意味するのか、それとも攻撃者が持ち出したデータを調査の過程でまとめたものなのかは、Notionの説明だけでは判断できない。後者であれば、データセットという表現から元の保存場所を推定することはできず、推論処理中のデータが取得された可能性も残る。
また、Fireworksは初期の調査では顧客データへの不正アクセスの証拠を検出していないと説明していたが、その後の調査で被害範囲を拡大している。更新ページでも調査が継続中であり、追加情報が公表される可能性があるとしている。したがって、FireworksがZDRを採用しているという説明だけで、推論処理に関連するデータの流出を完全に否定することはできない。設計上のデータ保持方針と、実際のインシデントで何が起きたかは分けて考える必要がある。
それでも、保存されたデータセットからの流出という見立てには、複数の状況証拠がある。第一に、Fireworks自身がデータセットへの影響を認める一方、推論サービスへの影響は検出していないと説明している。第二に、NotionはFireworksから通知された新たなデータセットを分析し、Insights機能で利用されたチャットの記録を発見したと述べている。第三に、NotionはFireworksとの接続解除に際して同社システム内のデータを削除し、学習処理も停止したとしている。ただし、この削除対象に具体的にどのようなデータが含まれていたのかは明らかではなく、学習処理の停止を流出元の直接的な証拠とみなすことはできない。
現時点で言えるのは、データセットとして保存された情報が流出に関係した可能性が比較的高いということまでだ。Notionのチャットがいつ、どのような目的でFireworks側に保存されたのか、あるいはそもそもFireworks側に保存されていたのかは確定していない。今後、Fireworksの最終調査報告やNotionの続報で、流出元が推論ログだったと明らかになれば、この見立ては覆る。逆に、Insightsの分類処理にBatch Inferenceなどのデータ保存を伴う機能が使われていたと確認されれば、保存されたデータセットから流出したという仮説を裏付ける材料になる。
Notion AI利用者が取るべき対応と今後の焦点
日本でNotion AIを業務に利用している組織にとっては、流出経路の解明を待たずに対応すべき点がある。Notionは、対象データを流出したものとして扱い、該当期間中にNotion AIのチャットへパスワードやAPIキーを入力していた場合は、直ちに変更または再発行するよう求めている。影響を受けたワークスペースのオーナーは、サイドバーの「?」から「セキュリティインシデントのレビュー」を開くことで、該当するデータを確認できる。この確認機能はデスクトップアプリまたはWebブラウザから利用する必要があり、モバイルアプリには対応していない。
今後の焦点は、Fireworksが流出元となった製品や機能を特定するか、NotionがInsightsの分類処理で使用していたデータ経路を明らかにするかの2点にある。今回の事案は、AIサービスが通常の推論処理ではデータを保存しないと説明していても、それだけでは関連するすべてのデータ処理や保存経路の安全性を判断できないことを浮き彫りにした。流出が保存を伴う機能で発生したのか、それとも推論処理に関係する経路で発生したのかによって、今回のインシデントから得られる教訓は大きく異なる。両社の今後の説明では、被害範囲だけでなく、チャットデータがどのように扱われ、どの経路から第三者にアクセスされたのかを明らかにすることが求められる。
