API キーをクラウドに置いた企業の規程——10月の2つのプラットフォーム被害が浮き彫りにした空白
はじめに
AI サービスの API キーを、デプロイ先のクラウドプラットフォームの環境変数に置く運用は、すでに標準に近いものです。一方で、このやり方には規程に一行しか書かないまま見落とされがちな空白があります。キーを「保管する」ことと、キーが所在するプラットフォームそのものが破られたとき「自社の側で何を検知して、どこで止めるか」を書くことは、別の話です。
この空白を、2026 年 10 月 30 日に公開された2つの事象で確認できます。いずれも本稿の一次情報源は海外報道と各社の公表文です。日本語で全文を確認できた範囲での事実の整理であり、推測は推測として分けて書いています。
2つの事象が示した共通点
クラウド基盤を提供する Northflank は、2026 年 10 月 30 日、不正アクセスにより顧客の環境変数が復号されたと判断しました。直後、保存されていた顧客の AI API キーの不正利用を複数報告されたと公表しています。BleepingComputer が伝えた公表文によると、同社は「環境変数はすべて復号されたとみなせ。すべてのキーを無効化・再発行せよ」と顧客に呼びかけています。
ブロックチェーン分析の Chainalysis は同日、外部の行為者が社内システムへ不正アクセスしたと公表しました。手口は「offensive agentic techniques」、攻撃的なエージェント型の手口です。アクセスされたのは利用者 ID、氏名、メールアドレス、役割ラベルなどの顧客情報で、調査データや認証情報には到達していないと述べています。同社の公表文は、この事象と直近の Binance 盗難は無関係であると明記しています。
2件を並べると、同じ形が見えます。被害の中心にあるのはデータではなく、そのデータに接続できるキーです。そして、検知と発信の主体は、いずれも被害を受けたプラットフォーム側に置かれています。顧客である自社が「自分のキーが不正に使われている」ことを最初に知る経路は、プラットフォームの公表か、請求書の異常か、提供者のメールのいずれかです。
規程にない境界
日本の中小企業のセキュリティ規程に「API キーは適切に保管すること」と書いていないところは多くありません。一方で、次の3点を置いている規程は、本稿執筆時点では見た限り少ないです。
1 つ目はキーの所在です。環境変数に置く、ということは、キーの実体は自社ではなくプラットフォーム上にあります。所在が外部である以上、「保管」の対象はキーそのものより、そのキーが使える範囲のほうが大きくなります。所在が規程に書かれていないと、キーが盗まれることと、キーが使える範囲が広すぎることが、規程上同じ「保管の問題」に見えてしまいます。
2 つ目は外部のプラットフォームが破られた場合の自社側の検知です。今回の2事象で、プラットフォームは速やかにパッチを当て、顧客に公表しました。しかしその速さは、キーが使われ始めてから請求が出るまでのより短い窓より速いとは限りません。プラットフォームの検知は、被害側の内部で起きます。自社に届くのは、その結果です。自社が「自分が送ったはずのない呼び出し」を検知できる経路を持っているか、という問いは、規程に無いまま放置されがちです。
3 つ目は、検知の主体の所在です。プラットフォームが「あなたのキーが使われています」と知らせるのを待つ運用は、検知の主体を被害側に預けることになります。キーは自社の資産であり、その使われ方の監視まで外部に預けると、規程上の責任の境界が不明確になります。
制度として書くべき境界
本稿で言いたいのは、今回の被害を自社のものにならせず、規程の空白を埋めることです。
1 つ目、キーの所在を規程に書き出します。どのキーがどのプラットフォームのどの環境変数にあるか、一覧化します。所在が書かれていれば、「保管する」は「その所在と使える範囲を管理する」に置き換わり、範囲が広すぎるキーは保管の問題として処理できます。
2 つ目、自社側の検知経路を1つだけ置きます。請求書の異常を見てから動く運用は、窓を逃します。少なくとも、自社が送ったはずのない呼び出しを、自社の側で一度見る仕組みを、規程の対象に入れます。これがどれほど軽く済むかは本稿の範囲外で、ここで置くのは「規程の対象にする」ことのほうが小さいという事実です。
3 つ目、検知の主体を自社に戻します。プラットフォームの公表を待つのではなく、プラットフォームの公表が起きた時点で、自社の所在一覧と照合する手順を、規程の付録として置きます。
いずれも、キーを守るための新しいツールではなく、規程に「キーがどこにあり、その使われ方を誰がどこで見るか」という1行を足すことです。今回の2事象は、その1行が書かれていなかったことが、被害が請求書として届くまでの時間差にそのまま写ったという点で、参考になります。
本稿は事実の整理が主眼です。具体的な検知の仕組みや、各社の被害範囲の確定は、本稿の範囲外であり、公表文と報道が示している範囲に留めています。
参考情報
- BleepingComputer、2026 年 10 月 30 日公表、2026 年 11 月 2 日取得。北米のセキュリティ報道媒体であり、本稿の Northflank 事象の一次確認経路である。
- Chainalysis、2026 年 10 月 30 日公表、2026 年 11 月 2 日取得。同社の公式公表文であり、本稿の Chainalysis 事象の一次資料である。
- 白米元気「1Password の記事を読んで、自分の鍵を数えてみた話」、Zenn、2026 年 11 月 2 日公開。日本語圏で同日、キーの所在と数を整理する話題として出ている例である。
本稿は AI の支援を受けて執筆されました。事実の確認と内容の責任は筆者にあります。