一台の穴が全台の合鍵に。封じ込めと鍵の打ち直し

連載「AIのAPIキーが盗まれた日」の第 4 回です。前の回: 第 3 回 入口はバックアップの管理画面だった。次の回: 第 5 回 被害が小さかった3つの理由と、AIのAPIキーを守るチェックリスト。最初から読む場合は第 1 回です。

入口は、全台の控えを集める台の管理画面でした(第 3 回)。では、この台から他のサーバーへ、実際にどこまで届くのでしょうか。確かめると、届きました。控えの中の合鍵などを通って、ほかのサーバーに入れる状態でした。この回では、止める作業、届くかの確認、鍵の打ち直しを、確かめたことと一緒に説明します。あわせて、「なぜ」そうしたのかも書きます。

作業は Claude Code が、編集長の指示と承認を得ながら進めました。時刻は日本時間です。

この回の早見

見るだけの監査から、止める作業へ

それまでの作業は、読み取りだけの監査でした。ここから、止める作業に切り替えました。どの操作も、実行の前に編集長の承認を得ています。

1. 攻撃を止める: 11:45 に、2 回目の攻撃の処理を止めました。管理画面のサービスも止めました。
2. 外への通信を断つ: 受け取り口への外向きの通信を遮断しました。盗んだ物を、これ以上送らせないためです。
3. 証拠を残す: 証拠一式を別の場所へ退避し、手元にも控えました。
4. 残りの全台を確認する: 同じスクリプトも、同じ外部接続も、どこにもありませんでした。
5. 同じ欠陥の可能性に備える: 同じ欠陥の可能性がある台には、遮断と更新の対応をとりました。欠陥の内容は第 3 回に書きました。

なぜ、止めたらすぐ証拠を残すのか

止めただけでは、何が起きたかが分からなくなるからです。電源を切るなどの操作で、残っていた記録は消えます。IPA の手引きも、不用意な操作で記録を消さないように書いています。記録がなければ、何が外へ出たのか、入口はどこだったのかを、あとから確かめられません。編集部は、止めたあと、消える前に証拠を別の場所へ残しました。

この台から他へ、どこまで届くか

調査を担当した AI の記録には、「ここで、もっと嫌な事実に気づく」とあります。この台は、ただの一台ではありません。全サーバーの控えを持ち、ほかのサーバーに入るための権限も持っていました。そこで、「この台から他の台へ、実際にどこまで届くか」を、承認のもとで確かめました。

結果は、届きました。道は 2 つです。

道 1: この台の権限

この台は、ほかのサーバーに入るための権限を持っていました。その権限は、まだ生きていました。つまり、この台を乗っ取った人は、ほかのサーバーにも入れる状態でした。

道 2: 控えの中の合鍵

全台の控えの中には、ほかのサーバーに入るための鍵がありました。控えを開ければ、合鍵が手に入ります。

そして、その控えを開く鍵も、一緒に漏れていました。

調査を担当した AI の記録には、「合鍵がバックアップの中にあり、そのバックアップを開ける鍵も一緒に漏れている、という最悪の循環」とあります。一台の穴が、理論上は、管理している全台の合鍵につながっていました。

合鍵を打ち直した

届くと分かったので、合鍵を打ち直しました。やったことと、確かめたことを書きます。

1. この台の権限を、すべて取り消しました。 この台の鍵では、もうどこにも入れないことを、実際に確かめました。
2. 関係する鍵と証明書を、すべて作り直しました。 古いものでは入れず、新しいものは通ることを、確かめました。
3. 控えを開く鍵も、替えました。 古い鍵では、もう開かないことを確かめました。

控えの本体が持ち出された形跡は、確かめた範囲では見つかりませんでした。

OWASP(ウェブの安全に取り組む国際的な団体)の資料も、漏れた、または漏れたかもしれない秘密は、失効させて使えなくすることを求めています。

なぜ、全部の鍵を替えるのか

持ち出された形跡が見つからなくても、全部替えました。「見つからなかった」ことと「無かった」ことは、別だからです。どの鍵が見られたかを、あとから完全には言い切れません。見られたかもしれない鍵を、ひとつずつ見分けて残すより、全部を使えなくするほうが確実です。

守りが自分に噛みついた

作業の途中には、小さな落とし穴もありました。守りの仕組みが、作業中の自分を攻撃者と見て、締め出したのです。

調査を担当した AI の記録には、「守りを固めると、守りが自分に噛みつく」とあります。守りを変える作業のときは、自分の作業も止められることを、前提にしておく必要があります。

学び: 合鍵と、それを開ける鍵は別の場所に

OWASP の資料には、鍵は、その鍵で守っている秘密のそばに置かない、という考え方があります(鍵自体が暗号化されている場合は別です)。今回は、合鍵が控えの中にあり、控えを開く鍵も一緒に漏れました。ひとつ漏れると、全部が開く形です。

この形は、次の 3 点で崩せます。

• 控えの中に、全体を開ける合鍵を置かない。
• 控えを開く鍵を、控えと同じ所に置かない。
• 漏れたかもしれない鍵は、使われる前に失効して、新しい鍵に替える。

具体的な手順は第 5 回でチェックリストにします。

考察: 被害が小さかったことの意味

確かめたことと、編集部の推測を分けて書きます。

• 確かめたこと: 2 つの道は、実際に届く状態でした。一方で、第 3 回のとおり、居座りや横展開は、確かめた範囲では始まっていませんでした。
• 推測(確かめていません): 届く状態にあったことと、届かれたことは別です。今回は、後者が起きる前に止められたと考えられます。ただし、止められたのは攻撃の途中だったからです。守りが十分だったからとは言えません。
• 一般化: 全体を支える台に「全体の鍵」が集まると、一台の穴が、全体の穴になります。侵入の跡が無くても、鍵が読める所にあれば、守れたことにはなりません。

回想: 漏れた鍵を、発行元が止める仕組み

この分野では、漏れた鍵への備えが変わってきました。2021年6月8日の GitHub の告知では、OpenAI などが、GitHub の秘密のスキャンの連携先に加わりました。GitHub は、見つけた鍵を発行元のサービスへ転送します。発行元は、その鍵を自動で無効にして、持ち主に知らせます。2018年から数えて、36 の発行元と協力してきた、とも書かれています。漏れた鍵を、持ち主が気づく前に、発行元が止める流れです。

ただし、この仕組みが見るのは GitHub に置かれた鍵です。今回のように、自社の台から漏れた鍵には届きません。自分で替える備えが、いまも要ります。

今日できること

• 控えや設定ファイルの中に、ほかの場所に入るための鍵が入っていないかを調べます。
• 控えを開く鍵が、控えと同じ所にないかを調べます。
• 鍵を全部替える手順を、紙 1 枚に書いておきます。だれが、どの順で替え、何で確かめるか、です。「古い鍵で入れないこと」を確かめるところまで書きます。

この回で分かったこと

• 止める作業は、攻撃を止める、外への通信を断つ、証拠を残す、の順で進めました。
• 一台の穴は、この台の権限と、控えの中の合鍵の 2 つの道で、全台に届きました。
• 控えを開く鍵も一緒に漏れていたため、合鍵は理論上、取り出せる状態でした。
• この台の権限を取り消し、関係する鍵と証明書を作り直し、控えを開く鍵も替えました。古い鍵で入れないことを確かめました。

読み手へのひとこと

「侵入の跡がない」ことは、安心の理由になりません。まず、自分の控えの中に、全体を開ける鍵が入っていないかを見てください。見つかったら、その鍵を替えるところから始められます。小さな会社でも、今日の 30 分でできる確認です。

次の回

実害が小さく済んだのは、なぜでしょうか。第 5 回 被害が小さかった3つの理由と、AIのAPIキーを守るチェックリストで、3 つの理由と、明日からできることを整理します。