存储加密密钥
私钥可以授权执行其对应权限主体获准的任何操作。绝不能共享私钥。种子材料、恢复秘密、Bearer 令牌和导出的密钥文件都必须受到同等级别的保护。
在投入生产前确定保管方案。该方案必须与风险价值、账户控制器策略及部署的恢复流程相匹配。
定义保管边界
- 维护清单，记录每个权限主体、公钥、算法、环境、用途、保管方、存储位置、备份及替换流程。
- 为开发、测试、生产、日常交易、治理、部署和恢复分别使用不同的密钥。
- 人员和进程只能访问其角色所需的密钥。
- 风险模型要求时，高价值或治理签名必须经过独立批准。
- 记录签名器允许用于哪个网络和权限主体。签名服务必须拒绝超出该范围的请求。
选择合适的存储方式
对于本地开发、受控测试或安全的保管交接，可以将密钥导出到权限受限的文件。在受支持的 Unix 平台上，使用 kagami 生成新的密钥目录：
cargo run --bin kagami -- keys --algorithm ed25519 --out-dir ./client-key父目录必须存在。目标目录必须是新目录，或已经由当前用户所有；其模式必须为 0700，不得包含符号链接，并且必须为空。Kagami 以 0600 模式写入 public.key 和 private.key；--pop 还会写入 pop.hex。如果 Kagami 无法强制执行这些仅所有者文件系统规则，该命令会在相应平台上失败。
私钥文件是未加密的导出文件。不得将其放入源代码管理、共享文件夹、日志、工单、聊天或构建制品。应将生产密钥导入获批的保管边界，然后按照部署流程删除导出文件。不得在生产环境中重复使用开发密钥。
对于生产环境，优先使用经过审计的保管边界，例如：
- 硬件安全模块或硬件支持的密钥存储
- 操作系统或移动设备密钥库
- 隔离的签名服务
- 只向已授权工作负载释放密钥的秘密管理器
所选集成支持时，应让密钥材料保持不可导出。确认保管系统支持 Iroha 权限主体所需的算法和签名操作。
静态加密可以保护存储中的副本，但在未授权进程或人员取得解密后的字节后便无法继续保护密钥。应加固主机、限制运行时访问并监控签名活动。
保护签名工作流程
- 使用具名运营人员身份、强认证和经过审计的签名系统访问。
- 原始密钥不得出现在命令行参数、shell 历史记录、环境转储、进程列表、崩溃报告或应用日志中。
- 只在执行所需操作时解锁签名器，使用后关闭会话或让会话过期。
- 批准前显示权限主体、网络、指令、资产和费用。
- 对特权交易或高价值交易要求显式确认。
- 自定义客户端集成能够委托签名时，应让原始私钥远离浏览器页面和通用应用进程。
明文客户端配置只适用于本地开发和受控测试。生产集成应通过其获批的保管边界取得签名。原版 Iroha CLI 从客户端配置中读取私钥，且不提供通用的外部签名器适配器。自定义客户端可以构造交易有效载荷哈希，并附加由外部签名器生成的签名。
备份和恢复密钥
- 只备份恢复策略明确要求备份的密钥。
- 加密备份，并使其与在线签名器分开存放。
- 对备份应用与在线密钥相同的访问和批准控制。
- 需要职责分离时，由独立保管方持有恢复凭据。
- 在不暴露生产密钥材料的情况下测试还原。
- 记录并审查每次备份创建、访问、还原和销毁。
不要假设其他钱包的助记词格式能够表示 Iroha 私钥。只使用所选保管系统支持且经过测试的恢复格式。
替换已暴露或停用的密钥
在事件发生前准备好替换方案。流程必须明确：
- 谁可以宣布密钥已暴露或停用
- 如何隔离受影响的签名者
- 如何生成新密钥并将其置于获批的保管边界
- 对于账户，如何通过获授权的控制器替换或社会恢复创建替代的、规范且不含域名的
AccountId，并迁移关联状态 - 对于节点或对等节点，如何协调获授权的链上共识密钥轮换或停用与 BLS PoP、激活和重叠策略、本地密钥配置、
trusted_peers_pop及部署拓扑 - 依赖配置、应用和运营人员如何采用新的
AccountId、公钥或对等节点身份 - 如何移除旧密钥的权限，并将其副本归档或销毁
- 之后如何验证网络和依赖应用
WARNING
加密或更换密码都无法让已经复制的私钥重新变得安全。怀疑密钥暴露时，应停止使用该密钥，并遵循获批的替换或撤销流程。