AWS不正アカウントでClaudeを蒸留する攻撃と企業の備え

分析・見解

計算資源の窃盗とモデル複製が一本の線でつながった

これまで、クラウドの不正利用といえば暗号資産の採掘が定番だった。盗んだアカウントで高性能な計算機を借り、電気代と請求を他人に押し付ける手口である。今回の件が新しいのは、同じ手口の出口が「他社AIの能力の複製」に変わった点にある。

攻撃者の側から見ると、設計は合理的である。アカウントは使い捨てなので、請求も停止も自分に返ってこない。上限に達したら次のアカウントへ移ればよい。こうして集めた問いと答えの組は、小さなモデルを育てる教材になる。

知識蒸留は正規の技術であり、問題は使い方にある

知識蒸留（＝大きなモデルの答えを教材にして、小さなモデルに同じ振る舞いを覚えさせる手法）は、それ自体は広く使われる正当な技術だ。多くのAI企業が、自社の大型モデルから軽量版を作るために使っている。

問題は、他社のモデルを許可なく教材にすることである。利用規約はたいてい、出力を競合モデルの学習に使うことを禁じている。しかし規約は、偽名で作ったアカウントの背後にいる相手には効かない。守る側は、契約ではなく技術的な検知で対処するしかなくなる。

窃取の対象は能力だけでなく安全性の調整にも及ぶ

報告で注意したいのは、模倣の対象に安全性の調整が含まれる点だ。拒否すべき依頼を断る仕組みは、開発元が長い時間と費用をかけて作り込んだ部分である。蒸留では、この断り方の癖までは正確に写し取りにくい。

その結果、能力は近いのに安全面の歯止めが弱いモデルが生まれうる。悪用の目的で使うなら、歯止めが弱いことはむしろ都合がよい。ここが、単なる知的財産の問題にとどまらない理由である。

防御の主戦場は、アカウント作成と使い方の異常検知に移る

アカウントの自動作成を防ぐには、登録時の本人確認、支払い手段の審査、新規アカウントへの初期上限が基本になる。一方、API側では、一つの主体が極端に幅広い話題へ、機械的な間隔で問い続ける行動を見つける必要がある。普通の利用者は特定の用途に偏るが、蒸留目的の利用は話題を網羅しようとして偏りが少ない。

ただし、攻撃者はアカウントを分散させて一つあたりの量を薄める。単独のアカウントを見る監視では足りず、支払い情報や接続元、時間帯の共通点から束ねて見る仕組みが要る。今後は、この関連付けの精度が防御側の差になるだろう。