暗号鍵を保存する

秘密鍵は、対応する権限に許可されたすべての操作を承認できます。秘密鍵は決して共有しないでください。シード素材、復旧用の秘密情報、ベアラートークン、エクスポートした鍵ファイルも同じように厳重に保護してください。

本番運用を開始する前に、鍵の管理方式を決めてください。その方式は、リスクにさらされる価値、アカウントコントローラーのポリシー、デプロイの復旧手順に適合していなければなりません。

鍵管理の境界を定義する

• 各権限、公開鍵、アルゴリズム、環境、用途、管理者、保管場所、バックアップ、交換手順を一覧にして管理します。
• 開発、テスト、本番、通常取引、ガバナンス、デプロイ、復旧には、それぞれ別の鍵を使用します。
• 人やプロセスには、その役割に必要な鍵だけへのアクセスを許可します。
• リスクモデルで必要とされる場合は、高額取引やガバナンスの署名に独立した承認を求めます。
• 署名者が使用できるネットワークと権限を記録します。署名サービスは、その範囲外の要求を拒否しなければなりません。

適切な保管方法を選ぶ

ローカル開発、管理されたテスト、または安全な鍵管理環境への引き渡しでは、権限を制限したファイルに鍵をエクスポートできます。対応している Unix プラットフォームで、kagami を使用して新しい鍵ディレクトリを生成します。

cargo run --bin kagami -- keys --algorithm ed25519 --out-dir ./client-key

親ディレクトリは既に存在している必要があります。対象ディレクトリは、新規であるか、現在のユーザーが既に所有しているもので、モードが 0700、シンボリックリンクを含まず、空でなければなりません。Kagami は public.key と private.key をモード 0600 で書き込み、--pop を指定した場合は pop.hex も書き込みます。所有者だけにアクセスを許可するファイルシステム規則を Kagami が適用できないプラットフォームでは、コマンドは失敗します。

秘密鍵ファイルは暗号化されていないエクスポートです。ソース管理、共有フォルダー、ログ、チケット、チャット、ビルド成果物には含めないでください。本番鍵を承認済みの鍵管理環境にインポートした後、デプロイ手順に従ってエクスポートしたファイルを削除します。開発用の鍵を本番で再利用しないでください。

本番環境では、次のような監査可能な鍵管理環境を優先します。

• ハードウェアセキュリティモジュール、またはハードウェアで保護されたキーストア
• OS またはモバイル端末のキーストア
• 孤立した署名サービス
• 許可されたワークロードにだけ鍵を渡すシークレットマネージャー

選択した統合が対応している場合は、鍵素材をエクスポート不能にしてください。鍵管理システムが、Iroha の権限で必要とされるアルゴリズムと署名操作をサポートしていることを確認します。

保存時の暗号化は、保存されたコピーを保護します。しかし、許可されていないプロセスやオペレーターが復号済みのバイトを取得した後は、鍵を保護できません。ホストを堅牢化し、実行時のアクセスを制限し、署名動作を監視してください。

署名作業を保護する

• 名前付きのオペレーター ID、強力な認証、署名システムへの監査可能なアクセスを使用します。
• 生の鍵を、コマンドライン引数、シェル履歴、環境ダンプ、プロセス一覧、クラッシュレポート、アプリケーションログに含めないでください。
• 必要な操作の間だけ署名者のロックを解除します。使用後はセッションを閉じるか期限切れにします。
• 承認前に権限,ネットワーク,指示,資産,料金を表示します.
• 特権的な取引や高額取引には、明示的な確認を求めます。
• カスタムクライアント統合で署名を委任できる場合は、生の秘密鍵をブラウザページや汎用アプリケーションプロセスの外に保持します。

平文のクライアント設定は、ローカル開発と管理されたテストだけに適しています。本番の統合では、承認済みの鍵管理環境を介して署名を取得する必要があります。標準の Iroha CLI はクライアント設定から秘密鍵を読み取り、汎用の外部署名者アダプターは提供しません。カスタムクライアントはトランザクションペイロードのハッシュを構築し、外部署名者が生成した署名を添付できます。

鍵のバックアップと復旧

• 復旧ポリシーでバックアップが必要とされる鍵だけをバックアップします。
• バックアップを暗号化し、稼働中の署名者とは分離して保管します。
• 稼働中の鍵と同じアクセス制御および承認制御をバックアップにも適用します。
• 職務分離が必要な場合、復旧用の認証情報は独立した管理下に置きます。
• 本番の鍵素材を露出させずに復元をテストします。
• バックアップの作成、アクセス、復元、破棄をすべて記録し、レビューします。

無関係なウォレットのニーモニック形式で Iroha の秘密鍵を表現できるとは限りません。選択した鍵管理システムがサポートし、テスト済みの復旧形式だけを使用してください。

露出した鍵または廃止した鍵を交換する

事故の前に交換を準備する.手順は次のことを特定しなければならない:

1. 誰が鍵の露出または廃止を宣言できるか
2. 影響を受ける署名者がどのように隔離されるか
3. 新しい鍵が生成され,承認された保管に入れる方法
4. アカウントの場合、承認されたコントローラーの交換またはソーシャルリカバリーによって、代替となる正規の AccountId を作成し、関連付けられた状態を移行する方法
5. ノードまたはピアの場合、承認されたオンチェーンのコンセンサス鍵のローテーションまたは無効化を、BLS PoP、アクティベーションと重複期間のポリシー、ローカル鍵設定、trusted_peers_pop、デプロイトポロジーと連携させる方法
6. 依存する設定、アプリケーション、オペレーターが、新しい AccountId、公開鍵、またはピア ID を採用する方法
7. 古い鍵の権限を削除し、そのコピーをアーカイブまたは破棄する方法
8. その後にネットワークと依存アプリケーションを検証する方法

WARNING

暗号化や新しいパスワードを施しても、コピーされた秘密鍵を再び安全にすることはできません。露出が疑われる場合は鍵の使用を中止し、承認済みの交換または失効手順に従ってください。

暗号鍵生成, 運用セキュリティ,および セキュリティ原則を参照.