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

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

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

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

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

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

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

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

可用性を計画する

リモートバックエンドはネットワークサービスに依存します。サイナーを利用する前にisAvailable()を呼び出し、一時的な障害にはバックオフ付きのリトライを適用し、障害時のフォールバックパスを定義してください。Keychainはリモートバックエンドに対してHTTPSを強制し、デフォルトのリクエストタイムアウトを適用します。

シークレットとトランスポートの保護

すべてのリモートバックエンドはHTTPSで通信します。HTTPS以外のエンドポイントは拒否されます。
APIキー、トークン、認証情報はシークレットマネージャーまたは環境変数から提供してください。ハードコードしたり、ソースコントロールにコミットしたりしないでください。
Keychainはエラーレスポンスをサニタイズして、シークレットがログに漏洩するのを防ぎます。独自のログにも生の認証情報やキーマテリアルが含まれないようにしてください。

署名の監視と監査

署名の成功率、レイテンシ、失敗件数を追跡し、急増時にはアラートを発行してください。詳細は本番環境への対応のメトリクスをご参照ください。プロバイダー側の監査ログ（KMS、Vault、またはカストディアン）を有効にし、アプリケーションが送信したトランザクションと照合してください。