この鍵は自壊する:失効可能なAPIキーのためのオープン標準

セキュリティ責任者なら誰しも、何らかの形でこの事態を経験したことがあるはずです。研究者やスキャナー、あるいは善意の第三者が、公開リポジトリに置かれたあなたの会社のAPIキーを見つけてしまう。この瞬間から時計は動き出しますが、待っているのはキルスイッチではなく宝探しです。このキーを発行したのはどの会社なのか。誰に連絡すればいいのか。security.txtは用意されているか。そのメールボックスを誰か見ているのか。適切な担当者が適切な認証情報を失効させる頃には、すでに数時間、あるいは数日が経過しています。一方で攻撃者に必要な時間はわずか数分です。ボットは常に公開リポジトリをスクレイピングしており、漏洩したシークレットの大半は何年経っても有効なままです。

この問題について印象的なのは、実は一度すでに解決済みだという点です。2013年、OAuthはRFC 7009を得ました。これはwell-known設定URLを通じて発見可能な、標準化されたトークン失効エンドポイントです。仕様に準拠したクライアントであれば、誰でもプログラム的にトークンを無効化できます。ところが業界はその後も、実際には最も漏洩しやすい認証情報であるプレーンなAPIキーを、失効の仕組みを一切持たせないまま出荷し続けてきました。

唯一の明るい材料はGitHubのSecret Scanning Partner Programです。プロバイダーが鍵のパターンを登録し、GitHubが公開コミットをスキャンし、失効はWebhookで実行されます。これは機能していますが、独自仕様かつ中央集権的で、招待制という制約があります。一方でオープンソースのスキャニング界隈がどこへ向かっているかを見てみると、新世代のスキャナーはどれも同じロードマップ項目を掲げています。プロバイダーのAPIを通じた自動失効です。しかし発行元に対して「このキーを失効させてください」と伝える標準的な手段が存在しない以上、各スキャナーはプロバイダーごとに個別の連携を手作業で構築せざるを得ません。

そこにギャップがあります。そこで、私が実現したいと考える標準の構想をお示しします。名付けてORKS、Open Revocable Key Standard(オープン失効可能鍵標準)で、草案の仕様はすでにGitHubに公開しています。『ミッション:インポッシブル』のブリーフィングテープのように、発想はシンプルです。認証情報には最初から自壊機能を組み込んでおくべきだ、というものです。

提案の4つの柱

1. 発行元を名乗る鍵。すべての鍵は固定プレフィックス、エンコードされた発行元ドメイン、シークレット本体、チェックサムを含む形式を持ちます:orks_{issuer}_{secret}_{check}。GitHubはすでにこのパターンの両方の要素が有効であることを証明済みです。トークンのプレフィックスによってスキャニングが扱いやすくなり、埋め込みチェックサムによって誤検知が排除されました。新しい要素は発行元ドメインです。これにより、鍵を発見したスキャナーは誰に連絡すればよいかを、オフラインの状態で正確に把握できます。

2. 発見可能なキルスイッチ。すべての発行元は/.well-known/api-key-configに小さなJSONファイルを配置し、その失効エンドポイント、任意のイントロスペクションエンドポイント、セキュリティ連絡先、対応している鍵の制約条件を記載します。これはOIDCディスカバリーやsecurity.txtと同じ考え方です。

3. 所持による失効。失効エンドポイントに鍵全体をPOSTします。認証は不要です。その理屈はこうです。鍵を保持している者はすでにその鍵を悪用できる立場にあるため、代わりにその鍵を破壊させる権利を与えることは、純粋に改善にしかなりません。完全な鍵の提示を要求することで、総当たりで探索できる余地はなくなり、エンドポイントは鍵が有効だったか、無効だったか、あるいは実在しなかったかにかかわらず、同じ「受理しました」という応答を返します。

4. 宣言された制約条件。ディスカバリーファイルには、発行元がIPアローリスト、有効期限の必須化、スコープ、mTLSといった、どのバインディングに対応しているかが公開されます。「このベンダーはIP固定の鍵に対応しているか」という問いに対して、2週間に及ぶメールのやり取りではなく、調達担当のツールが一回のGETリクエストだけで答えられるようになります。

ラインを止めない引き紐

認証不要の失効に対して最も強い反論となるのが可用性です。所持していることが失効の権限になるのであれば、漏洩した鍵はもはや機密性の問題にとどまりません。それを見つけた誰もが、curlコマンド一発で本番環境の連携を止められてしまうのです。

これに似た課題に対するトヨタの答えが「アンドンコード」でした。どの作業員も紐を引くことができますが、引いたからといって工場のラインが即座に止まるわけではありません。まず注意を喚起し、一定の猶予時間内に問題が解決しなければ、そこで初めてラインが停止する仕組みです。ORKSはこの設計思想を、任意設定の「隔離モード」という形で取り入れています。認証不要の失効リクエストが送られても、鍵はその場で即座に無効化されるわけではありません。代わりに次のような流れをたどります。

1. 登録済みのすべてのチャンネルを通じて、報告者が提示した証拠とともに、所有者に即座に通知されます。
2. 鍵は即座に制限を受けます。読み取り専用となり、レート制限がかかり、破壊的な操作はブロックされ、すべての動作がログに記録されます。
3. タイマーが起動します(既定値は24時間で、ディスカバリーファイルに明示されます)。タイマーが満了すると、鍵は自動的に無効化されます。
4. 所有者は即時失効へと処理を早めることも、提示された証拠を明示的に確認した上で取り消すこともできます。ただし、これらの操作は認証済みのダッシュボードからのみ行え、メールのリンクからは決して行えません。

これにより、嫌がらせ目的の悪用は、サービス停止ではなく管理された縮退運転へと姿を変えます。実際に漏洩した鍵は、最後の数時間を完全に生きたままではなく、手足を縛られた状態で過ごすことになります。そして決済や管理者権限のような高リスクな鍵の種別については、発行元は単純に即時モードを宣言すればよいのです。このトレードオフは、誰がたまたま最初にセキュリティ用の受信箱を読んだかという偶然に左右されるのではなく、明示的に公開されたポリシーとして扱われるようになります。

AIエージェントによってこの問題が急務となる理由

ここまで述べてきたことは、認証情報を保持する主体が開発者やCIパイプラインを指していた時代から、すでに真実でした。それが今、自律的なAIエージェントが認証情報の保持者になるケースが増える中で、いよいよ切実な課題となっています。

エージェントは認証情報の乗数のような存在です。あなたのツール群に組み込まれた単一のエージェントが、メール、コード、CRM、決済、クラウドインフラといった鍵をすべて同時に保持することになり、しかも各チームはそれらを棚卸しするより速いペースでエージェントを展開していきます。エージェントの漏洩の仕方も従来とは異なります。プロンプトインジェクションによって自ら認証情報を外部に流出させるよう誘導されることがあり、またマシン並みの速度でログにシークレットを書き出してしまうこともあります。侵害から悪用までの猶予は数日から数秒へと縮まっており、メールから始まる失効プロセスはもはやどう考えても遅すぎます。

ORKSはエージェント時代に3つの点で適合します。機械可読なキルスイッチは、まさに自律システムが利用できるインターフェースです。プロンプトインジェクションの試みを飛行中に検知したガードレールは、反射的にその認証情報自体を隔離できます。宣言された制約条件は、完全には信頼していない相手に鍵を渡す際の手段になります。IPを固定し、スコープを絞り、有効期限を短くするといった具合です。そして私が特に気に入っているパターンは、この構図をまるごと逆転させます。タスクを終えたエージェントは、退出時に自ら鍵を失効させるべきだ、という発想です。即時自己失効ポリシーと短いTTLを組み合わせて発行された鍵は、時間軸における最小権限の原則を実現します。タスク完了後にログの中から見つかった鍵は、その時点ですでに死んでおり、失効の呼び出し自体が監査イベントを兼ねることになります。

業界全体はエージェントのアイデンティティ管理について、OAuthを土台とした答えへと収束しつつあり、それは正しい方向性です。しかし過渡期の現実として、数百万に及ぶエージェントが、それ以上の仕組みを何ら提供しないサービスの静的な鍵を保持し続けています。失効の標準があったからといって、その鍵自体が優れたものになるわけではありません。しかし、その鍵を「殺せる」ものにはできます。そしてそれこそが、悪用するよう操られる可能性のあるエージェントにとって、最も重要な性質なのです。

この先の展望

well-known方式の優れた点は、中央の管理主体も一斉導入も必要としないところにあります。あるプロバイダーは、次のスプリントでこれを出荷できます。鍵にプレフィックスを付け、静的なJSONファイルを1つ公開し、エンドポイントを1つ立てるだけです。プロバイダーごとの失効連携を急いで構築しようとしているスキャナー各社は、その代わりに汎用の検出器を手に入れることになります。新しい発行元が加わるたびに、すべてのスキャナーがより役立つものになっていきます。これはsecurity.txtを当たり前の存在に押し上げたのと同じ好循環です。

行き着く先は、良い意味で退屈なものです。鍵が漏洩すると、それを保持するスキャナーやエージェントが数分のうちに発見し、発行元をデコードし、well-knownエンドポイントにアクセスして、認証情報を隔離する。所有者は不正利用の報告を受け取るのではなく、通知と証拠へのリンク、そしてローテーションボタンを目にして目覚めることになります。

あなたのミッションは、もし引き受けるとすれば、次の通りです。発行するすべての鍵に、自壊する能力を持たせること。この提案は、あなたのことを見捨てはしません。

エンドポイントのスキーマ、鍵のフォーマット、隔離状態のステートマシンを含む草案仕様(ORKS v0.1)の全文は、レビューと貢献を受け付けています。github.com/6d6b68/ORKSにてご確認ください。フィードバック、異論、そして私が見落としている先行事例など、あらゆる意見を歓迎します。issueまたはプルリクエストをお寄せください。