本番環境のベストプラクティス

Keychainは署名バックエンドを抽象化しますが、本番環境でのサイナーの運用は 依然としてお客様の責任です。これらのプラクティスはすべてのバックエンドに適用されます。バックエンドの選択については バックエンドの選択を参照してください。

ホットサイナーとコールドサイナーを分離する

頻繁な自動トランザクションには残高の少ない運用用(「ホット」)サイナーを使用し、 資金の移動には別の高額(「コールド」)サイナーを使用します。 コールドサイナーはMPCカストディまたはクラウドHSMで保護し、署名前に承認ポリシーを 必須とします。インターフェースは同一であるため、各ロールは呼び出し箇所を変更することなく 異なるバックエンドを使用できます。

計画的に鍵をローテーションする

Solanaでは署名鍵がアカウントアドレスそのものであるため、鍵をローテーションすると 新しいアドレスが生成されます。ローテーションはマイグレーションとして計画してください。新しい鍵を プロビジョニングし、関連する権限(または資金)を新しいアドレスに再割り当てしてから、古い鍵を 廃止します。環境ごとに異なる鍵を使用し、devnetの鍵がmainnetで再利用されないようにしてください。

最小権限アクセスを付与する

各バックエンドの認証情報は、署名に必要な最小限の範囲に絞ってください。AWS KMSの場合は、特定のキーに対する kms:Sign、kms:DescribeKey、kms:GetPublicKey です(可用性チェックでは後者の2つを使用します)。静的な認証情報よりIAMロールを推奨します。Vaultポリシーやマネージドウォレットの APIキーにも同じ原則を適用してください。

可用性を計画する

リモートバックエンドはネットワークサービスに依存します。signerを利用する前に可用性を確認し(TypeScriptでは isAvailable()、RustとPythonでは is_available()、Goでは IsAvailable(ctx))、署名のみの失敗にはバックオフ付きでリトライし、障害時のフォールバック経路を定めてください。ブロードキャストを行うバックエンド(Crossmint、Fordefiのネイティブ自動モード)を無条件にリトライしてはいけません。未確認のブロードキャストへの対処を参照してください。Keychainは設定されたベースURLにHTTPSを強制し、リダイレクトを拒否し、デフォルトのリクエストタイムアウトを適用します。

未確認のブロードキャストへの対処

CrossmintとFordefiのネイティブ自動モードは、サーバー側で署名とブロードキャストを行うため、呼び出しが失敗しても何も反映されていないとは限りません。プロバイダーがトランザクションを受理した可能性がある場合、Keychainは BROADCAST_UNCONFIRMED(Rustでは SignerError::BroadcastUnconfirmed)を返します。このエラーには、作成リクエストが受理された場合はプロバイダーのトランザクションIDが含まれ、さらに、作成リクエストの送信時に使用された、メッセージから導出されたべき等キーが常に含まれます。

  • 他の操作を行う前に、まずトランザクションIDを使ってプロバイダー側と照合してください。
  • バイト単位で同一のトランザクションを再送しても安全です。べき等キーにより重複が排除されます。
  • トランザクションを再構築すると(たとえば新しいブロックハッシュを使う場合)、新しいキーが生成されるため、別の送金として扱われます。

シークレットとトランスポートを保護する

  • リモートバックエンドは、設定されたベースURLにHTTPSを強制し、リダイレクトを拒否します。唯一の例外はVaultで、ローカルの vault server -dev が動作するよう、ループバックでは平文のHTTPを受け付けます。
  • APIキー、トークン、および認証情報はシークレットマネージャーまたは環境変数から 供給してください。ハードコードしたり、ソース管理にコミットしたりしないでください。
  • Keychainはエラーレスポンスをサニタイズしてシークレットがログに漏洩するのを防ぎます。 独自のログにも生の認証情報や鍵素材が含まれないようにしてください。

署名をモニタリングおよび監査する

署名の成功率、レイテンシ、および失敗数を追跡し、急増時にはアラートを発報してください。 メトリクスの詳細については本番環境の準備状況を参照してください。 プロバイダー側の監査ログ(KMS、Vault、またはカストディアン)を有効にし、 アプリケーションが送信するトランザクションと照合してください。

Keychainが検証する内容を理解する

  • Keychainが検証するのは署名のホップであり、トランザクション自体ではありません。シミュレーション、トランザクション内容のチェック、ポリシーエンジンはありません。これらはアプリケーション側、またはプロバイダーのポリシー制御で実施してください。
  • Fordefiのネイティブ手動モードは、署名の前にトランザクション(ブロックハッシュ、Compute Budgetの手数料instructions)を書き換えます。送信したものではなく、返されたトランザクションから処理を続け、他のどのsignerよりも先に実行してください。
  • Rustは中間的な鍵バッファをゼロ化しますが、PythonとGoにはできません。これらの言語でMemoryバックエンドを使う場合は、プロセスのメモリ全体を機密として扱ってください。
  • Ledgerでは、署名対象の内容として信頼できる唯一の表示はデバイスの画面です。本番環境では、unsafe-debug 機能を有効にしたり、solana_remote_wallet の TRACE ログを有効にしたりしないでください。どちらもデバイスとトランザクションの詳細をログに出力します。

全体像についてはセキュリティモデルを参照してください。

Is this page helpful?

© 2026 Solana Foundation. 無断転載を禁じます。