Keychain 对签名后端进行了抽象，但在生产环境中运营签名器仍是您的责任。这些实践适用于所有后端；有关后端选择，请参阅 选择后端。
区分热签名器与冷签名器
使用低余额的运营（"热"）签名器处理频繁的自动化交易，使用独立的高价值（"冷"）签名器处理国库资金转移。冷签名器应由 MPC 托管或云端 HSM 支持，并在签名前要求审批策略。由于接口完全相同，每个角色可使用不同的后端，而无需修改调用点。
有计划地轮换密钥
在 Solana 上，签名密钥即账户地址，因此轮换密钥会生成新地址。请将密钥轮换规划为迁移过程：先配置新密钥，将相关权限（或资金）迁移至新地址，再停用旧密钥。每个环境使用独立密钥，确保开发网密钥绝不在主网中复用。
授予最小权限访问
将每个后端的凭证权限限定在签名所需的最低范围。对于 AWS KMS,
即针对特定密钥授予 kms:Sign、kms:DescribeKey 和 kms:GetPublicKey 权限
(可用性检查会用到后两个);优先使用 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 费用指令)。请基于其返回的交易继续操作, 切勿使用您提交的原始交易,并且要先于任何其他签名器运行它。
- Rust 会对中间密钥缓冲区进行清零;Python 和 Go 则做不到。在这些语言中使用 Memory 后端时,请将整个进程内存视为敏感数据。
- 使用 Ledger 时,设备屏幕是唯一可信的签名内容描述。请勿在生产环境中启用
unsafe-debug功能, 也不要为solana_remote_wallet启用TRACE日志, 因为这两者都会记录设备和交易的详细信息。
完整说明请参阅 安全模型。
Is this page helpful?