Northflankで利用者のAIキーが悪用 止めるのは発行元の管理画面

Northflankに置いていたAIのAPIキーは、Northflankの画面で値を書き換えただけでは止まりません。漏れた古いキーは、発行したOpenAIやAnthropic、Googleの管理画面で失効させるまで、外からでも使えるからです。

アプリとAIエージェントの実行基盤を提供するNorthflankは、日本時間2026年10月30日22時40分から、ステータスページでセキュリティインシデントを知らせ始めました。31日未明の更新からは、利用者が預けたAIのキーが使われたという報告にも触れています。

調べ終わる前に「全部」と言い切った

最初の告知の呼びかけは「環境変数をすぐにローテーションする」の一行でした。その下に、Wizの警告からの経過が並びます。18分後には状況を「Identified」に変え、すべての環境変数が復号されたものとみなして、キーを止めるか替えるよう求めました。その後の更新では、ワークロードに付けたシークレットに加え、シークレットグループとグローバルシークレットも対象だと示しています。

ステータスページの更新を、日本時間に直して並べました。

ステータスページの時刻で引き算すると、警告から利用者への最初の告知までは約2時間です。調べ終わる前から「全部」と言い切る書き方は、当サイトで追ってきた同じ型の事故と比べても思い切っています。利用者は、自社が対象かどうかの連絡を待たずに動けます。

10月だけで9件目

Northflankの件は、単独の事故ではなさそうです。31日8時38分の更新は、AIの認証情報を狙う攻撃の大きな流れと合うかもしれないとし、似たIPアドレスが載っている資料としてWizの報告「Black October」を挙げました。

Wizが米国時間10月30日に出したこの報告によると、10月中にインシデントを公表したAIの開発基盤は少なくとも9社です。公表された報告に共通するのは、保存された環境変数、とくにAIを使えるものを探して狙う手口だといいます。9件に共通する単一の脆弱性や依存関係はない、との断り付きです。

当サイトで取り上げた2件と並べると、同じ「環境変数を狙われた」事故でも、気づき方と利用者への頼み方が違います。表の日付は各社が公表した日なので、Wizの一覧の日付とずれるものがあります。

範囲の示し方は、3社でずいぶん違います。Zeaburの件では確認できた件数を示し、確認できないものは流出したものとして扱う方針でした。Railwayの件は「一部の利用者に限られる見込み」としましたが、念のため全員に替えるよう求めました。つまりNorthflankは、その「念のため」を最初から前提に置いたことになります。

AIのキーは、発行元で止めるまで生きている

31日8時38分の更新で、Northflankは利用者にこう求めました。

Revoke existing credentials with their issuing providers, generate replacements, and update the affected secrets and workloads in Northflank. Review your AI provider usage and billing logs for unexpected activity, and report any suspicious usage to Northflank support and the relevant provider.

発行元で今の認証情報を失効させ、新しいものを作り、Northflankのシークレットとワークロードを更新する。そのうえでAIの提供元の利用と請求のログを見て、見覚えのない動きがあればNorthflankと提供元の両方に知らせる、という順番です。

Northflankの値の書き換えは、手順の最後の一手にすぎません。10月17日のOpenCode Consoleの件でも、Consoleからキーを消しただけでは各社の側で失効しないことが、見落としやすい点でした。

Railwayとの違いも一つあります。Railwayは10月21日の告知に、AIの推論を提供する上流の会社へ、キーをすべて前もって失効させるよう知らせたと記しました。Northflankの更新には同じ一文がありません。提供元が先回りして止めてくれると当てにせず、自社で失効させる前提で動くほうが確実です。

失効の順番は、提供元の案内でも分かれます。Googleは、新しいキーで動くのを見届けてから古いキーを無効にする順で、止まる時間を避ける書き方です。Anthropicの案内は、漏れた疑いがあればすぐに削除する順です。すでに無断利用の報告が出ている今回、編集部はAIのキーに限っては先に失効させる順でよいと考えます。使われた分はそのまま自社の請求になり、次に見るとおり、攻撃者が使い始めるのはとても速いからです。

漏れて30分で試され、数日後にあふれる

Wizの報告には、こうした基盤から漏れたキーのその後を追った記録が2件あります。Wizは漏れた基盤の名前を出しておらず、対象も企業のAmazon Bedrockのキーです。Northflankの件と同じとは言えませんが、使われ方の流れはよく分かります。

• 最初の無断の呼び出しは、基盤で認証情報が読まれたとされる時刻から30分以内だった。一般家庭の回線のIPアドレスから、複数の組織のキーを1分ほどで試していた
• その後の数日は、同じ小さなプログラムから1日14〜120回の呼び出しが続くだけだった。Wizは、キーがまだ使えるかを確認する処理とみている
• 事例Aは4日後に使えるモデルを一通り試され、数時間後に大量の利用が始まった。30時間で約80万回、約9割が通った。事例Bは7日後に転売の仕組みとみられる所に現れ、翌朝から13時間で約170万回、うち100万回超が通った
• 2件だけで、定価にすると10万ドルを超える利用になったとWizは見積もっている

つまり、請求の急な増え方だけを監視していると、手前の数日を見逃しかねません。大量に使われる前に、1日に十数回から百回あまりの見覚えのない呼び出しが続く時間があるからです。

しかも、Wizの事例のように30分で試されるなら、告知を見てから替えた会社でも、替える前の呼び出しはもう済んでいるかもしれません。Northflankの件は読まれ始めた時刻もはっきりしないので、キーを替えたあとも、利用の記録は告知より前にさかのぼって見ておきたいところです。

3社の管理画面で見る所

では、利用の記録と上限は、どの画面で見ればよいのでしょうか。Northflankは「AIの提供元の利用と請求のログを見る」と書くだけです。OpenAIとAnthropic、Googleの公式の説明を読み、見る所を並べました。

表でまず見てほしいのは2行目です。3社の説明を読む限り、利用額の上限はキー1本ごとではなく、プロジェクトかワークスペースの単位で付きます。Googleは、キーには独自の請求の設定がなく、プロジェクトの上限を引き継ぐと明記しています。

裏を返せば、PaaSに置くキーは、その基盤専用のプロジェクトかワークスペースで作るのが得策です。そこに付けた上限が、1つの基盤から漏れたときの損の天井になります。Anthropicでは、既定のワークスペースで作ったキーの利用額は、組織全体の上限でしか止まりません。

ただし、上限はブレーキであって鍵ではありません。OpenAIは反映が即時ではないと書き、Googleも請求データの処理が遅れて上限を超えうると断りを入れました。事例Bの13時間で約170万回は、編集部で割ると1分あたり約2,200回です。通らなかった呼び出しも含む数ですが、同じ勢いなら、数分の遅れの間に通る回数も少なくないはずです。

次に作るキーの寿命は、提供元の設定で縮められます。OpenAIはプロジェクトのAPIキーに有効期限を付けることを強く推奨しており、管理者は組織やプロジェクトでキーの最長の有効期間を決められます。Googleは2026年5月28日から、AI Studioで新しく作るキーを「auth key」にしました。サービスアカウントに結び付き、漏れたと検知したキーの利用をすばやく止める仕組みがあるといいます。

ステータスページに書かれていないこと

11月1日8時31分の更新の時点で、次の点はまだ書かれていません。

• 侵入の経路と、環境変数が読まれ始めた時刻
• 影響を受けた利用者の数と、使われたキーの提供元や金額
• 自社のクラウドで動かすBYOCの利用者も、同じ扱いか
• 31日に全員へ有効にした監査ログに、それより前の操作が残っているか
• AIの提供元に、キーの失効を頼んだか

分からないことが多いぶん、利用者がとれる手は「全部替える」に絞られます。逆に言えば、迷う所の少ない告知です。

影響するのは、Northflankに鍵を置いた会社と委託先

Northflankでサービスやジョブ、コーディングエージェントを動かし、環境変数にAIのキーやクラウドの鍵を置いている会社は、影響を受ける前提で動きます。Northflankは全員に全部替えるよう求めました。自社が対象かどうかの連絡を待つ理由はありません。公式サイトはCodexやClaude Codeをクラウドで動かす使い方を前面に出しているので、AIのキーが並んでいる会社は多いでしょう。

• アドオンでPostgreSQLやMongoDB、MySQL、Redis、MinIO、RabbitMQを使っている会社も対象です。Northflankが用意したローテーションでパスワードを替え、公開アクセスを有効にしていれば止めます
• 開発を任せた会社や、社内の一部のチームが個人の契約でNorthflankを使い、会社のキーを置いている場合も同じです。会社の台帳に載っていないことがあるので、聞いて回るしかありません
• BYOCで自社のクラウドに載せている会社は、Northflankに扱いを問い合わせつつ、答えを待たずに替えておくのが無難でしょう
• Northflankを使っておらず、キーも預けていない会社は、今回の件では影響を受けません

ただ、10月だけで同じ型の公表が9件あります。ほかのPaaSに置いたAIのキーも、同じ手順で見直す価値は十分にあります。

週明けを待たずに進める手順

1. Northflankを使っている部門と委託先を聞き、プロジェクトごとに、環境変数とシークレットグループ、グローバルシークレットにある鍵の名前を一覧にします。値は書き写さず、どの提供元のどのキーかが分かれば足ります。
2. AIのキーは、OpenAIやAnthropic、Googleの管理画面で失効させ、新しいキーをNorthflankのシークレットとワークロードに反映します。クラウドやGitHub、決済の鍵も、それぞれの発行元で同じように替えます。
3. 各社の利用の記録をキーごとに開き、少なくとも10月分をさかのぼって見ます。急な増加に加えて、1日に十数回から百回あまりの見覚えのない呼び出しも探し、見つけたらNorthflankのサポートと提供元に知らせます。
4. Northflankの監査ログで見覚えのない操作がないかを見て、ログを書き出しておきます。
5. 新しいキーはNorthflank専用のプロジェクトかワークスペースで作り、月の上限と金額の通知を付けます。OpenAIは「Enforce a hard limit」をオンにしないと、上限に達しても止まりません。あわせて、OpenAIならキーの有効期限、Googleなら送信元のIPアドレスの制限も、使える環境なら設定します。

環境変数に入れたキーの一覧は、たいてい置いた人の頭の中にしかありません。Northflankのキーを替える今日の作業は、その一覧を表にする機会でもあります。1つの基盤に1つのプロジェクトと決めておけば、次に同じ告知が届いた日に、失効させる範囲と上限で守られる額を探し回らずに済みます。