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

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

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

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

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

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

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

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

可用性を計画する

リモートバックエンドはネットワークサービスに依存します。サイナーを利用する前に可用性を確認し (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で、ループバックでのプレーンHTTPを許可するため、ローカルの vault server -devが動作します。
  • APIキー、トークン、および認証情報はシークレットマネージャーまたは環境変数から 供給してください。ハードコードしたり、ソース管理にコミットしたりしないでください。
  • Keychainはエラーレスポンスをサニタイズしてシークレットがログに漏洩するのを防ぎます。 独自のログにも生の認証情報や鍵素材が含まれないようにしてください。

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

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

Keychainが確認する内容を把握する

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

詳細は セキュリティモデル をご覧ください。

Is this page helpful?

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