出金権限付きAPI キーの強制拒否：技術深掘り解説

ほとんどの取引プラットフォームは出金権限が有効なAPI キーを受け入れています。黄色の警告バナーを表示し、「理解しました」と入力するよう求め、それでもキーを保存します。私たちは異なります。あなたのキーに出金権限がある場合、オンボーディング時に拒否し、決して保存しません。この記事では、その理由、方法、そして代替案の実際のコストを説明します。

脅威モデルを一段落で

出金権限付きAPI キーを保持するシステムは、認証情報漏洩により、ユーザーアカウントを空にすることが一度のミスで起こります。漏洩はデータベース侵害である必要はありません。侵害された従業員のラップトップ、設定ミスのあるバックアップ、サードパーティ依存関係のサイドチャネル、またはプロセスメモリダンプが暗号化されていないログに落ちることもあります。これらはすべて私たちより大きな企業で実際に起きています。唯一の確実な防御は：誰の資金へのキーも最初から持たないことです。

検出の仕組み

ユーザーがキーを貼り付けた後の最初の認証済みコールで、取引所固有の権限内容照会コールを実行します。主要な取引所のほとんどは以下のいずれかを公開しています：

• 権限セットを構造化されたフィールドとして返す専用の「API キー情報クエリ」エンドポイント、または
• キーの権限スコープが応答ペイロードの一部として含まれるアカウント情報エンドポイント。

出金、内部振替、サブアカウント振替出金、またはユニバーサル振替出金を許可するフラグを探します（取引所は同じ考え方に異なる名前を使用しています）。これらのいずれかが存在する場合、秘密鍵をメモリから即座に破棄し、UI に構造化されたエラーを返し、キーを決してデータベースに書き込みません。

警告ではなく強制拒否する理由

警告はクリックされます。私たちは複数の製品でこれに関するデータを長年観察してきました。「理解しました」と入力するユーザーの基本率（上記の単語を一つも読まずに）は80％を超えています。80％のユーザーに無視される警告はセキュリティコントロールではなく、責任回避の盾です。

強制拒否はその反対です。正しい場所に摩擦を置きます：ユーザーは取引所に戻り、取引権限のみの新しいキーを作成し、戻ってきてそれを貼り付けます。ループ全体にかかるコストはユーザーにとってもせいぜい2分です。最悪ケースの認証情報漏洩シナリオの場合、攻撃者にかかるコストはアカウント全体です。

警告して拒否しないパスが実際にあなたに何のコストをもたらすか

警告して保存するパターンはユーザーフレンドリーに見えます。最悪ケースを尋ねるまで：敵対的な従業員1人、サプライチェーン侵害1件、遷移的依存関係のサイドチャネル1件、スコープが間違ったログ1件があれば、答えは出金権限付きキーがそれに触れた最も弱い人と最も弱いコードと全く同じくらい信頼できるということです。

強制拒否はその計算を裏返しにします。最悪ケースの完全なデータベース侵害でも、攻撃者は読み取り+取引キーのみを持って去ります。取引のみのキーは被害を与える可能性があります（ポジションを吹き飛ばし、手数料を蓄積し、流動性の低いペアにオープンポジションをダンプできます）。しかし、出金することはできません。資金は取引所に残ります。それはゼロリスクではありませんが、自動取引エージェントを最初に接続することで署名したリスクです。

私たちがまだ防御できないもの

強制拒否が完全なセキュリティ体制であると主張していません。それは1つのコントロールです。完全なセットはセキュリティページで記載されています：ユーザーごとのデータキーを持つ KMS エンベロープ暗号化、API コールの期間中だけプロセスメモリに存在する復号化された秘密、追加のみのハッシュチェーン監査ログ、CI テスト済みのクロスユーザー分離、脆弱性開示プログラム。出金権限の強制拒否はそのスタックで最も目に見えるピースです。またオンボーディング中に出金権限付きキーの拒否をリアルタイムで見ることができるため、自分で検証するのが最も簡単なピースでもあります。