儲存密碼金鑰
私鑰可以授權其授權主體所允許的每項操作。切勿分享私鑰；種子材料、復原祕密、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
加密或更換密碼都無法讓已遭複製的私鑰重新變得安全。若懷疑金鑰已暴露，請立即停止使用，並遵循經核准的取代或撤銷程序。